Clarifying the role of software-defined networking northbound APIs
Network World - 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.
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?
SHERWOOD: Look at the operating system world. There is not an API that is standard for application developers across Mac OS, Windows and Linux. It just doesn't exist. But that's been a fairly healthy ecosystem. Similarly, if you look at cellphones, there's not a comparable northbound API across iOS, Android, Symbian, etc. But again, that's a fairly healthy ecosystem. The critical thing is, as long as the API is open it doesn't matter as much if it's standardized. Yes, eventually, these things might become de facto standards, but that's many moons from now.
NW: But if all the controller vendors come out with non-standard northbound APIs it's going to make it harder on the buyer, won't it?
SHERWOOD: My mindset is the buyers are actually buying business applications, and it's really about what supports what. For example, it is a reality that the people who write Angry Birds have to write different implementations, one for Android and one for iPhone. But as long as the application you want is available on the platform you want it to work on, that kind of doesn't matter for the buyer. You just want the application to work.
NW: Is it technically hard to create these northbound APIs or is it just a byproduct of the way the technology is emerging, with the early focus on the southbound side while biding your time on the northbound stuff?
SHERWOOD: It's both. Think of the work required to get Unix to a position where people could even think about standardizing the APIs that became POSIX. A lot of learning had to be done, and people are still arguing about it. With my working group hat on I tell people we should build a bunch of examples, figure out what we got wrong, try to fix it, iterate it, and, assuming we actually reach some sort of stable point, then try to standardize that. Right now everyone and their grandmother has a controller, and what that means is that everyone and their grandmother has a northbound API. And while I'll be the first to tell you I think mine is best, at this point nobody really knows.
NW: Does every controller supplier have one northbound API, or will they have multiple types of APIs for different types of functionality?
SHERWOOD: It's a little bit of semantics. People talk about the Amazon EC2 API, but if you break it down there's clearly a bunch of different types of APIs put together. It doesn't really matter as much for the programmer as long as these things are well documented, open and available to them without changing.
NW: OK. And where do we stand in the development of these northbound APIs? Has Big Switch, for example, fleshed any out?
SHERWOOD: With all these things it's a question of what you support. The dataset we work on, both Floodlight [the open source version of Big Switch's controller] and our commercial product, is actually able to support a growing list of interesting applications, but it's not everything. And what's interesting to see is that people are extending the APIs to build more and more applications on it. And to pre-empt maybe your next question -- how close are we to being done? -- we just don't know yet.
NW: OK. You mentioned some applications that will be able to take advantage of the northbound APIs, but is it possible to categorize what will likely emerge? A bunch that will do X, others that will do Y?
SHERWOOD: I'm of the belief that it will be a large class of applications. I joke that the killer app of SDN will be the long tail, which is to say that the most interesting app will be the wide variety of apps that will be made possible. But I think it will be a large collection of applications. I recently asked a group of grad students, "Who's going to be the first to create FarmVille for networking, some application that no one ever thought of, but turns out to be really popular?"
NW: Are the legacy guys, the Ciscos and Junipers of the world, really keen on the standardization of these APIs, or does it work against their best interests?
SHERWOOD: I think they're a little bit of two minds, if I can put words in their mouths. Obviously they have their own interests to protect, but at the same time I think they see the writing on the wall. So they're looking to be active participants in this and also want to see where it's going. I don't think that's terribly different on the northbound API side versus any other part of this issue.
NW: OK. The last question. If this effort to standardize the northbound APIs doesn't get off the ground, are there workarounds that would help us achieve some of the same things?
SHERWOOD: Let me be very specific as to what my working group is doing. Right now we're only categorizing the APIs and documenting what exists. We aren't trying yet to standardize them. One could imagine that would be a subsequent step. It is my personal belief that we don't need to do this because a standard API doesn't exist in the PC operating system world or in the mobile phone market, and if we're half as successful as those markets then I'll be pretty happy.
It's really easy to pick a standard and say -- OK, this is it, we're done. But my concern is that if we pick something now it will be wrong or incomplete. That can cause as much or more damage as not picking something soon enough.
NW: If a company ends up with controllers from multiple suppliers, would there be a way of federating them in some sense, to reach some form of interoperability without having standard northbound APIs?
SHERWOOD: Certainly we spend a fair amount of time thinking about that, particularly with my ONF hat on. It's actually interesting to take a slightly different question and come back to it.
So quite often in a controller we have to integrate with other legacy protocols, OSPF or BGP, or something like that. So our controller already knows how to talk with non-SDN devices, and my claim is that other people building controllers will have to do the same thing. So if my controller is willing to speak BGP to something, and another controller is willing to speak BGP to me, that could actually be some sort of lingua franca between us.
NW: OK. Anything else regarding this whole topic?
SHERWOOD: I'm really more of a programmer than what I'd call a standards wonk, and I think the exactly wrong thing to do is standardize first and develop later. That's someone saying they have the answer and we should set it in stone. I think there's still a lot of development and experimentation that needs to be done. So that's how I fill a lot of my time, just trying to develop and experiment with these APIs.
NW: Are there other people you're working with that are fighting to do the opposite?
SHERWOOD: There's certainly a tension back and forth. It really comes down to how right you think you are. There are people who believe they are right, they have seen the light and if everyone would just agree, the API should be their way. I think that's going to be true independent of this topic in any significant body of people. I'm a little more pragmatic, much more the old rough consensus and running code perspective We'll see what happens.
Read more about lan and wan in Network World's LAN & WAN section.
- Virtually Delivered High Performance 3D Graphics "A picture is worth a thousand words." That old phrase is as true today as it ever was. Pictures (i.e., those with heavy...
- Who does NSS Labs "Recommend" for NGFW? In 2012, NSS Labs found that most available NGFW solutions "fell short in performance and security effectiveness." In 2013 NSS Labs noted "marked...
- CIOs Deliver Productivity Breakthroughs with Intelligent Digital Signage Retailers have long recognized the influence that digital signage provides over a shopper's point-of-purchase decision making process.
- Improving Business Value of WAN Optimization Want to achieve faster ROI with WAN optimization? Read the latest IDC report and discover how you can cut IT costs without compromising...
- Live Webcast IBM FlashSystem V840: Leveraging Software-Defined Flash to Drive Your Business With end-to-end, tightly integrated functionality and super-fast flash technology, products like IBM FlashSystem V840 Enterprise Performance Solution empower businesses to leverage the efficiency...
- What should I look for in a Next Generation Firewall? SANS Provides Guidance With so many vendors claiming to have a Next Generation Firewall (NGFW), it can be difficult to tell what makes each one different....
- IBM FlashSystem V840: Leveraging Software-Defined Flash to Drive Your Business With end-to-end, tightly integrated functionality and super-fast flash technology, products like IBM FlashSystem V840 Enterprise Performance Solution empower businesses to leverage the efficiency... All Networking White Papers | Webcasts
Our new bimonthly Internet of Things newsletter helps you keep pace with the rapidly evolving technologies, trends and developments related to the IoT. Subscribe now and stay up to date!