SDN architectures

SDN Nirvana Still a Distant Dream (Part 1)

Every few years, the communication industry likes to come up with a bunch of new acronyms and buzzwords. It helps to rejuvenate an otherwise boring industry. After a torrent of buzzwords such as IMS, SDP, CEM, Big Data, etc., the latest acronym to make the rounds is software-defined networking (SDN). Like all these acronyms, SDN also promises unprecedented benefits for the world of communications. The vendor community is obviously overjoyed. For startups, it is an exciting acronym to attach their name to in order to increase their market valuation, impress VCs and private equities and look for a profitable exit strategy. Every single communications trade show is buzzing with the network virtualization and SDN theme, with people excitedly discussing the merits of SDN. However, our research says that from an operator standpoint, it will easily take another three to five years before we see large-scale, carrier-level adoption of SDN. In this two-part blog, I will try to explain some of the key bottlenecks that need to be resolved in order for SDN to be successful. SDN Requires a Paradigm Shift in the Network
First and foremost is the fact that operators are used to buying network devices from vendors, where network intelligence residing on the control plane is tightly wound with network devices. Hence increasing capacity and adding new network infrastructure also means operators have to invest in expensive software upgrades, etc., which becomes expensive and time-consuming. Most network vendors use proprietary protocols, which creates a black-box scenario. Although this proprietary approach provides competitive differentiation to equipment vendors, it makes most operators' overall network infrastructure complex, static, expensive and over-dependent on vendors. At the heart of the SDN concept is de-layering, and separating and consolidating the network intelligence-related control plane functions as a centralized controller for physical switching, packet forwarding and lookup. This de-layering allows operators to just enhance their capacity and storage without having to invest in software upgrades and network intelligence-related expenses. However, this paradigm shift brings major cost imperatives for operators, which have made tremendous investment in their legacy networks for many years now. Completely forklifting their existing network infrastructure in favor of SDN does not make economic sense for operators. The other aspect of SDN that needs attention is the northbound API, which connects the controller to SDN applications. The northbound API provides a mechanism in the SDN architecture to present services or applications to the business, and this is an area that still needs a lot of work. The lack of standards and limited work done around northbound APIs is not going to help the case for SDN. Creating a standard API will not be an easy task, as different applications will have unique bandwidth and latency requirements. Hence, either the base API will need to accept incremental runtime parameters to support different applications, or different APIs will be needed to support different applications. Many of these constraints need to be resolved before SDN becomes mainstream. In my opinion, in the medium term, we will witness a plethora of SDN lab trials by operators as well as a few strategic implementations of a hybrid SDN strategy. SDN Needs a New Type of OSS
From a service-fulfillment standpoint, the challenges can be very interesting. SDN's goal is centralized management and control of networking devices from multiple vendors in order to improve automation and management by using common APIs to abstract the underlying networking details from the orchestration and provisioning systems and applications. Operators today have multiple siloed fulfillment stacks that lack end-to-end network device management or configuration management capability. In fact, most service fulfillment offerings in the market lack a horizontal service-centric device management capability. This prevents service providers from having an end-to-end view of network devices, the services running on those devices and the customers and applications that are impacted. When a device supports multiple network services, each service requires some portion of the shared resource of the device to build and maintain each network service. Typically, the rollout of a new service or even a change in the network requires multiple changes to multiple devices. Service-centric configuration management will play a pivotal role, as it can provide the horizontal capability that handles design, management and specification changes across all devices on the network and manage the SDN layer, which is divided into applications that deliver services, such as switch/network virtualization, firewalls and flow balancers. In order to automate an SDN-type environment, the OSS systems need to federate and work in close proximity with SDN controllers, which would require a complex orchestration layer that can offer service-centric configuration management, discover network resources, implement policies and possess flexible resource management functionality. Building this orchestration layer on top of operators' existing service fulfillment systems will be complex, expensive and time-consuming. SDN Demands a Common Foundation for Fulfillment and Assurance
End-to-end service lifecycle management will be critical for the success of SDN. It will again start from service-centric configuration management, which needs to provide detailed device-level information to both fulfillment and assurance. Understanding the impact of a single network parameter change to underlying services and subscribers is not possible without close alignment of configuration management with fulfillment and assurance. It is therefore critical for solutions to be able to view services and applications in the context of the end-to-end infrastructure over which they are provided and be capable of adapting to dynamic changes. Without that, it will be impossible for operators to keep pace with the consistent change and dynamism introduced by SDN applications. A single and central view of subscribers, their provisioned services, the devices on which services or applications are running and their interactions with network resources is the only way to provide a customer-centric view of products and services. It is critical to close the gap between service fulfillment and assurance, which will enable providers to reuse interfaces and process fragments that can subsequently be triggered in either the service fulfillment or assurance context. In most operator environments today, there is a disconnect between service fulfillment and service assurance that permeates all aspects of service provider operations, including business and operational processes, departments and people supporting the fulfillment and assurance functions separately. SDN demands a blurring of the lines between assurance and fulfillment functions, which means change in operators' organizational structures -- never a trivial endeavor. Conclusion
SDN promises a lot of benefits, and it has the potential to bring major capex and opex benefits for operators. However, it comes with its own challenges and issues that need to be ironed out before it can be successfully deployed in brownfield operator environments. In part 2 of this blog, I will discuss other critical challenges that can negatively impact adoption of SDN. Please also watch for more upcoming reports on this topic at the Heavy Reading SPIT Total Access website. – Ari Banerjee, Senior Analyst, Heavy Reading