Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Lifting the Cloud Over SDN: A LightReading Blog by Sunil Khandekar

A Blog by Sunil Khandekar, founder and CEO of Nuage Networks, an Alcatel-Lucent venture. Also posted on LightReading.

Software-defined networking (SDN) must be magic. Why else would researchers, educators, vendors, customers — practically everyone and anyone connected to the networking industry — be so high on SDN?

The answer, of course, lies in the promise of SDN. After all, isn’t it supposed to completely transform networking? Isn’t it the innovation that has finally rescued the networking industry after a decade-long drought? And, most importantly, isn’t the SDN market forecast to generate tens of billions of dollars — an estimate being raised every month? (See Defining SDN & NFV.)

The cloud over SDN

Interestingly, everyone has their own definition of SDN and their own take on how it will reshape the networking industry. That’s not entirely surprising. The term is broad enough to allow everyone’s convenient interpretation to stand. The industry has made progress in moving beyond hype, and customers are now asking how SDN will help them, rather than what SDN is. Nevertheless, there is still a fair amount of confusion, which causes doubt and constricts the real progress that SDN stands to deliver. It is time to lift the cloud over SDN. (Take a peek at the deck from MPLS SDN World 2014.)


The ultimate goal of an SDN solution is to massively simplify network operations, increase agility, and accelerate deployment of new services without sacrificing security and control.


The four key tenets of an SDN solution are abstraction, automation, control, and visibility.

SDN bridges the gap between applications and networks to enable the rapid consumption of network services such as bandwidth, QoS, security, firewall, and load balancing by providing visibility and control to the applications. It is about providing abstraction of network capabilities, and it is about the automation of network provisioning. It is about separating what applications need from how the network implements its capabilities.

In order to lift the cloud over SDN, we need to understand how various implementations of “SDN” currently promoted across our industry measure up against these defining characteristics of SDN.

1. Does SDN = OpenFlow?

Discussion of separating the control and data planes took off when the Open Networking Foundation introduced the OpenFlow protocol version 1.1 circa 2011. Normally, the control and forwarding planes are part of the same network switch or router. But the ONF advocated separating and logically centralizing the control plane from the forwarding plane. The forwarding plane would remain part of the network element — in other words, the switch or router. The ONF introduced OpenFlow as the southbound protocol used by the control plane to program reachability information in the forwarding elements.

Separating the control plane and the forwarding plane was not new. It had been done a decade ago in routers, though both functions still resided in the same physical device. The idea of physically separating the two planes and logically centralizing the control plane is not new, either. It had been already proposed in prior work, such as IETF ForCES initiative. But the industry took note of the revived efforts this time around, and the idea opened up interesting possibilities. Benefits included the ability to conduct control plane upgrades that did not disrupt network forwarding, centralizing the control plane to enable traffic optimizations based on a network-wide view (vs. network-element views), and removing the burden of processor-intensive distributed control protocols from lightweight network elements: virtual switches, CPEs, etc.

However, the overt focus on the separation of the control and forwarding planes and the shiny new OpenFlow protocol diverted attention away from SDN. The separation of the control and forwarding planes created the notion that all forwarding elements could be made simpler and cheaper. It is absolutely true that the networking requirements in campus and data center networks have traditionally not been nearly as stringent as required in the WAN. As a result, the premium attached to these devices have not been justified. The “white-box” discussion that ensued in the industry and drove down the cost of networking devices commensurate with networking requirements has been great for customers. This change has been long overdue. It was tempting for some to apply the same broad brush everywhere and suggest that all networking elements, including WAN core and edge routers, could also be simplified. This caused some confusion in the industry, which has largely settled now.

To be clear, this approach — separating the control and forwarding planes — falls short when measured against the four tenets of SDN discussed before. Though it provides control over forwarding elements under the OF controller domain, it does not deliver against the other three tenets: visibility into applications, abstraction of networking capabilities, and network automation.

However, the long-overdue change that caused pricing structures to change in the networking industry is nothing but goodness, and the ONF deservedly gets the credit for this.

2. Does SDN = traffic engineering?

The often-cited case study of Google’s SDN implementation for the purpose of traffic engineering the network is certainly interesting. The Google implementation is about computing optimal paths for the network using an offline compute tool and then programming these paths in network elements using OpenFlow. This approach affords Google full control and visibility over the network infrastructure. But it is not the first such implementation, nor is it new by any means.

The (former) MCI network team members must get a chuckle out of this, because they did exactly the same thing 14 years ago. The one difference? They did not use OpenFlow as the southbound protocol. Instead, they used MPLS labels for traffic engineered paths computed with an offline traffic engineering (TE) engine, now called a path computation element (PCE) server, which were programmed using SNMP in their network elements. Yes, this was back in Y2K.

Is this SDN? Yes, if you consider the separation of control and forwarding elements as the key definitional component of SDN. Yes, if you consider control and visibility being the key elements of an SDN solution, giving Google the ability to run its network hotter by utilizing network links to its capacity by balancing load optimally without sacrificing the SLA of its applications.

This particular implementation by Google focuses on the control and visibility aspects of the SDN and not as much on the abstraction and automation, which are the other two tenets of SDN. Additionally, Google has added and adapted OF with fairly extensive proprietary extensions and built its own TE application, which is used in the closed environment to optimize its own network.

3. Does SDN = next-generation element management system?

Imagine a cloud-based network management platform that provides the capability to provision networking elements from different vendors using various southbound protocols such as SNMP, CLI, XML, and, of course, the shiny new OF. Wow. Yes, that is the only word that comes to the mind of a network engineer who has known nothing but CLI or has had to rely on an element management system (a.k.a. GUI-based CLI) that was not multi-vendor.

No wonder some startups that provide such multi-vendor network management systems are getting attention, in part because incumbent and well-established networking vendors have steadfastly built and propagated mono-vendor provisioning tools. All this time, the burden has been on the customer to stitch these multi-vendor EMS platforms together. Once again, even though this development is goodness, it is quite amazing when you consider that this innovation happened under the auspices of SDN. To be clear, this implementation of SDN also falls short when measured against the four tenets.

Does this provide more control and visibility? Perhaps — it can provision multi-vendor devices. Does this provide business agility? Not really. At best, it enhances the present mode of operations, to an extent.

It is time for the real SDN to stand up.

SDN = a new approach to networking
To meet the demands and promise of cloud computing, it is critical for the networking industry to deliver a way to automate networks and make them as consumable, agile, and responsive as compute has become. This requires a complete rethink and a new approach to networking — an approach that viewsapplication delivery as the product, rather than the network as the product.

This approach requires a shift in two fundamentals dimensions. The first isabstraction of network resources and capabilities in a way that dramatically changes how applications interact with the network. IT admins should be able to declare desired networking behaviors in a simple and IT-friendly language without worrying about how the network implements such behaviors.

The second dimension is automation of network services for all applications in a way that makes network provisioning zero-touch and hence error free. SDN requires an automated framework that instructs the network to provision itself based on the needs of the application workload, rather than device-by-device provisioning of every network resource.

However, abstraction of network capabilities and automation of network provisioning are not enough, even though they are fundamental. It is also critical to provide network and IT admins complete control over all users, applications, and workloads and full visibility into the network for performance and operations, administration, and maintenance (OA&M), regardless of the location of the workloads. The network needs to allow resource access and consumption based on permissions granted with a global policy framework. Visibility must provide critical and necessary data on the performance of the network, the usage of the network by applications and by users, and the tools to troubleshoot and debug network problems.

In the end, it is all about providing end users access to their data at any time, in any place, and in any cloud and for the network/IT admins to build a network that is highly automated and scales to meet the demands.

As we as an industry move forward with adopting SDN, we must not lose sight of why SDN holds so much promise. It cannot be about some new protocol or an optimized network management system that at best improves the status quo but generally fails to drive a technological quantum leap. SDN must drive new capabilities not present in current networking approaches. It must enable new application ecosystems and network service offerings while introducing significant operational model efficiencies. Any solution that falls short of delivering on any of these fronts should be carefully re-examined. Chances are it’s more of the same — just re-badged as SDN.

— Sunil Khandekar is founder and CEO of Nuage Networks, an Alcatel-Lucent venture.

Read more by Sunil Khandekar here.

Follow Sunil on Twitter! 


The Nuage site uses cookies. By using this site, you are agreeing to our Privacy Policy.