X
Business

Avaya aims to boost IP multicast methods with new network fabric

Avaya contributes to the fabric networking buzz with a new option that should support up to tens of thousands of video streams versus just hundreds previously.
Written by Rachel King, Contributor

Avaya is the latest networking player to throw its submission into the growing ring of fabric networking solutions debuting this week.

See also: Dell intros new SDN fabric for data economics, architectures | Avaya taps EMC, VMware for speeding up cloud connections

Announced amid the Open Network Summit in Santa Clara, Calif. this week, Avaya reps described that VENA Fabric Connect is designed to deliver network services from datacenters to the desktop while enabling a more agile network.

Sounds straightforward enough, but the key is differentiating this from a pack of new network fabric technologies rolling out.

Many of Silicon Valley's old guard businesses have been turning toward open technologies, in particular, to handle unified communications as well as big data — much like we've seen recently with Hadoop and open source software. Just look at IBM, Intel, and EMC, for starters.

The main theme of Avaya's new fabric release could be summed up as "out with the old, in with the new," being that VENA is intended to enable businesses to gradually phase out legacy infrastructures in favor of a unified, end point provisioning infrastructure.

One of Avaya's approaches is touting one of its new releases, the VSP 4000, as the "industry’s first" fabric-enabled multi-service and multi-tenant edge device, which is supposed to connect the dots from the VENA fabric across an entire network to remote offices, whether it be at mid-market enterprises or for hosting providers.

With these back-end solutions in play, that's where Avaya is inserting its core unified communications products.

For example, Avaya touted that with the VENA Fabric Connect, IP Multicast protocols should then be able to support up to tens of thousands of video streams versus just hundreds previously with sub-second failover times rather than seconds or minutes.

Editorial standards