The northbound application programming interface (API) on a software-defined networking (SDN) controller is evolving rapidly, but with no standards in sight.
Initially, the Open Networking Foundation (ONF), the nonprofit that manages standardization of SDN's southbound protocol OpenFlow, avoided the issue of northbound API standardization, believing it was way too early and might stifle innovation of this critical component of network infrastructure.
The issue is further complicated by the fact that the networking world isn't used to how things are done in the software world, which views standardization as a roadblock to innovation. "The northbound API is a software interface inside a server, and API standards generally emerge from the market, not necessarily from a committee," ONF Executive Director Dan Pitt says.
Too early to talk about standards?
Given this ambivalence toward standards for the northbound API, why are they being discussed? Developers want to write useful SDN apps, and they don't know what to write to.
"They just want something popular that will give them good market share," Pitt says. "Companies making commercial controllers all want their northbound API to be the popular one -- but they'll have to win this one through merit. So far, nobody's written a controller that everyone naturally gravitates toward."
The ONF started a discussion group on the northbound APIs in 2012, with a goal of establishing a chartered working group with deliverables and a timeline. However, that discussion group was rolled into the ONF's Architecture and Framework Working Group, which is exploring the scope of SDN: What is it? What are the important interfaces or elements? How does it interact with other architectures and other standards and realms?
The Architecture Working Group is now developing a charter with three deliverables for the northbound API:
- Use cases that motivate the need for the northbound API.
- A compendium study that looks at examples of the northbound API and explores what they do, what they require from applications, what they convey about the network and what data models they use.
- Recommendations on what, if anything, needs to be done to help the industry accelerate the adoption of SDN applications.
"We need to build out this study so we can help people decide if there's something here that meets their needs. If there isn't, what's missing? Is there anything the ONF can do to help meet a market need? Until we identify those needs, we're not constraining innovation by rushing forward," Pitt says.
A world without northbound API standards?
There's a chance there won't ever be a juried standard on the northbound API. "There may be de facto standards coming out of the software world, and if the commercial world is happy with one … great," says Pitt. "If there's an absolute need for a standards committee to step in and do it, we're ready. Or we'll work collaboratively with carriers, wherever they want to do it."
The ONF is working closely with a group of service providers, Network Functions Virtualization (NFV), on using northbound APIs to build Layer 4-7 virtual appliances. "They may want a standard to get the software community writing toward as they build a suite of products to implement the functions in the software -- like firewalls, load balancing, traffic engineering and security," he says.
Short-term standards may also emerge for particular applications. But if this avenue is taken, Pitt doesn't expect it to meet everyone's needs for all time.
"We're used to standards being written in committees -- that's how it's done in networking protocol land," says Pitt. "But that's not how it's typically handled in the software world. It's important to keep in mind how different these two worlds are. We're leading the charge, keeping in mind what will be best for the industry."
The ONF isn't the only organization that might be involved in deciding whether the northbound API should be standardized. IEEE and others such as The Internet Engineering Task Force (IETF) will likely weigh in on this issue at some point.