Much Ado About SDN Controller Platforms
In the past 3 years, I have given a handful of tutorials on how to build OpenFlow/SDN-based control plane functions (also called as “Controller Applications“). But I had my most fun (and adrenaline rush) when I signed up to do tutorials on 3 controller platforms — POX, Ryu and OpenDayLight – without having used them before .
I have used NOX quite a bit and it was my hypothesis that knowing one controller platform really well would be sufficient for one to learn to use the other platforms. Lucky for me, the hypothesis turned out true. By spending a little bit of time (not more than 6 hours with any 1 controller platform), I got upto speed and was able to comfortably write programs from scratch with each controller platform. The applications I wrote were even beyond the basic L2 Learning Switch that we typically use in the tutorials. This is testament to the growing maturity of the SDN controller platforms.
For the purposes of building controller applications, all controller platforms expose 3 main features to the application developer. If you are a novice app developer, you should look for the following first:
- Ability to listen to asynchronous events (e.g., PACKET_IN, FLOW_REMOVED) and to register call back functions (e.g., receiveDataPacket).
- Packet (e.g., ARP, ICMP, TCP) parsing capabilities to extract information, including associated context, about incoming flows.
- Ability to create and send an OpenFlow/SDN message (e.g., PACKET_OUT, FLOW_MOD, STATS_REQUEST) southbound to the programmable dataplane.
The controller applications may in turn offer an northbound interface for soliciting configurations or other input from the user. But support for building such northbound interface is typically not expected from the controller platform, and the applications themselves can instrument it in other ways.
I feel like I shouldn’t be ending the blog article without commenting on the new kid in the controller block — OpenDayLight. The tutorial on OpenDayLight was conducted a few days after BigSwitch’s announcement about stepping down from the project. Consequently, most attendees were keen on getting the answer to the following:
- What is the main reason backing BigSwitch’s departure from the consortium?
- My Answer/Opinion: Mostly political. The unavoidably diverging codebase would have eventually become unsettling for the community.
- What do I see as the main architectural difference between FloodLight and OpenDayLight?
- My Answer/Opinion: FloodLight is predominantly OpenFlow-centric, while OpenDayLight has an abstraction layer that allows it to work with many other APIs managed through plugins. Some of the differences and similarities will be apparent from this wiki page.
- Does OpenDayLight controller platform seem to have potential to progress without BigSwitch?
- My Answer/Opinion: Yes. I base it on my having quickly learned and built an application bundle in a matter of few hours. Their Java-based platform seems quite developer-friendly.
 The tutorials were organized by Bay Area Network Virtualization meetup group.
Check out more from Contributors on SDNCentral:
- Truly Successful DevOps Requires a Change in Culture
- The Advent of the Infrastructure Platform
- The Role of Abstractions in DevOps
- Why NFV Will Be a Reality Soon
- Clearing Up Common Misconceptions About DevOps
CONTRIBUTED ARTICLE DISCLAIMER:
Statements and opinions expressed in articles, reviews and other materials herein are those of the authors; the editors and publishers.
While every care has been taken in the selection of this information and reasonable attempts are made to present up-to-date and accurate information, SDNCentral cannot guarantee that inaccuracies will not occur. SDNCentral will not be held responsible for any claim, loss, damage or inconvenience caused as a result of any information within this site, or any information accessed through this site.
The content of any third party web site which you link to from the SDNCentral site are entirely out of the control of SDNCentral, and you proceed at your own risk. These links are provided purely for your convenience. They do not imply SDNCentral’s endorsement or association. The copyright and any other intellectual property right any third party content belongs to the author and/or other applicable third party.