ONF to standardize northbound API for SDN applications?

Sources say the ONF is at the early stages of developing northbound API standards. Standardized SDN app interfaces could boost adoption.

The Open Networking Foundation is in the very early stages of developing northbound API standards that could become the universal framework for how developers create SDN applications, sources said. However, Foundation officials deny these claims.

Panelists at an SDN workshop at Interop New York this week confirmed they have been involved with establishing an Open Networking Foundation (ONF) working group that would focus on northbound API (application programming interface) standardization. Pascal Menezes, a principal program manager for Skype/Lync at Microsoft, said he had been part of a group that, for two months, has been working on a charter for a northbound API working group. Other ONF members said that charter will go to a review board for a vote next week. The working group will be called the Northbound Interface Working Group, one source said.

Standardizing an API for SDN applications has been hotly debated. Essentially, applications are the exciting part of an SDN environment, enabling everything from network services, such as Quality of Service (QoS) and load balancing, to full-out network virtualization.

Many SDN architectures decouple the control plane from the physical network and place it in either a central platform or a federated group of controllers, which uses a language, such as OpenFlow, to define distinct packet flows among data-forwarding devices. But the applications that live on top of the controller (northbound) determine how the controllers program those flows.

The ONF develops and standardizes the OpenFlow protocol, the most prominent standard southbound SDN protocol. But the organization has said that standardizing a northbound API would hamper innovation among applications developers. When contacted this week about the matter, ONF executive director Dan Pitt reiterated this position in a statement released by the foundation.

"We want to clarify that ONF is not formalizing a standard for northbound APIs at this time. ONF continues to believe that no single northbound interface will serve all use cases and environments. As a software interface, the northbound interface is less suited for standardization by committee than protocols are, and standardizing one at this time would stifle market innovation," Pitt wrote. "We will continue to evaluate all of the northbound APIs available as part of our commitment to SDN end users, but any standard for northbound APIs, if necessary, should stem from the end users' implementation and market experience."

Beyond the stifling innovation in development, the official launch of a northbound API standards working group could launch direct competition between the ONF and the OpenDaylight consortium, making the goal of SDN interoperability more elusive than ever.

OpenDaylight, an alliance of network hardware and SDN vendors, has developed and released an open source SDN controller that provides a "framework" for deploying northbound SDN applications. However, the organization is not a standards body and has refused to call its common framework a universal standard.

That doesn't stop market experts from seeing its work as the future of the universal northbound API.

"OpenDaylight is defining the northbound API," said network engineer and Packet Pushers founder Greg Ferro. "The networking industry can only have one protocol for everything." For the northbound, it will be OpenDaylight, and in the southbound, it will be OpenFlow, he said.

ONF will consider a group of northbound API standards for SDN apps

Generally, the interface that enables SDN applications has been referred to as the northbound API, but ultimately, it will more likely be a set of interfaces. After all, the definition of an SDN application is very broad, covering everything from network services such as QoS to business applications such as unified communications. These applications need to speak to the network in different ways and require different interfaces. The ONF standards process will account for these variations, according to those involved in the formation of the working group.

"There are different layers of northbound APIs," Menezes said. There will be an API interface that supports network services, another for applications such as orchestration, and potentially something different for business applications. Those APIs will call on lower-level functions in the network and its topology differently, he said.

Why the need for northbound API, SDN application standards?

Much of Interop this week focused on the need for application-aware networking -- or the ability for applications to determine how much bandwidth they need from the network -- and in turn for that to be provisioned as part of an automated system.

That communication between applications and the network must be standardized in order for developers to write apps that work on any network infrastructure regardless of vendor, said Mat Mathews, co-founder and vice president of product management at SDN startup Plexxi. SDN technology won't take hold if applications only know how to express their infrastructure intent to switches from one vendor.

Ultimately, when users choose their SDN vendors, the decision could hinge more on how they implement SDN apps than on what southbound language they're using or which architecture they choose.

"If you want SDN to be successful, the most important aspect is the northbound APIs, not whether you are running OpenFlow or something else, or whether you have tunnels or device-based SDN, because those aren't getting integrated into your operational process. That's the SDN apps -- the monitoring apps, security apps," said Gartner's distinguished analyst Joe Skorupa.

Standardized apps give users the freedom to move between vendors with their apps intact.

"I talked to a client working on integrating a particular vendor's SDN into its operational processes. Testing and integration and deployment was a very expensive nine-month process. What happens if the vendor you pick -- for whatever reason -- gets bought, goes out of business, can no longer afford to invest in its technology? You need to know that the apps that you bought and integrated into your operational processes and procedures can go with you when you go from Vendor B to Vendor L," Skorupa said.

Until now, many companies are providing RESTful APIs that developers can write to, but those applications can't necessarily be moved between vendor systems.

Can the ONF pull off northbound API standards?

There's been plenty of chatter in the industry about the ONF dragging its feet on OpenFlow standardization. OpenFlow 1.3 was recently released, but some said the process of getting there was far too slow. Now they wonder if they organization can pull off northbound API standards.

A number of the ONF's member vendors placed pressure on the ONF to begin northbound API work, said one source who is a contributor to an ONF working group. The demand came from need, and the organization responded accordingly, he said.

"They [the ONF] realized they can't just be about OpenFlow and more," said the source, who asked not to be identified. "We figured we ought to give them a chance to see if they can do this."

Another source who is a member of an ONF working group believes the standards are imminent and said that a new ONF working group would take into consideration reference work from the OpenDaylight controller and northbound API framework. He agreed that a fair amount of pressure had been placed on the ONF from its members to move toward standardization.

News director Shamus McGillicuddy contributed to this article.

Dig deeper on Northbound applications and interface

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

1 comment

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close