What the Hell is SDN?
By stretch | Thursday, May 2, 2013 at 6:20 p.m. UTC
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.)
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.
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.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Software-Defined Networking
May 2, 2013 at 7:26 p.m. UTC
"For example, you might SSH into the CLI of a router (the control plane)..."
Should that be management plane?
May 2, 2013 at 7:36 p.m. UTC
Fixed. Thanks for the heads up!
May 2, 2013 at 8:47 p.m. UTC
Just for reference, Ivan Pepelnjak blog (SDN label):
May 2, 2013 at 9:57 p.m. UTC
Great intro to SDN and OpenFlow. I've been out of the IT game for several months and I'm trying to play catch up with all of the latest happenings. I've been hearing a lot about SDN and OpenFlow and your explanation of both of those concepts was spot on.
Your writing and teaching style is superb. This article gives me a good base to launch out from and learn more.
You didn't touch on any of the disadvantages of SDN. My initial guess would be different controllers "seeing" the network in a different way. Is that valid?
What are some other concerns/disadvantages that you see with SDN? (If that's in a follow up or addendum to this post I can wait).
May 2, 2013 at 10:13 p.m. UTC
Thanks for the non-hyped post. I'm sick of the uber-hype that SDN/OpenFlow is getting right now. The only people doing anything in real life is Google and their R&D department is larger than many real-world production teams. All this while vendors and fanboys would have you believe you're already late to the game if you don't have it deployed.
May 3, 2013 at 12:57 a.m. UTC
@eboogie: I'm still learning a lot about SDN myself. The one glaring potential issue to me is what happens when the controller loses connectivity to one or several switches. Everything we know about failover goes out the window if nodes aren't capable of making their own forwarding decisions. Of course, we will likely see a lot of hybrid deployments where SDN is used for the management of specific flow types and everything else falls back to regular non-SDN switching.
I'm sure we'll see a lot of rapid development around SDN over the next year or two. And I'm happy to wait patiently and learn from others' mistakes.
May 3, 2013 at 1:33 p.m. UTC
I was part of an OpenFlow class in Jan 2012. The guys "teaching" it kept giving these scenarios of how it can work and even let us configure some HP switches with OpenFlow and a couple of different controllers. I at first thought this was going to be awesome, and then I started thinking, what happens if the controller falls over dead, or something like that. So, I asked the question and they said that bad things happen then. They mentioned at SC 2011 that they DOSed themselves when their controller crashed. Because all of the "Hey, what do I do with this flow?" started coming in at once and basically took down their entire OpenFlow network. They also said there is a 60 second default timer for flows. So, if they lose communication with the controller and a flow hasn't been seen in 60 seconds it times out. Then if that flow shows back up, it doesn't know what to do with it. OpenFlow has some serious maturing to do before I put it in anything production here. I know Internet 2 uses it alot, but I just don't trust it yet.
May 3, 2013 at 3:33 p.m. UTC
We've been told that onePK will indeed provide centralized and programmable management plane, but control plane remains distributed. Would you still classify this as "SDN"?
May 3, 2013 at 5:00 p.m. UTC
I work at a university. We're just now starting to roll it out for researchers. I don't want to support it. IT is terrible about providing training in general. I can see having to spend part of my already full day playing developer to leverage an API. Maybe I'm a Luddite but unless there's a very tangible return on it, I'm not convinced the human factor won't make it less than viable for most environments.
May 3, 2013 at 5:19 p.m. UTC
Good post - but I don't think your description of SDN is complete. If I can summerize, you defined SDN as:
- Seperation of Control Plane and Data Plane
- Based on OpenFlow
Utilizes a controller
You are missing the concept that an SDN network should be based on open standards. One of the founding goals of SDN was to be vendor agnostic. Thus an approach that relies on a proprietary set of APIs to communicate with the controller violates the spirit of SDN. We've seen vendors that have announced SDN approaches that are mostly proprietary - and that is not what the SDN movement is about.
OpenFlow is a means - but not necessarily the only means of communicating with the dataplane. Other approaches can and probably will enter the SDN ecosystem.
The controller too is part of the SDN - and it too should utiize an open set of APIs to communicate North/South with applications.
Orchstration, whether through OpenStack of CloudStack or vCloud Director should be part of the definition.
Vyatta (a Brocade Company)
May 3, 2013 at 6:57 p.m. UTC
Great write-up Stretch. As others have mentioned, it's hard to find straightforward, down to earth explanations of what SDN is and how it works and you've done that beautifully here. Greatly appreciated.
May 4, 2013 at 4:45 a.m. UTC
Wireless controllers are kind of SDN-s to me or check out Meraki Inc. cloud management - even if the switch/ap loses connectivity to the controller (cloud) it still keeps the forwarding table as is, you wont be able to do changes until you gain connectivity (an out of band management would help here)
I still think this is too early and it has been given an undeserved credit and hype over the past couple of months.
May 4, 2013 at 2:57 p.m. UTC
"...[OpenFlow] 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.)"
Hey Stretch, not sure whether this question was rhetorical or not, but it has been suggested elsewhere that this consortium grew out of a desire for greater control over the agility and [rapid] adoption of the protocol (and changes to it) than is commonly offered by today's standards bodies. That is my understanding anyway. Very good write-up!
May 6, 2013 at 7:33 p.m. UTC
So, in a layer 2 network, the SDN switches don't do STP and flooding anymore?
The forwarding is done entirely by the controller?
May 13, 2013 at 1:47 p.m. UTC
Good post Stretch, i want to learn about the mgmt-topology of SDN and redundancy ways of provide high availability of Controller-Agent connection?
Is anybody have opinion about it?
May 14, 2013 at 12:14 p.m. UTC
Interesting the timing how NetworkWorld posted an article on 5/13 after Stretch's on the same topic. As always I check packetlife.net first!
May 14, 2013 at 9:55 p.m. UTC
Well, with the controller as a Single Point o' Failure, one would assume that clustering or designating hot backups would help keep the chestnuts out of the fire. One would figure that such schemes would be forthcoming.
I'd be very interested to see what Cisco does with this, as that will have a great deal of influence on where SDN goes.
May 15, 2013 at 2:25 p.m. UTC
I think SDN's biggest competitor will be performance and price.
I have worked many years in telecoms and the vendors with the best management software solution is not what sells the most.
Does not matter if it saves work time and etc, is not that important selling point the the board rooms to sign the deals.
First step stone would need to be an industry standard requirement and second, it can't add more cost for the vendors to do so.
Google might have an advantage but i can't imagine them selling hardware to operators, but i could them to compete with what they got and develop to become a big ISP, even maybe a Tier1 if they decide to invest in it.
May 22, 2013 at 11:37 a.m. UTC
Thanks stretch and dschader for clearing my concept about SDN.
June 4, 2013 at 6:38 a.m. UTC
Great post Jeremy, very nicely articulated. I am excited to see what creative guys like you do with it. Like you said anyones guess, edge services are will be pretty fun.
June 10, 2013 at 11:31 a.m. UTC
would you mind signing up on flattr.com? I've been reading here for years and would like to give something back :)
June 10, 2013 at 3:11 p.m. UTC
I'll attend a SDN presentation in a couple of days. Meanwhile I'm under impression that SDN logic is much like good'ol' SS7 networks, or like H.225/H.245. Or like H.248/Megaco model.
Nothing [really] new under the sun :)
August 7, 2013 at 6:53 p.m. UTC
Didn't we go through this already with ATM? LES servers? and didn't we all drop ATM for Ethernet.
August 24, 2013 at 6:00 p.m. UTC
Good article, thanks Jeremy.