SDN is about an evolution not a revolution: Avaya

“Telecom industry has done a good job at evolving the networking protocols to support various applications needs, there is still a great deal of complexity while making the environment fragile,  highly subject to instability and slow recovery, causing outages that the business cannot afford to have and SDN promises to address these downfalls,” says Jean Turgeon, Vice President & Chief Technologist, Avaya in conversation with Mohd Ujaley

What initiatives Avaya is taking in the areas of Software-defined networking (SDN)?
Conceptually, SDN was originally introduced to simplify and accelerate deployment of new services and applications by building software based centralized controller and an abstraction layer between the protocols, due to the inter-dependencies of the protocol stack when running on a node.

Most vendors have focused mainly in developing a solution leveraging a centralized controller model, moving from a distributed control plane architecture to a centralized control plane one. Additionally most vendors when it comes to SDN are only addressing the data center challenges and not the ability to extend services where users and devices are located which clearly isn’t in the data center.

Avaya has taken an innovative and differentiated approach to deliver on what SDN promises to overcome from IT challenges perspective: Virtualize and eliminate unnecessary protocols across the entire enterprise. By eliminating unnecessary protocols, reducing the number to ONE if desired, recovery times are faster, not only in the data center, but across the enterprise.  By virtualizing the entire Enterprise (Data Center, Campus and Branches) with a simplified model, we have eliminated the legacy client or server nodal model, and delivered to our customers a much easier evolution towards NFV. We have also transitioned some of our network services to a virtualized model. For example, our Policy Access control has been virtualized in addition to our Session Border Controller (SBC), while through our SDN Fx introduction; we also have the ability to virtualize routing services through an open vSwitch model.

With a virtualized, services-based architecture, through a Fabric based solution and SDN FX, NFV services are easily adaptable and easier to deploy. The competition continues to push nodal configuration and traditional complex configurations such as VLANs, ACL’s, even Spanning Tree in some instances. For Multicast services being offered such as video distribution (Surveillance, digital signage, etc.) the competition continues to us PIM, which doesn’t provide the scaling and recovery times these critical services require. They continue to resist transitioning away from box by box scripting or programming, regardless if configuration is done centrally or not.

What are the major factors that are propelling the demand for SDN in telecom sector?
The telecom industry in India is one of the most advanced and highly competitive in the world. With the new spectrums, reach to new customers across India, and the promise to deliver connectivity and mobility to the billion potential users in the country, and the sector becoming one of the pillars of economic growth in India, the challenges are huge.  The industry, to build a remain competitive and relevant,  and continue being at the forefront of the industry services quickly and efficiently, it is looking for a combination of reliability, agility and security to continue enhancing its customer experience, provision new services internally and externally while remaining highly secure. In fact, the industry leaders whom we’ve met at our latest CXO event in India in April 2015, told us that the sector needs a network architecture that, not only allows it to competitively deliver to the India market, but also support growth beyond Indian borders.

It is the promise of services deployment acceleration through applications profiling which makes SDN and NFV so interesting for the Telecom sector. While the industry has done a good job at evolving the networking protocols to support various applications needs, there is still a great deal of complexity while making the environment very fragile,  highly subject to instability and slow recovery, causing outages that the business cannot afford to have.

While SDN promises to address these downfalls, Avaya fundamentally believes that we must first fix the foundation before we attempt to mask the level of complexity associated with deploying services end to end.

Nodal configuration using the legacy protocols carries a lot of risk due to its configuration complexity and implementation requiring multiple nodes to be reconfigured. Therefore, enterprises will normally go through an off-production lab testing and validation and likely to demand a maintenance window to apply changes, and have an opportunity to rollback, in the event of a problem occurring due to misconfiguration of one of the nodes; this could be as simple as a type in a script or a wrong port number triggering a loop on the network.

By moving to a services based architecture, focusing on point of services provisioning as opposed to a nodal model, customers finally gain the agility and simplicity they have been looking for. But moving CLI scripting to SDN programming does not necessarily deliver on customer’s   expectations. Hence why Avaya took a different approach by solving the control plane issues, while introducing at the edge of its architecture the ability to interface with other SDN controller while maintaining a simplified end to end protocol architecture.  

Avaya’s competitors for the most part are not enabling end to end services. The orchestration piece of SDN is what may bring this to reality, but how long will it take before the provisioning tools are sophisticated enough to achieve this across your entire enterprise? Do not lose sight of the same protocols being used, hence recovery times and risks associated with the multi-protocols approach from the legacy model is not going to magically disappear or improve.

By visualizing the enterprise and moving to a services based architecture, other virtualized network services defined as NFV can easily be integrated. Hence, a firewall service, a session border controller, etc. can easily be integrated with the already virtualized networking infrastructure. In addition, by moving away from nodal configuration, the risk of IP hoping and hacking is greatly reduced as Ethernet Topology is used to establish communications to IP services, contrary to other vendors that continue to go hop by hop.

Why there has not been any major deployment so far?
It is taking time to see major deployments because it takes time to build provisioning tools on the SDN controller. Like it took months and months of development for Telecom and mainly SP and SI to be able to provision MPLS services, we are seeing a similar outcome in the time it will take for customers to really see the benefit.

Over-passing the legacy system is still a huge challenge. Isn’t a kind of hybrid solution way forward?
SDN is about an evolution not a revolution. It is imperative that customers can maintain their current assets while evolving towards SDN, but it would be wrong to have vendors promote a forklift of their existing infrastructure to deliver on SDN promises. What other vendors are doing is building a parallel infrastructure, which does not deliver on a lower TCO. Customers need to carefully evaluate the various solutions.

Our SDN Fx Architecture provides a very smooth evolution and transition to SDN. SDN Fx supports the legacy protocols on the same nodes while running its Fabric Connect solutions, allowing customers to simultaneously run both the legacy model and the SDN enabled architecture. In addition to this, SDN Fx also introduced the concept of “Fabric Extend” which provides the ability to traverse any competitor’s network and even a carrier MPLS network over the WAN if required. The SDN Fx model therefore enables customers to transition to a new model without having to replace the current infrastructure. Leverage your current investment and use it as a transport for the new SDN infrastructure. Replacing is with new nodes will simply trigger huge cost which some vendors may favour but certainly not aligned with reduction of TCO.

Some vendors have attempted to commoditize Ethernet connectivity by devaluating the software. Is SDN all about CAPEX and OPEX?
You are right, some vendors have attempted to commoditize Ethernet connectivity by devaluating the software that vendors are developing to move to an open software architecture as promoted by SDN. While the cost of Ethernet connectivity will continue to be driven to lower price levels, enterprises have to realize it is not just about CAPEX.

There is a huge percentage of IT budget being spent on keeping the lights on. Hence, OPEX needs to  focus and by moving a complex distributed architecture based on nodal scripting configuration capabilities to a centralized complex programming architecture may not exactly achieve the outcome desired. In simpler terms, you don’t want to move from a distributed node by node configuration with the complex protocols, to a centralized provisioning tool that will in return push the same configuration and same complex protocols to each node of your network. 

Hence, Avaya is fully endorsing what SDN’s ultimate business objectives are, but customers will not be able to achieve their goals unless they substantially increase their skillset towards programming applications profiles as opposed to make it easier to enable services end to end.  Therefore customers need to evaluate options available to them and ensure they do not fall into a trap where they simply move the problems as opposed to solving the problems. Customers must move to a next generation network architecture to be able to achieve services and applications deployment agility. Moving the complexity around and calling it something different will not achieve the fundamental objectives expected by SDN.

Recently in India telecom service providers have spent huge amount of money to acquire spectrum, isn’t now there is limited scope for network modernisation or expansion, and the choice between either of those will have to be made judiciously?
I fundamentally believe Service Providers will make a substantial investment. They have to address the TTS (Time to Service) challenges. Just like MPLS which required months and months of development to build provisioning tools to mask and hide the great deal of complexity associated with it, the same journey has started with SDN. So, not surprising to see investment in these areas to address the Orchestration challenges associated with a transition to SDN. My position is, make it easier to enable services first, then focus your orchestration efforts in connecting the pieces together as opposed to try to develop complex applications profiling in the same client or server architecture with all of these complex protocols.

With the mass adoption of SDN, will the dynamic of contract change and what impact do you see for both operators and companies such as yours in the light of network as a service (NaaS) becoming the reality?
If it is about shifting to an OPEX model, the answer is absolutely. Service providers can no longer afford these huge CAPEX 3 to 5 year’s upgrade cycles that some of our competitors have been imposing. They want to move to a predictable per user, per usage or even simpler per month billing model. NaaS is a reality and customers need and want it. The good news is there are solutions such as SDN Fx which address the complexity and high OPEX we have been facing. So, operators should look at what is available before they throw their complexity over the fence for someone else to figure it out. Moving to OPEX makes sense, but my recommendation is to do it because the business needs it, not because operators cannot move at the business speed desired. My advice: Look for solutions addressing OPEX costs today, and then decide where you want your CAPEX to reside and from there, you will get the SLA’s your business needs

If you have an interesting article / experience / case study to share, please get in touch with us at [email protected]

Advertisement