Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

SDN's Northbound Interface Evolves

Software defined networking requires both northbound and southbound interfaces to facilitate communication between physical devices, the SDN software and applications running on the network. On the southbound side, standards such as OpenFlow define the interface between the controller and the subtending network elements. However, there isn't a standard for the northbound interface (NBI) between the controller and the business applications and network services that utilize it.

As recently as two years ago, there was considerable debate in the SDN community about the viability of either creating such a standard or at least developing a consensus about how the NBI should function. Those against developing a standard argued that we were so early in the development of SDN that we didn't know what to include in the NBI. Those in favor of a standard approach said it was required in order to avoid vendor lock-in. They also noted that there were numerous controllers on the market, each with their own NBI and none with significant market share.

According to the proponents, the lack of either a standard or a consensus about how the NBI should function was impeding the development of SDN. Without a common NBI, application developers wouldn't be motivated to develop applications for the large number of controllers with small market share.

In 2013, the Open Networking Foundation (ONF) established a working group to focus on the NBI. Given that traditional standards activities are widely viewed as too slow for the current environment, the goal of the working group was not to develop a standard for the NBI in the traditional sense of the term standard. Rather, the goal was to develop a rough consensus and collaboration around community-developed NBIs.

The group published a white paper outlining its charter. One of the interesting concepts discussed was the need for APIs at different "latitudes." The idea was that a business application that used the NBI should not require much detailed information about the underlying network. Hence, applications like this would require a high degree of abstraction. In contrast, network services such as load balancing or firewalls would require far more granular network information from the controller. These would not need the same level of abstraction. 

I recently talked with Dave Lenrow, a distinguished architect in HP's advanced technology group. Dave is the chair of the ONF's NBI working group and is on the technical steering committee for OpenDaylight (ODL) and OPNFV (Open Platform for NFV). Dave said the NBI working group is "essentially doing an experiment in collaborative agile development with open source projects. Instead of spending years trying to prove on paper that our architecture works, we throw some experimental API stuff to multiple OSS projects (e.g., ODL, ONOS) and let implementers provide feedback on what works and what doesn't with a fast fail approach. Our members want ONF as a neutral third party to define the basic software artifacts (e.g., information model, principles of operation) that get implemented on many vendors' solutions."

Dave filled me in about the progress the NBI working group is making in general and in regard to latitudes in particular. Dave said that after publishing the white paper, the working group realized that the approach established there could only work if they solved the problem of resource sharing among logic at different latitudes. Currently, every application or service that communicates with the SDN controller acts as if it has total control of all of the subtending network elements. That means they would "step all over each other." According to Dave, the solution to this problem is a single resource arbitrator with a single interface to applications and services.

With that new goal in mind, the NBI working group is focused on developing an intent-based interface. In contrast to a prescriptive interface, an intent interface focuses on what the application or service needs, rather than the commands to change the network.

The intent-based interface the working group develops will be the single interface to applications and services. Subtending that interface will be the various NBIs that are supported by open-source and vendor-supplied SDN controllers. The key to making all of this happen is implementation of a common information model that enables, via extensibility, every possible use case to be represented by a single NBI.

According to Dave, there have been a variety of vendor-sponsored information models that have not found enough critical mass to create an ecosystem network effect. Dave expressed his strong belief that a diverse group must develop the interface, or it will not succeed. He elaborated, "A pay-to-play approach does not make any sense for this activity" and noted that anyone can join conference calls and comment on drafts where the work is proceeding.

Dave said that a document describing the operating principles for an intent-based SDN system is hopefully in its final draft before outside review. He added that the group was able to demonstrate end-to-end service function chaining at the Open Networking Summit in June. I found this demo particularly interesting because some of the virtual functions were in a domain controlled by the OpenDaylight-sponsored open-source controller, and others were in a domain controlled by the ONOS open-source controller. The application that created the end-to-end service used the same interface for each domain.

This demo provided a glimpse into a possible future state in which each SDN controller has one or more NBIs that provide value and potentially differentiate that controller in the marketplace. However, applications and services without modification can work end-to-end and can leverage the functionality provided by disparate SDN controllers.