Clarifying the role of software-defined networking northbound APIs

With software-defined networking the control of the network is pried out of the data handling devices and centralized on a controller that uses a common protocol, OpenFlow, to direct the switches on the southbound side. That much has been established. But what of the oft-mentioned northbound APIs that will let applications tell the controller what they need from the network? What kind of progress is the Open Networking Foundation making on that front? Network World Editor in Chief John Dix put the question to Robert Sherwood, CTO of Big Switch Networks and head of the ONF’s Architecture and Framework Working Group, which is responsible for multiple things, including the creation of these northbound APIs.

NW: Rob, let’s start by getting an explanation of your role in the Open Networking Foundation.

SHERWOOD: I am the chair of the Architecture and Framework Working Group, which is charged with many things, including scoping out the northbound APIs, but includes coming up with a general architecture and overview for everything that the ONF is looking at. You can almost think of it as a working group to decide the context for the other working groups. We’re also charged with coming up with names, so at least we can agree on what we disagree about, which is my standing joke.

[ MORE: Open Networking Foundation director details SDN directions, OpenDaylight impact ]

NW: How complete is ONF’s work at this point?

SHERWOOD: Let me split that conversation in terms of what gets standardized and what’s actually deployed and mature. In terms of what gets standardized, I would tell you we’re making good progress. No one thinks that we’re done. I think of it as, there may not be a done state, but enough things are standardized to hit a useful set of commercial features that can turn around and be productized by people like myself with my vendor hat on. At the same time, as you collect more interest, you have more use cases that come up and more places where you want this to go. So in that sense, there’s a fair bit of work ahead of us. But on the other hand, that’s strictly in terms of standardization. There are also lessons learned from implementation, and from that perspective, we still have some ways to go as well.

NW: Work seems to be furthest along with the so-called southbound APIs, with OpenFlow being the primary protocol that SDN controllers will use to talk to data handling devices. The northbound APIs are always referred to in more vague, futuristic terms. Explain the role they will play.

SHERWOOD: A lot of people are confused about this and it is one of the things I am trying to solve in my working group. Take what I call, for lack of a better term, a business application, something like Hadoop, or something like an Oracle server, or even something like OpenStack’s Nova. These are applications people want to run and the fact that there’s a dependency on the network is almost an annoyance for them. They just want the application to work.

So the northbound API is how that business application talks to the controller to explicitly describe its requirements: I am OpenStack. I want this VM field to talk to this other VM but no other VMs can talk to them, etc. But also give me a view of how loaded the network is so I can make an informed decision on where to put new VMs. So those are two examples of northbound APIs that I think are meaningful for people.

NW: Without northbound APIs will SDN applications be constrained vendor-specific controllers?