With the Olympics just around the corner, it got me thinking again about our favorite SDN topic: creating and standardizing the Northbound API (NBAPI). We’ve seen posts and musings around this from multiple folks (Brent Salisbury, David Lenrow to name just a few) and I’ve had many more conversations with others in the SDN community. I believe that a compelling Northbound API will not likely emerge from a standards body, or any kind of committee and the best bet for a compelling Northbound API is through competition in the open market.

If we look at where we are from an SDN Northbound API standpoint, we do have early implementations today. Take for example, Floodlight’s RESTful northbound interface to handle queries and state reporting, and for static rule programming. Unfortunately and perhaps unsurprisingly, dynamic or reactive rules require direct programming within the Java framework. Trema has one to handle resource management in sliceable networks centered around tenant management. And I have no visibility into Nicira’s NVP APIs presumably built on ONIX. And finally we have  NOX's limited API. Most of these are relatively nascent and there are limited publicly available applications built on top of these NBAPIs.

I’ve heard arguments for letting a Northbound interface develop over time organically instead of mandating via committee. And every one is looking for coalescence around a NBAPI. Instead of trying to form committees to create such an API or speculate the nature of such an API, perhaps we just encourage teams to build APIs necessary for their applications and let competing versions duke it out in the marketplace? As part of a conversation with Rob Sherwood, we discussed Android and iOS as popular interface platforms today. Like Rob, I think the world is a better place because there are different development platforms that spur innovation. What possible paths are there to a world where application developers get to pick from a robust set of  Northbound APIs candidates?

Looking at iOS, it started a proprietary internal interface first. Remember back in 2007 when Steve Jobs was telling the world to write only Web apps for the recently launched iPhone? That didn’t go down very well and after lots of lobbying from third-parties and customers, the iPhone SDK became a reality. In this case, the SDK evolved from a proprietary interface to a publicly available interface after Apple cleaned it up and matured it. Clearly the iPhone API has been well-received by mobile application developers. Unlikely that we'd ever see millions of Apps for OpenFlow on the OpenFlow app-store, but I'd bet we'd be ecstatic if we had a couple of hundred.

On the other side, you could argue that Android was relatively open from the start but I think Google exerted a definite amount of control (and still does). Visibility into an API doesn't mean you can change it. I think a better comparable here is the cgi-bin API for web servers. Imagine for a moment HTTP being a Southbound interface and web application logic interacting with a HTTP server as the Northbound interface. We started first with static HTML pages, and then user demand drove execution of programs. This led to the NCSA (National Center for Supercomputing Applications) supporting the cgi-bin interface in its popular HTTP server. Cgi-bin expanded into FastCGI, Simple CGI, and then into ISAPI from IIS, NSAPI from Netscape, Apache modules hosting mod_php, mod_perl etc. Concurrently, we also saw parallel rearchitecture efforts, with Java application servers like Tomcat spawning enterprise application platforms.

Because web-servers were widely deployed, and web applications flourished, we all learned why cgi-bin’s short-running processes needed to be replaced with long-lived processes. We could see the rationale for moving application logic into the web-server itself, to the application-server becoming the central part of the solution. All these met different end-user and market needs. Likewise, for SDN, I see multiple northbound interfaces, perhaps for different classes of applications, from lightweight OpenFlow “drivers”, all the way to fully-baked application-server platforms with advanced controller logic, state synchronization, high-availability etc. Whether we need an invisible guiding hand in the form of a standards body to keep all these efforts corralled remains to be seen—I think it’s premature.

I believe the path forward is through experimentation and for multiple controller platforms to draw their lines in the sand, put their stakes in the ground, make up reasonable APIs that fit their community needs. Who cares if the interface is perfect or even right the first time? Instead of worrying so much about a single unified NBAPI, let’s encourage Nicira to write more apps on its proprietary NVP NBAPI. Let’s encourage development teams to write applications to Floodlight’s API and modify it for their needs, perhaps add callbacks to its RESTful API so we can handle reactive flows--just do whatever they see fit. In the ensuing competition between the different APIs, we will see true evolution towards really useful NBAPIs. The alternative, if we sit around and debate in committees, is stagnation and irrelevancy (just look at NAC within the TNC).

I'd be interested in hearing what the community has to say--feel free to comment on the post below. Feedback strongly encouraged!

Check out more Technology on SDxCentral: