The Northbound API- A Big Little Problem : What is a Northbound API (Application Programming Interface) in SDN? The Northbound API is available on a SDN controller that allows for applications to interact with the controller. The controller in turn, interacts with the network hardware through the OpenFlow protocol to manipulate the flow tables and send instructions to the underlying network substrate. I am going to call that the Southbound API. The controller appears to be the glue at the center of the SDN paradigm. While crucial in the incubation period we are in, I think in the long run it will be just another resource pool we scale up and out, similar to what we have in the x86 compute construct. The following are three fundamentals if I were to rank what I need from an OpenFlow controller.
SDN Components
- Push a data path to the network hardware substrate based on match + action + count rules into a switch’s flow tables via OpenFlow protocol.
- Expose a “Southbound API” for networking devices to integrate into the ecosystem.
- Expose a “Northbound API” for applications to attach to the ecosystem.
Figure 2. The API degrees
SDN Disruption Timing is Important
The API’s today for the two most active OpenFlow controller projects judging from the cobwebs on some of the sites are NOX/POX and Floodlight. No surprise that NOX is from the Nacira camp and Floodlight is from the BigSwitch camp, the two startups that have evolved out of Stanford and SDN. Both have incredibly talented people. Of the two controllers, the Floodlight API is my head and shoulders above preferred of the two. The FloodLight JSON/REST API provides an easily readable HTTP GET,POST, DELETE style actions. I think that a fairly abstracted API is important if traditional engineers are to be comfortable with what is going on under the hood in provisioning and troubleshooting. Especially, if they are in networking because they are not fans of endless hours of grinding out crappy code, in my case. As far as the NOX API, Google around and see if you can find it..
Art Fewell in an interview asked Martin Casado about this last year at the fall ONS. Martin is one of the parents of OpenFlow, the creator of OpenvSwtich and in my opinion from my interactions with him is one of the biggest believers in the community aspect that is so lacking in R&E. It is not only his intellect but probably more importantly his ego profile that has him on the frontlines of so many groundbreaking projects (sorry being a network fan boy).
“My personal opinion is that we need to stay very, very focused on one layer right now. I’d be very interested in seeing OpenFlow coming out, having general support in hardware, having multivendor support, having a good ecosystem on products that use it. Even though this comes up all the time, I think we should all focus on one piece of the puzzle. That said, clearly, you do want kind of a higher way of interacting with the network. But it’s not clear to me that this is a northbound API, it’s not clear to me that this is something that sits on top of a network operating system; it’s not clear to me how this will look. This is so totally embryonic. I view OpenFlow almost as a BIOS. It’s kind of a nice independent way of talking to the hardware, and that’s it. And I think if we just get this accomplished, we’ve done a great thing, and then the rest will follow.” -Martin Casado
Figure 3. It is starting to look a little more like proven benefits from abstracted architectures.
My 2 Pennies Worth
The sooner we get some coherent coalescence around the Northbound API the sooner the magical apps and the multi-billion dollar industry can begin. If the community cannot come up with something well defined, open and flexible without being overly complex. I am not optimistic that the research and education community is capable of doing so with how fragmented R&E feels at times. I don’t expect Cisco and Juniper to collaborate together to produce a vision together just as I don’t expect to siloed institutions to do that either. The individual or institutional glory will always trump giving away ideas collaboratively unfortunately. I expect a vendor to fill that void rather quickly.
This coming week we have Cisco Live US (my predictions add yours!) and Interop Japan, in which I expect to hear aggressive announcements around SDN. That said I have told all vendors I do not want to know anything NDA regarding SDN. Telling me something being planned that may give hope to our broken networking OAM and then telling me I can’t discuss it with anyone but them pisses me off most the time. It’s more fun to guess at how this gets bungled or embraced by the big shops. I am excited to see the big players in the industry to get involved. They will not sit on the Northbound API for long because that is the crown jewels. Hopefully it will get the community what they need or consolidate on something like the RESTful/JSON API already defined from some. , stable API roadmaps to begin developing the truly revolutionary layer of SDN which is the applications.
Brent – Insightful post to your point we need both a north and south bound API. Until we as an industry can come together with the use-cases and model to make OF / SDN profitable these open questions linger – how to actually implement an OF / SDN network?
Boy oh boy do I ever agree with you Mark. I think the vendors will start coming in with “reference architectures” to tie the islands SDN islands together. I have been piecing together what I see as a possible integration for a post but we are so early. I still lean towards adoption as opposed to crash and burn in some cases. If you roll it today its more likely to say hey look what I have at my place other than a corner case or two. Most customers dont want or have DIY like resources to take a dev kit and roll their own applications. I think the application API is so critical to getting a working framework for deployment and integration. RouteFlow is the closest to a coherent path I have seen to tie into existing networks but even that is really raw but seems pretty active. To your point I agree we are glaringly missing the native to SDN route redistribution/advertisement with scale. I think its probably just to focus on one layer at a time. If someone put loads of time/money into an App today it would probably be broken 3 days later lol.
I compare it today that I am personally talking about debugging how IOS/Junos etc talk to their hardware, firmware, HALs etc. I need to be talking one API up at least like I would today. I get way too many things wrong trying to generalize complex hardware with the few white papers and books available to those of us on the outside. I think it will get clearer over the next 6 months? Next merchant silicon cycles may alleviate some of the issues. Seeing a lot of SRAM/TCAM masking chatter. What do you think will come out of the announcements this week Mark?
Without speculating or violating NDAs I think we will see wider hardware support for OF now that 1.3 has slowed down the OF churn. I believe 90% of customers want a complete solution without having to do too much development on their own, there are exceptions (e.g. large content providers, universities, etc…) but overall people want something which takes little development work for the others they want a comprehensive API (not SDK) which they can use to build their systems around…
thanks for taking the time to write, i never find time to write good posts. i really appreciate all the good information everyone has to share.http://www.bancobrasil.net
Hi Adir, Kind of you to say. Drop me your blog when you get up and running!
Excellent diagram that illustrates the “picture is worth a thousand words” mantra. This actually inspires me to write an article of my own.