Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.
November 6, 2013
The Open Networking Foundation (ONF) turned a lot of heads in October with the announcement of a Northbound Interfaces (NBI) Working Group.
While we're always glad to draw more attention to the benefits of Software-Defined Networking (SDN), we want to be sure that the industry truly understands why we are looking north and how this new Working Group fits into the overall focus of Open Networking Foundation (ONF). This is especially important since we have been so vocal for more than two years about why we are not standardizing the northbound API. (Believe me, I've taken a lot of flak for that, but steadfastly resisted.)
ONF's mission is to accelerate the adoption of open SDN. To us, SDN includes both the OpenFlow substrate and the enablement of applications and services above it. This means that while our NBI Working Group is new, our work with the Northbound Interface is not.
Back in June 2011, we received an inquiry from another industry group asking if we planned to standardize the Northbound API. "Goodness, no," we replied, but we neglected to say why.
"Oh good," they replied. "Then we will."
Damage control included explaining why no one should, because:
No one had enough experience with OpenFlow controllers to know what to standardize
This period of innovative experimentation was important for learning and we did not want to stifle it
Anyone who tried would surely get it wrong
There won't be just one NBI anyway, and
That's not how software artifacts get standardized.
Fortunately, they listened.
Since then, the industry has built a considerable body of experience. With a solid OpenFlow substrate, the attention now shifts to include the software and services that the foundation enables. We have seen a greater demand from developers of application, orchestration, and management software for assistance in understanding NBIs as a critical component of a complete SDN solution.
So in the fall of 2012 we began looking at NBIs in the form of the Architecture and Framework Working Group's study of existing SDN use cases and controller interfaces, which are many. The large number of unique controller APIs indicates that there is no consensus yet on what makes the right NBI (and could also lead one to believe that they are not that hard to write). We will soon publish the first edition of our NBI study, cataloguing and comparing them.
While this proliferation of SDN controllers brings some valuable learning, it also creates confusion for those wanting to write to an NBI. Without stable interfaces to write to, overall adoption of SDN slows, and when we heard concerns from many in the ONF user population, we knew that we had to take action.
The question then became: What action should the ONF take? We have long said that software APIs are not typically standardized in advance by committees, because they don't have to be. Anyone can modify an (open) interface quickly; it's not like redesigning an ASIC. What we as an organization can do is bring clarity to the choices and their benefits, through both investigation and prototyping.
Therefore, ONF took the leap and chartered the NBI Working Group, which is evaluating Northbound Interfaces. Plural. That's an important distinction. The Working Group has already put together a chart showing how broad the topic is. Characterizing the different levels of abstraction as latitudes and the different use cases as longitudes, they starkly demonstrate the futility of imagining there being one, or "the," NBI.
Our first step will be to develop information models for Northbound Interfaces at different latitudes and longitudes with plans to prototype and gain market feedback on select examples. Again, examples -- plural.
What we don't plan to do is rush to a standard. ONF has spoken passionately about standards, and we have committed to standardizing only what is truly necessary. If the industry needs us to help them arrive at a standard for some use case, we will. Prominent among our members' requirements are for the interfaces they write to to be truly open and not vulnerable to the whims of a single vendor. Moreover, we suspect that a small number of NBIs will serve a large fraction of current market needs. Thus, one of the purposes of our NBI Working Group will be to determine if an NBI standard from a committee is needed by the market at this time.
ONF plans to publish its Northbound Interface information models in 2014, accompanied by open-source working code for select use cases. We will also continue to strengthen the OpenFlow substrate to make sure it offers great service to the software and services above the NBI.
As always, user needs remain our only compass.
— Dan Pitt, Executive Director, Open Networking Foundation
Dan Pitt is Executive Director of the Open Networking Foundation, joining on its public launch in March 2011. Dan spent twenty years developing networking architecture, technology, standards, and products at IBM Networking Systems in North Carolina, IBM Research Zurich in Switzerland, Hewlett Packard Labs in Palo Alto, and Bay Networks in Santa Clara, Cal., where he was vice president of the Bay Architecture Lab. When Nortel bought Bay Networks, Dan became vice president of Nortel's Enterprise Solutions Technology Center, spanning nine cities on four continents. From 2002–2007 he served as dean of the school of engineering at Santa Clara University and holder of the Sobrato Chair in Engineering. From 2007–2011 he advised and served in executive operational roles in startup companies in the U.S., Canada, and Australia, most recently as an executive in residence at the Plug and Play Tech Center in Sunnyvale, Cal. Dan received a B.S. in mathematics (magna cum laude) from Duke University and an M.S. and Ph.D. in computer science from the University of Illinois. He taught as an adjunct professor at Duke University and the University of North Carolina for ten years and has fifty publications and one patent to his credit.
You May Also Like
Rethinking AIOPs — It's All About the DataMar 12, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Fiddling with Fixed WirelessMar 21, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Cable and 5G: The Odd Couple?Apr 18, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Delivering the DAA DifferenceMay 16, 2024