As recent posts on this blog attest, I have been thinking a lot lately about software defined networking (SDN). I’m not alone in that regard, and I’m no doubt behind the curve. Some impressive intellects and astute minds are active in SDN, and I merely do my best to keep up and try to assimilate what I learn from them.
I must admit, I find it a difficult task. Not only is the SDN technical community advancing quickly, propelling the technology forward at a fast pace, but the market has begun to take shape, with new product launches and commercial deployments occurring nearly every week.
Lately, I’ve turned my mind to controllers and their place in the SDN universe. I’ve drawn some conclusions that will be obvious to any habitué of the SDN realm, but that I hope might be useful to others trying, as I am, to capture a reasonably clear snapshot of where things stand. (We’ll need to keep taking snapshots, of course, but that’s always the case with emerging technologies, not just with SDN.)
To understand the role of controllers within the context of SDN, it helps to have analogies. Fortunately, those analogies have been provided by SDN thought leaders such as Nick McKeown, Scott Schenker, Martin Casado, and many others. This blog, as you know, has not been especially replete with pictures or diagrams, but I feel it necessary to point you to a few on this occasion. As such, feel free to consult this presentation by Nick McKeown; it contains several diagrams that vividly illustrate the controller’s (and the control layer’s) key role in SDN.
The controller is akin to a computer’s operating system (a network-control operating system, if you will) on which applications are written. It communicates with the underlying network hardware (switches and routers) through a protocol such as OpenFlow. Different types of SDN controller software, then, are analogous, in certain respects, to Windows, Linux, and Mac OS X., What’s more, just like those computer-based operating systems, today’s controller software is not interoperable.
Not Just OpenFlow
Given what I’ve just written, one ought to choose one’s controller with particular care. Everything I’ve read — please correct me if I’m wrong, SDN cognoscenti — suggests it won’t necessarily be easy to shift your development and programming efforts, not to mention your network applications, seamlessly from one controller to another. (Yes, development and programming, because the whole idea of SDN is to create abstractions that make the network programmable and software defined — or “driven,” as the IETF would have it.)
Moreover — and I think this is potentially important — we hear a lot of talk about “OpenFlow controllers,” but at least some SDN controllers can be (and are) conversant in protocols and mechanisms that extend beyond OpenFlow.
In fact, in a blog post this past August, Nicira’s Martin Casado distinguished between OpenFlow controllers and what he called “general SDN controllers,” which he defined as those “in which the control application is fully decoupled from both the underlying protocol(s) communicating with the switches, and the protocol(s) exchanging state between controller instances (assuming the controllers can run in a cluster).”
That’s significant. As much as OpenFlow and SDN have been conflated and intertwined in the minds of many, we need to understand that SDN controllers are at higher layer of network abstraction, providing a platform for network applications and a foundation for networking programmability. OpenFlow is just an underlying protocol that facilitates interaction between the controller and data-forwarding tables on switches. Some controllers leverage OpenFlow exclusively, and others are (or will be) capable of accommodating other protocols and mechanisms to achieve the same practical result.
An example is Onix, the controller proffered by Nicira. In a paper that is available online, the authors specify the following:
“The Onix design does not dictate a particular protocol for managing network element forwarding state. Rather, the primary interface to the application is the NIB, and any suitable protocol supported by the elements in the network can be used under the covers to keep the NIB entities in sync with the actual network state.”
To be sure, Onix supports OpenFlow, but it also supports “multiple controller/switch protocols (including OpenFlow),” according to Casado’s aforementioned blog post.
There are a number of controllers available, of course, including NEC’s ProgrammableFlow Controller Appliance and Big Switch Networks’ Floodlight, among others. NEC sells its controller for a list price of $75,000 and it has IBM as a partner, presumably to help enterprises get up and running with SDN implementations in exchange for professional-services fees.
But this brief post here isn’t intended to provide an enumeration and evaluation of the available SDN controllers on the marketplace. I’m not up to that job, and I respectfully defer the task to those with a lot more technical acumen than I possess. What I want to emphasize here is that the abstractions and platform support provided by an SDN controller qualify it as a critical component of the SDN design architecture, all the more so because controllers lack interoperability, at least for now.
As Nicira’s Casado wrote last spring, “ you most likely will not have interoperability at the controller level (unless a standardized software platform was introduced).”
So, think carefully about the controller. While the OpenFlow protocol provides essentially the same functionality regardless of the context in which it is used, the controller is a different story. There will be dominant controllers, niche controllers, controllers that are more scalable than others (perhaps with the help of applications that run on them), and there will be those that emerge as best of class for service providers, high-performance computing (HPC), and data centers, respectively.
There will be a lot riding on your controller, in more ways than one.