Avaya Wireless is all about SDN

After hearing about Avaya’s wireless portfolio recently, I kept coming back around to a common thread that seemed so entrenched in the core of their solution – SDN. Admittedly I’m not a Data Center or Applications kind of guy, but Avaya has an interesting take on positioning their wireless portfolio. Instead of focusing heavily on a unique set of hardware specific features in their Access Points, they focus on a ‘module enabled’ Software Defined Network strategy. Paul Unbehagen, Chief Architect at Avaya accurately describes SDN as meaning something different to everyone.

At its core, regardless of vendor or implementation, SDN is meant to ease network administration and orchestration by way of software (the S in SDN). Avaya enables this by way of software running on their hardware to create Fabric Attach (FA) Elements. These elements use FA Signaling as a way of communicating amongst each other. These modules running throughout your network (on Avaya hardware) automatically discover and become a part of your FA Core through the orchestration suite.

Avaya does this across their entire infrastructure portfolio which includes their core products, edge switching, and Wireless Access Points. These components all orchestrate together to automatically configure and allocate resources in your infrastructure as needed. In one example, they showed an Access Point coming online and auto-registering using Fabric Attach and magically the requisite VLANs for the wireless infrastructure were automatically provisioned on the uplink switch. It’s clear that Avaya has invested significant resources in enabling this FA functionality including going as far as proposing Fabric Attach as a standard to the IEEE but their messaging is clear – when you run an FA enabled network end to end, it ‘just works’.

It was interesting in hearing the Avaya story in their own words including their addressing some of the more interesting corner cases:

• Running an FA network without FA enabled devices being attached – this is supported using standards based LLDP TLVs but will likely require more effort than having the FA ‘agent’ running natively on your device.
• Running Avaya wireless on a non-FA infrastructure – this is supported, but Avaya doesn’t bring anything special to that story that someone else doesn’t already do. This is an interesting scenario that could be positioned for transition needs.

In short, Avaya has taken a link-layer protocol, customized it heavily and allowed it to ask for network resources in an orchestrated fashion. It remains to be seen if this meets everyones definition of SDN and is somewhat predicated on the ‘controller bottleneck myth’ that seems so pervasive in the wireless industry. I, for one, am very interested in seeing where this takes us over the next several years. Addressing distributed challenges at scale (such as provisioning resources) is a problem that has been solved in the wireless space for a long time – do it centralized and scale from the inside out. I look forward to seeing how (and if) Avaya can leverage this FA architecture across multiple platforms and vendors to create the foundational panacea that SDN promises.