Enabling Self-Healing, Self-Optimizing Service Provider Networks: Part 2 of 3

Part one of this series outlined the challenges and opportunities facing service providers, including competition from public cloud providers, increasing demands for complex services from enterprises, and current management limitations of SDN. Service providers realize that they need to build lean networks to improve service agility, respond quickly to changing customer requirements, and offer new services. They are looking to SDN and NFV technologies to build elastic networks to help them compete in this new marketplace while keeping the cost of ownership down. This post will cover how SDN in the WAN is (or is not) evolving to be a viable solution.

The Evolution of WAN SDN

Major service providers are leading the effort to drive requirements for next-generation networks based on SDN and NFV. By building flexible architectures based on virtualization and overlays to decouple services from infrastructure, they can deploy and scale a variety of services using the following approaches:

• Service-centric: Focus on services, not protocols. Intelligence is pushed from custom hardware into software.
• Decoupled control and data planes: Select the best available control plane from one vendor and hardware with the highest port density from another.
• Open interfaces: Drive ecosystem-wide innovation and avoid vendor lock-in.
• Enhanced management: Leverage network telemetry and analytics to drive key network management decisions in real time.

Here is how vendors and service providers are trying to get there.

Hybrid WAN SDN Approach 

In current WAN SDN environments, equipment vendors such as Cisco and Juniper Networks support a hybrid WAN SDN approach, where devices and SDN controllers share responsibility for the control plane. This approach is a compromise, because it does not accomplish complete control plane and data plane separation. In this architecture, service providers run simple IP/MPLS networks with IGP, BGP, and LDP control protocols and push the complex functionality of traffic engineering to applications.

The SDN controllers, just like routers, participate in the control plane of the network through BGP-LS. BGP-LS is a BGP extension that distributes IGP link-state information across multiple domains. This architecture enables controllers to discover the network in semi-real time and sends this information to applications. This approach is incomplete, however, because there are no analytics describing end-user services, traffic levels, path, and route changes. Without this management intelligence, network professionals are blind and cannot adequately troubleshoot issues or plan for network changes.

Controlling the Controllers

Controllers are a strategic component of the SDN ecosystem. The equipment vendors and service providers are equally vested in successful evolution of controllers. Although each large equipment vendor started investing in a proprietary controller, the market is warming to the idea of using open source controllers. The two most popular available alternatives are OpenDayLight (ODL) and Open Networking Operating System (ONOS). Both part of the Linux Foundation, these controllers will benefit from community participation to significantly enhance capabilities. The ODL has released Lithium, which is third generation software, and ONOS has released Drake, which is fourth generation software. These controllers are starting to move out of the lab environment and into field trials as well as into the production environments of service provider and enterprise networks.

The vendors have reversed their initial investment in building proprietary WAN controllers to back one of the two available open controller initiatives. Cisco and Brocade have released hardened versions of the ODL controller with bundled support services, which greatly accelerates the adoption of these controllers. Vendors such as Ciena, Ericsson, Fujitsu, Huawei, Intel, Infinera, and NEC have also launched SDN ecosystems around these controllers.

Controller Standards Issues

The most essential component of controllers is programmability, but unfortunately, it is the trickiest aspect for WAN SDN. Path Computation Element Protocol (PCEP), BGP Link State Distribution (BGP-LS), NetConf/YANG, and I2RS are various draft level standards available for WAN controllers to control the equipment.

With all these standards in various stages of development, service providers attempting to build SDN solutions will face major interoperability challenges. Major vendors might resort to implementing time-to-market extensions to go to market fast. For instance, although PCEP standards are available for basic state full-tunnel provisioning, the standards for extensions are still in the draft stage. Each equipment vendor has vendor-specific extensions that might not interoperate. This lack of standardization ties the fate of controllers to vendor routing software and presents the biggest threat to SDN adoption. Furthermore, the standards for programming basic traffic steering and orchestrating complex services such as VPN are not available.

Exacerbating all this is the need for service providers to deploy multiple controllers to manage their multi-vendor networks. The third and final article in this series will examine this challenge of architecting controllers and some solutions to fulfilling the promise of SDN.