Abel Tong is part of Ciena's new Blue Planet division and is responsible for helping network operators transform their networks by leveraging Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create new services and deliver higher-order value while simplifying their network operations.  Next month Abel will be part of several presentations and panel sessions at the IIR Network Virtualization Forum in Madrid.

While NFV has largely owned the network virtualization industry spotlight of late, there is a rising tide of interest around configuration management and provisioning of third party equipment. Why? There are a number of reasons, but most importantly, resolving this issue allows service providers to stitch network services and virtual services together from one software interface. This is the Holy Grail for network operators in being able to rapidly deliver, create, and deploy new revenue services on top of their existing network infrastructure.

But most vendors only view this problem by looking at the tip of the iceberg and without addressing the mass that lies beneath the water. Let me explain.

Recently, Blue Planet announced third-party configuration management and provisioning support for Cisco ASRs and Juniper MXs.

After the announcement we heard some interesting comments, including this one posted to Light Reading’s "Cisco, Juniper Land on Cyan's [Ciena’s] Blue Planet" article:

"In the past, I have done integration by buying a product and getting the manual. It is very possible to do this with both Cisco and Juniper. CLI is not magic its just a format for commands which Cisco and Juniper publish.” 

This reflects the conventional thinking of many legacy network operators. While understanding the CLI language and interpreting CLI commands is straightforward, the real issue is a lack of programmability and the complexity CLI introduces into the operational paradigm.

Today’s operators and OSS automation tools would typically use collections of custom, hand-built CLI scripts to help with the configuration of Cisco and Juniper devices. The initial creation of the CLI scripts is challenging, but over time, new services, new functionality, and new software releases come into play. Each time this happens, some non-deterministic subset of scripts need updating. In other words, the work required when making changes involves reassessing every script, which is complicated and time consuming. The fundamental issue here is CLI and the problems associated with managing updates and change through CLI.

Evolving Beyond the CLI

There are other, better-suited SDN approaches. Some SDN vendors have implemented code-based adapters, as code can make a given adapter more robust and more feature-rich with the ability to interact directly with the device and make real-time decision.

However, a code-based approach means any changes to the system or functionality require code “changes.” Those required code changes mean that the speed at which a service provider can make changes is limited by the speed with which an SDN vendor can release code.

Other controllers have developed model-driven approaches. Being model-driven means changes can be made at run-time. So, while model-driven approaches provide flexibility, these approaches may also be limited in the depth of functionality supported, their ability to make real-time decisions based on stateful information, and the extent to which they handle exceptions.

The Benefits of a Resource Adapter Architecture

In the case of announcing Cisco and Juniper support with Ciena’s Blue Planet, Ciena also introduced a powerful, new, template-driven SDN and Resource Adapter (RA) architecture. This RA architecture addresses key challenges in the multi-vendor, dynamic networks environment that many of our competitors don’t yet understand. The RA provides a formal abstraction method (i.e., describing what it is you want to manage), and also provides a uniform interface or API (i.e., describing what you can do with it).

CLI lives within the body of an RA and carries out RA functionality. In order to be multi-vendor, an SDN controller runs multiple RAs, which in turn support different vendors and different equipment types. This means that RAs must provide multi-protocol support. In addition to CLI, Blue Planet RAs support OpenFlow, REST, SNMP, TL1, and NETCONF. Further, RAs must provide intelligent multi-version support.

For example, an operator might have a network with Cisco IOS 12.4 across the majority the network but also have a few new or upgraded nodes running the latest IOS Release 15. And finally, adaption must be handled automatically. In other words, as Blue Planet automatically discovers devices, the right RAs need to apply to each underlying device.

Here is another comment from the same Light Reading article:

"I believe that would have to have some cooperation from the legacy equipment vendor in order to write the RAs to enable BP [Blue Planet] to control their elements. Otherwise, BP would only be able to monitor those elements through SNMP. This is what I think, but it's possible they came up with a new way to do it without any input from the legacy vendor."

Cooperation from a legacy equipment vendor is a “nice to have”.  However, in-depth understanding of what a service provider wants to do and how it needs to be implemented is the real “must have”.

Consider offerings of Layer 2 Carrier Ethernet and Layer 3 VPN services. Service providers (SPs) maintain high-level service definitions, which make the services comprehensible and consumable. Definitions are typically straightforward (i.e., the collection of end-points being interconnected and the bandwidth between them), but the devil is in the details. Layer 2 services could have options for performance, quality of service (QoS), and protection switching schemes, while Layer 3 services can have options around Internet access, routing, and discovery protocols.

Essentially, no two SPs offer exactly the same service or deliver services in exactly the same way, so the SDN controller has to adapt. Also, over time, the services, service options, and even equipment used to deliver these services change. A service provider must be able to integrate changes as needed on the SP’s timeline. They cannot wait for an SDN controller or equipment vendor’s software release cycle.

Again, the Blue Planet SDN and RA architecture makes service adaptation possible. Blue Planet provides a service layer abstraction that makes provisioning and management simple and easy. However, at the same time, Blue Planet is flexible, allowing for variations in a service and customization.

Further, consider a case where a service provider deploys a special network element with key and differentiating functionality. For example, a new Ethernet device might provide the latest MEF standard hierarchical QoS (HQoS). With Blue Planet, the service provider can extend their service definition, update the RA transformation and take full advantage by offering the differentiating feature set wherever and whenever the new device is available.

There are clearly many choices when it comes SDN controllers today. Every controller supports multiple vendors; however, multi-vendor support is not as simplistic as many would make it out to be. Take a closer look.

Here’s one more comment from a happy Blue Planet user who is leveraging Blue Planet APIs and RAs to deliver dynamic, on-demand and elastic services: "You guys rock!"

Thank you! We appreciate the feedback. Hopefully, the rest of the industry will take a closer look versus hitting the proverbial iceberg.