Doug Marschke, CTO, SDN Essentials
By now, most people have heard about SDN (Software Defined Networking) in some way. It seems the market hype has been constant for 3 years now. I first heard about SDN while working for a Network Integrator in 2012, so where are we now, and have we actually progressed?
Let’s start at the basics first, the idea of SDN really spawned from the clean slate university research programs at Stanford and Berkley. At the time, they were trying to figure out, how we can “fix” the internet if we started with a clean slate. One topic that was discussed was the idea of a consistent policy across IP devices, whether that be a router, switch, firewall etc. Of course to have consistent policy requires a way to have a consistent per hop forwarding behavior, so during their research, they decided they needed a way to write entries directly to the forwarding table. At the time there was no easy way to do this across multiple vendors, so the idea of Open Flow was formed. This drove the architecture of “open sdn” with the separation of control and forwarding as depicted in Figure 1.
This certainly seemed like a good idea to many, but as they say, the devil is in the details. In order to make the architecture above successful, a few things have to fall in place:
1. Needed an Open Interface to the hardware
2. Need a good extensible operating system (controller)
3. Needed one or many well defined API.
Where are we now with this architecture? I would say we are about half way there. We do have 1 which is open interfaces to the hardware with a variety of protocols (Open Flow, NetConf, LISP, XMPP, BGP to name a few.
We are trying as an industry to find a good operating system, and there have been several stable commercial products created, as well as some open source projects taking shape. However despite a lot of PR, as an industry we have not decided on a set or controllers that fit this Open SDN architecture, and some argue that we never will as it is hard to find a “one size fits all” controller.
While the industry was working hard on above, two other common definitions of SDN come to the forefront, the first is the network overlay, and the second is what I called the vendor API. First, in figure 2 is a drawing on a network overlay. In the most simple terms, an SDN network overlay is a system designed to connect multiple logical networks (usually in the form of virtual machines) across a traditional 
IP/Ethernet underlay network. There are some common elements from the Open SDN architecture, including open north bound API’s and an SDN controller, however the largest difference is that the forwarding elements for thae underlay do not change and are mostly agnostic to the overlays. Today there are many vendors pushing the overlay architecture, and some very large deployed case studies. However, if we learn from history in networking, we know that overlays have a limited life shelf, whether it be Frame Relay, ATM or today’s favorite MPLS.
The third definition for SDN is what I called the vendor “Oh Oh” moment. With all the hype surrounding SDN, networking vendors decided that they better have a SDN story to win those RFP’s and so they decided on the architecture in figure 3. The vendors essentially created an API on their 
platform that allowed them to connect to some of the more popular controllers or orchestration system. This allowed them to have the “see if works story”. Although, this is a very important step into moving towards a more Open SDN architectures since most network deployments are not greenfield, this architecture has some serious scaling issues as well and creates a “proprietary openness”. In other words, many vendors just put an API to access features of their platform, and using shared memory space that made support of protocols (such as Open Flow) reach limitations fairly quickly.
So is SDN ready for prime time or ready for the trash heap before it is started? Open SDN as we would like to define it is not ready for mainstream yet, but there has been a tremendous amount of resources thrown at the problem, so I suspect we aren’t too far off in finally getting some more main stream acceptance. However today, there are some real immediate network problems to solve, so network overlays and Vendor API’s may be the Band-Aids that are required to have the programmability, automation and application awareness that is needed in order for the network to support the user. If we continue on the status quo then the traffic engineering, long provisioning, and excess capex spending will only get worse. Before you know it, the hype will be a reality that you are not ready for!
