Nah Mate, That Ain’t A Controller… THIS is a Controller

Contributed by Rob Sherwood – CTO of Controller Technologies at Big Switch Networks.

I’m hearing more and more about SDN “controllers” these days.

Tech Execs at big networking companies are talking about delivering controllers in coming years. And I still see interesting projects emerging from academic institutions. Even Lua students can now experiment with OpenFlow controllers. In general, this is a good thing and I’m happy to see it.

It somewhat reminds me of the 
early days of operating systems — it seems everyone is writing one, and
 there is a lot of difference between them.  I think of it like the
 difference between the rather trivial operating system that a computer 
science undergrad writes in her senior-level operating systems class vs. a 
fully functioning commercially supported operating system like Mac OSX or 
even a popular, well-tested open source operating system like Linux. Is
 “while(true){do()};” an operating system?

 There are fundamental differences between the capabilities, features, and
 even architecture that will separate the toy projects from the controllers built for production deployment- the useful special-purpose controllers from the 

I expect there to be many experimental controllers, especially those that cater to a particular programming language or environment. As software developers get their heads around the idea of programming network applications, an existing frame of reference provides an important bridge whenever programmers are learning new technology. Over the long term, some winners will emerge.

Also, there are increasingly many special-purpose controllers.  Much like a general purpose OS like Linux is quite different, a 
virtualization specific OS like VMWare’s ESX, (which is different still
 from embedded OS controllers) seems to also come in a wide variety
 of specializations like general purpose (e.g., Floodlight),
virtualization specific (e.g., FlowVisor), and even controllers for embedded devices for mobile phones.

Only time and mind share will tell. Of course, I have a preference beginning with the Floodlight controller which enables developers to use a system that provides a mix of
”simple to learn” and “robust enough for deployment” criteria. Floodlight is packaged 
in a single JAR file. Using the REST API, programmers can write applications 
in any language they choose. (Java and Python seemed to be popular with the
Floodlight community.) 

The various controller present features are as varied as: “presents raw OpenFlow 
messages to the application writer” and “presents pre-computes possible (but 
not mandated) broadcast domains on top of mixed OpenFlow and non-OpenFlow

I work on Floodlight, and the features that I’m most proud 
of are the modularity, the host discovery, the mixed OpenFlow/non-OpenFlow
 topology and forwarding support. When the time is right, there is a clean
 upgrade path for porting applications to our commercial product: the Big
 Switch Controller (with all of its enterprise bells and whistles). I’ve yet 
to see any of the other open source controllers that offer comparable
features, but I’m definitely appreciating the excitement.

The race is on for what 
will become the SDN controller equivalent of Linux vs. the SDN controller
 equivalent of Minix (remember that!?). May the best software stack
 win!  Because somewhere in our minds, when we’re innovating and solving problems, we’re at some level all just a 
bunch of kids having fun.


About the Author:  Rob Sherwood is a key architect of OpenFlow 1.0, Floodlight, and FlowVisor. In his spare time he is the Chief Technical Officer, Controller Technologies at Big Switch Networks.

Comments are closed.