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 [1].

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:

1. Ability to listen to asynchronous events (e.g., PACKET_IN, FLOW_REMOVED) and to register call back functions (e.g., receiveDataPacket).
2. Packet (e.g., ARP, ICMP, TCP) parsing capabilities to extract information, including associated context, about incoming flows.
3. 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 Big Switch'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.

[1] The tutorials were organized by Bay Area Network Virtualization meetup group.