What the Hell is SDN?

If you follow any number of news feeds or vendor accounts on Twitter, you've no doubt noticed the term "software-defined networking" or SDN popping up more and more lately. Depending on whom you believe, SDN is either the most important industry revolution since Ethernet or merely the latest marketing buzzword (the truth, of course, probably falls somewhere in between). Few people from either camp, however, take the time to explain what SDN actually means. This is chiefly because the term is so new and different parties have been stretching it to encompass varying definitions which serve their own agendas. The phrase "software-defined networking" only became popular over roughly the past eighteen months or so.

So what the hell is it? Before we can appreciate the concept of SDN, we must first examine how current networks function. Each of the many processes of a router or switch can be assigned to one of three conceptual planes of operation:

• Forwarding Plane - Moves packets from input to output
• Control Plane - Determines how packets should be forwarded
• Management Plane - Methods of configuring the control plane (CLI, SNMP, etc.)

For example, you might SSH into the CLI of a router (the management plane) and configure EIGRP to exchange routing information with neighbors (the control plane), which gets installed into its local CEF table (the forwarding plane). All of these operations occur within the same device, and each node in the network operates autonomously to make its own forwarding decisions based on its local configuration. It's critical to recognize that, although this allows for highly dynamic and automatic forwarding decisions through the use of robust protocols, the end result is ultimately dependent on each node's independent configuration. For the purposes of establishing context, we can think of this as administratively-defined networking.

In the simplest possible terms, SDN entails the decoupling of the control plane from the forwarding plane and offloads its functions to a centralized controller. Rather than each node in the network making its own forwarding decisions, a centralized software-based controller (likely running on commodity server hardware) is responsible for instructing subordinate hardware nodes on how to forward traffic. Because the controller effectively maintains the forwarding tables on all nodes across the network, SDN-enabled nodes don't need to run control protocols among themselves and instead rely upon the controller to make all forwarding decisions for them. The network, as such, is said to be defined by software running on the controller.

(The term "software-defined" was probably not the best choice to convey this concept, since routers and switches of course already run software like any other reasonably complex computer system. "Controller-defined" or "centralized control" would in my opinion have been more appropriate, but I suppose it's too late to change it now.)

Why SDN?

So what could we gain by migrating from a distributed control plane to a centralized one? One major benefit of centralizing the control plane is allowing forwarding decisions to be made globally across the SDN domain rather than at each hop. For example, imagine a layer two switching topology with redundant paths. Normally, spanning tree (a control plane process) is needed to guard against loops because no individual switch knows what the entire network looks like. However, if the control plane functions for all switches are offloaded to a central controller, that controller can "see" the entire network and install forwarding decisions to each subordinate switch based upon the desired end-to-end path for each destination or flow while keeping all links active.

Another advantage of having a central controller is that we can provide a convenient programming interface to allow other applications to control network resources and influence forwarding decisions. As a hypothetical example, when a virtual machine is moved from one physical host to another, the controller could be automatically instructed to migrate any associated firewall or QoS policies (which are enforced in the forwarding plane) on the network side along with it. This removes the need for a human administrator to statically reconfigure network resources and allows the entire network to operate more fluidly.

OpenFlow

SDN and OpenFlow are often used (incorrectly) interchangeably, leading to much confusion. Whereas SDN is an abstract concept, OpenFlow is an over-the-wire protocol like IP and TCP with explicit specifications and behaviors. In fact, OpenFlow is just one of several burgeoning approaches to SDN. Cisco's OnePK, for instance, is another approach, and there are no doubt others out there I haven't heard of yet. But to keep things simple for now, we'll limit our discussion to OpenFlow.

The word "open" in OpenFlow signifies its status as an open standard, as in "open source." The first iteration of the protocol originated out of a research project at Stanford University back in 2008 (you can read the original white paper here) but has since been adopted as an open standard housed by the OpenFlow Consortium. (Why this initiative needed an independent parent body is unclear to me. It would seem that an IETF RFC or two would suffice for the purposes of standardizing the protocol.)

The OpenFlow specification (version 1.1.0 at the time of this writing) details the structure of flow tables and over-the-wire communication. At a low level, an OpenFlow controller can install arbitrary forwarding table entries into an OpenFlow switch. Traffic flows can be matched based on a number of attributes, similar to filtering with an access list. As a simple example, a controller might install forwarding information on nodes across a layer two domain to ensure that a specific flow from host X to host Y follows a specific path across the network.

To implement OpenFlow, you need a minimum of two things: an OpenFlow controller, and an OpenFlow-enabled switch. There are a number of controllers available, some open source and others commercial products. The OpenFlow Consortium has a list of several here. It's important to realize that SDN as a concept is still just barely getting off the ground, and it will take a good year or two for market leaders and best practices to emerge, so don't fret about familiarizing yourself with every candidate just yet. The OpenDaylight project (launched just last month) has seen involvement by a number of major vendors and looks promising. Brent Salisbury has a great tutorial on OpenDaylight installed on Ubuntu controlling a Mininet software switch that helps illustrate the fundamentals of SDN flow control.

Given that the protocol is still in its infancy, most OpenFlow-capable switches currently available are software-based proofs of concept. However, OpenFlow support is quickly making its way onto hardware switches by way of hardware refreshes and firmware updates through industry leaders including HP, IBM, Arista, and others.

The Near-Term Future

The SDN revolution today is extremely turbulent. Presently, its development is focused heavily on the large data center and virtualization space. It may very well evolve into a useful tool for the enterprise and service provider space in the future, but there's a lot of work that needs doing by everyone involved before that can happen. Personally, I'm keeping an eye on my news feeds, waiting to see some successful implementations and case studies before I start digging too deep into SDN. It will be interesting to see where this leads.