Where Do We Stand with SDN's Northbound Interface?

If you have been following SDN you know that there are standards such as OpenFlow that can be used for the southbound interface between the controller and the subtending network elements.  However, there isn't a standard for the North Bound Interface (NBI) between the controller and the business applications and network services that utilize the controller.  Over the last few years, this has been a subject of great debate in the SDN community.  Proponents of standardizing the NBI have argued that there are numerous controllers on the market, each with their own NBI and none of which have significant market share.  Their argument is that the lack of standardization impedes the development of SDN because without standardization application developers won't be very motivated to develop applications for a controller with small market share knowing that they will likely have to modify their application to work on other controllers.  The argument against standardization is that we are so early in the development of SDN that we don't really know what should go into the NBI and hence it makes no sense to standardize it.

To gain some insight into where we stand with NBI I caught up with Sarwar Raza.  Sarwar is the Director of Cloud and SDN within HP Networking's Advanced Technology Group.  He is also the chair of the NBI working group that was formed a few months ago by the Open Networking Foundation (ONF).  The members of the NBI working group include amongst others HP, Microsoft, Ericsson, Radware, Huawei, NEC and Freescale.  The group's charter was outlined in a white paper published by the ONF.

The first question I asked Sarwar was about the debate surrounding whether or not to standardize the NBI.  He pointed out that for a year or so there had been a proposal in front of the ONF to standardize the NBI.  The ONF initially responded to the interest in standardizing the NBI by having the ONF architecture working group establish a study group.  It was that study group that was recently promoted to become the NBI working group.  He concluded that given that the members of the ONF recently agreed to establish a NBI working group, this indicates that for at least some members of the SDN community the sentiment is shifting in the direction of standardization. 

I will admit that I thought the goal of the NBI working group was to develop one or more standards for a NBI.  Sarwar pointed out that standardization was not a short term goal of the group and that "Our goal in the next year is to formalize the framework along with the information and data models and then iterate some with code before we even start a standards discussion."

As part of their charter, the NBI working group intends to work with one or more open source initiatives to develop working code for the NBIs that the group aims to put forward for standardization at an appropriate time in the future.  I asked Sarwar if any of the open source initiatives had already agreed to develop code.  He explained that the working group has a good relationship with both the OpenStack and the OpenDaylight initiatives but that when dealing with open source initiatives "There is no magic handshake."  What he meant was that none of the open source initiatives are going to agree in advance to produce code for NBIs that are under development.  What will happen is that after the NBI working group has made some additional progress, they will have detailed technical discussions with multiple open source communities and will see if there is a consensus about developing code. 

One of the interesting concepts that the NBI working group has introduced is the need for APIs at different "latitudes".  The idea is that a business application that uses 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 and hence, not need the same level of abstraction.  One obvious conclusion to be drawn here is that the NBI working group will not come out with one NBI that works for every type of application.  It is also highly likely that there will be further segmentation of NBIs based on industry sector.  For example, there may be different NBIs for enterprises than there are for service providers.  While it is clear there will be more than one, it is less clear how many standard NBIs will we have a year or two from now.  I am not saying that it would necessarily be bad, but it would be very ironic if the motivation to standardize NBIs was to avoid having a large number of NBIs and that the result of that standardization was a large number of NBIs.  

To me the viability of any new technology or new way of implementing technology revolves around the use cases.  The good news is that the NBI working group intends to publish use cases. Given my curiosity about the possible use cases, I was disappointed to hear that they would not be published for another couple of weeks.  I was also disappointed to hear that unlike the approach taken by the ETSI NFV ISG (European Telecommunications Standards Institute, Network Function Virtualization, Special Interest Group), the NBI working group currently does not have any plans to take an active role in driving one or more POCs (proof of concept) for each of the use cases that it develops.

Given that it is only been around for a few months, the NBI working group has accomplished a lot.  They have created a general API framework and architecture and are within weeks of publishing a set of use cases.  However, they have a lot more work to do and I will check back in with Sarwar in two or three months to get an update on their work.