SDN != OpenFlow
Lately there seems to be a lot of hype around software defined networking and in some of the articles OpenFlow is equated with SDN or vice versa. While OpenFlow has a role to play in SDN and it is what created the concept of SDN, I don't think it is accurate to think of SDN == OpenFlow. This post is my attempt to describe OpenFlow, SDN and why SDN != OpenFlow. This is important for us engineers as we need to focus on the right problems and solve them using the right technology, instead of getting distracted by the hype that we see or hear in the press.
Software Defined Networking
Why - The demand for cloud computing is increasing due to number connected devices and applications. Each XBOX One has 3 virtual servers in the cloud. There is tons of data stored in the cloud due to applications such as OneDrive, Facebook and others. This increased demand is putting a lot of pressure on the cloud datacenters to provide secure and reliable service while reducing their cost. The cost includes both capital expenses (CAPEX) and operational expenses (OPEX). Networking is a major contributor to the overall cost of the datacenter. This is due to many factors such as specialized hardware, vendor specific tools and slow pace of innovation. SDN brings the promise to solve this. SDN vision is to provide a software defined network that is cost effective and provides rapid innovation and operational flexibility. The larger vision is to have a software defined datacenter (SDD), however, the focus of this post is SDN and OpenFlow only.
What - There is no single definition for SDN. In fact, at times it seems that SDN is something that would solve world hunger (wishful thinking, but it won't). SDN has become an umbrella term that is used for anything and everything networking related. However, if you peel away the hype and marketing surrounding SDN (including my own above 
), you would see that SDN is a design concept or philosophy for building software for network management. And even though there is no single definition for SDN, there are a set of guiding principles in this design philosophy that most people seem to agree to. These principles are the key to understanding SDN.
1. Software
The first principle in the SDN is software i.e. doing things in software (as possible). This is an important principle because doing things in software bring tremendous flexibility. You can innovate and update it faster, you can run on different hardware etc. This is no different than what has happened to compute with server virtualization.
Virtualization has brought tremendous flexibility in running a large scale data center. Virtual Machines provides unprecedented flexibility such as ability to run multiple operating systems on a single physical machine, live migration from one physical server to another without dropping active TCP connections, being able to snapshot a running virtual machine, ability to dynamically adjust underlying resources available to the VM etc. Using software in networking can bring the same flexibility to networking. This includes things like network virtualization and network function virtualization, which would be topic of another post in the future.
2. Decoupling
The second principle in SDN is of decoupling or separation of functionality. This is not a new concept in itself, every software engineer know about modularity and decoupled functionality. Even in networking, the network stack is built in a modular fashion where there are different layers. In SDN, this decoupling is about dividing the overall network management into three distinct planes called management, control and data plane.
Management plane is responsible for coordinating among various subsystems of the datacenter like compute, storage and network, as well as taking user input and converting it to control plane constructs.
Control plane is the brain of the network and has the intelligence to make overall network function. It is responsible for configuration of data plane devices and ensuring overall functioning of the network.
Data plane represents networking devices (physical or virtual) that do the actual network packet processing. The data plane should provide high performance packet processing but should be relatively simpler (or have lesser intelligence) and do what is programmed by the control plane.
3. Standardization
The next principle of SDN is standardization. Once you decouple the network management into multiple layers, you would want a standard interface between these layers such that it is possible to replace one data plane device with another one or use different management applications such as OpenStack working with different network controllers etc. The interface exposed by the control plane is referred as northbound and the one exposed by data plane is referred as southbound interface.
While standards based interfaces are better, in many cases, an abstraction based approach is needed due to ecosystem diversity and differentiation. For example, OpenDaylight uses something called a SAL (service abstraction layer) to allow the control plane services to talk to different data plane devices that may support different feature sets or different protocols for configuration. This allows control plane services to be independent of diversity in underlying data plane interfaces. Now, as we know, maintaining such abstractions are hard long term, so standards based interfaces are better, but from practical standpoint that is hard to achieve given the realities of the market.
4. Centralization
The last principle of SDN is centralization of policy. This is one of the key principle of SDN because doing centralization of networking policy, you can treat the whole network as a single unit and allow control plane to program various devices in a coherent fashion. It removes the model of networking policy being scattered around various devices making the diagnostics of the network a nightmare and incurring significant operational overhead. Please note that the centralization is logical centralization i.e. even though control plane can be running on multiple systems in a distributed fashion, it is acting as a single unit. This logically centralized implementation of a control plane is typically called a network controller. One can implement network controller where it runs in a single server or it can run in a distributed fashion on multiple servers. However, it is one entity that manages the overall network and programming of networking devices. The centralization is not new, e.g. in an operating system, a kernel is a logically centralized entity comprising of various kernel modules. In fact, we can map an OS stack to SDN stack and see the similarities between the two.
From this picture, we can see that how in an operating system, the kernel is the brain that manages various devices, in an SDN stack, network controller is the brain and controls the overall network.
PS: Few months back a picture in an article motivated me to draw this picture above. I am not able to find the original article that had a similar picture in it. If anyone has seen that, I would love to put a reference to that article in this post.
OpenFlow
OpenFlow has its roots in project Ethane by Martin Casado that presents the idea of a logically centralized controller, which contains the network policy for all packets and switches in the network process packets based on this policy. Building upon this idea, OpenFlow specifications were developed. There are few key things that OpenFlow provides as described below.
1. Flow based Data Plane
OpenFlow provides policy configuration in the switches using a flow based rules. The advantage of this approach is that the policy application is consistent. It also allows an application to innovate in packet processing by chaining various flow rules based on their specific requirements. However, a flow based data plane is not necessary for SDN, it is just one more way in which data plane devices can configured. One can argue that flow based data plane approach is better, and while it is generally true, in specific cases, even that can be debated. For example, is flow based policy the most efficient representation? Does it provide the most efficient packet processing (at least in hardware switches)?
In many cases, flow based policies may not be best way to represent your packet processing rules, e.g. earlier versions of OpenFlow didn't have great story for ECMP and when this support was added, it was added via group types and not as flow rules or actions.
In the end, irrespective of whether flow based data plane is better or not, is orthogonal to SDN. SDN is about programming devices and whether a device supports OpenFlow or not, is immaterial.
2. Standards based Policy
OpenFlow provided a standard way to program switches, which is very nice. However, as I mentioned earlier, given the heterogeneous nature of the policy configuration and diverse ecosystem, an SDN based solution needs to support an abstraction layer (at least for foreseeable future). So while OpenFlow did push for standards based policy configuration, it is not mandatory for SDN and SDN is not tied to OpenFlow.
3. Controller based Design Concept
Ethane (and in turn OpenFlow) provides a conceptual model where the network state is kept in a logically centralized controller and various network devices obtain state from this controller for their packet processing. This I believe is the key concept that created the whole notion of SDN. However, again while Ethane created this design concept (and I think everyone would agree that its an awesome concept), it is a design concept, and like object oriented programming or other design concepts and is not tied to to a particular technology such as OpenFlow. In fact, most applications of this concept you see are not tied to OpenFlow, e.g. be it OpenDaylight Controller, Juniper Contrail, Cisco ACI and to some extent even NSX.
Closing Thoughts
Hopefully this article provided some clarity around SDN and its relation to OpenFlow. I would like to say though, that the role of SDN in simplifying network management is tremendous. With SDN, software becomes the entity where intelligence of the network lives. The policy application moves to virtual switches and networks get virtualized using network virtualization. An SDN controller ties all these together to manage network as a whole and provides autonomous network management where human intervention is needed only upon hardware failures. It can program 1000s of virtual switches, and keep their configuration consistent, which would be impractical to do manually. It can reduce the overall cost of networks (especially OPEX) significantly.
In such a world, where intelligence live in the virtual switches (or network edge), the role of physical network diminishes as well. I am sure, my hardware friends would disagree with me on diminishing role of hardware. They are right, this is not black and white. You still need hardware to carry your packets from one place to another, you may want to offload processing to hardware to meet the performance requirements, you may need hardware to bridge between physical and virtual world etc. However, the key change with SDN is that intelligence lies in the controller and hardware competes in terms of its processing capabilities. It is a step towards commoditization of networking hardware.
Future
We have been building an SDN solution for Windows and it is available in the Windows 10 Technical Preview, look for a new server role called Network Controller. Windows Network Controller (WNC) is designed as a scalable and highly reliable application that would let you manage physical and virtual networking elements. In a future post, I would describe the overall architecture of WNC and how it meets the reliability and scalability requirements using technologies such as Windows Fabric and techniques such as goal state (or desired state) based programming.
References