BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
In its early days, the Open Networking Foundation placed a strong emphasis on establishing OpenFlow as a means of physically separating the network's control plane and data plane and facilitating a means of communication between the two. The ONF saw OpenFlow's "southbound" functionality as an essential foundation on which a software-defined-networking edifice could be constructed.
Now that the OpenFlow cornerstone is in place (though the protocol will continue to evolve and mature), the ONF appears ready to move ahead with other aspects of SDN, including northbound OpenFlow applications. Last week it announced four new initiatives, one of which will focus on northbound application interface (API), or NB-API.
As the ONF press release notes, developers of network-control applications wish to write "for the northbound edge of an OpenFlow controller." To make that happen, the initiative will catalog and characterize existing APIs in a first step toward assessing market requirements.
The ONF's NB-API initiative was presaged in a "liaison letter" sent in June from ONF executive director Dan Pitt to the Internet Engineering Task Force (IETF). He wrote that the "ONF has not yet standardized the controller's northbound interface, or determined its nature," but that it was interested in "potential SDN use cases developed by the IETF with a view demonstrating how these can be expressed with ONF constructs, possibly as direct functions of the controller."
Why northbound OpenFlow applications are a threat to Cisco
Obviously, the ONF is looking at the NB-API question within the context of OpenFlow and OpenFlow controllers. This is different from how Cisco Systems views the world with its Cisco ONE and onePK API push. Cisco, of course, wants its proprietary switching hardware to have a prominent northbound role in providing analytic data and intelligence to programmers.
Cisco reluctantly acknowledges OpenFlow, but in the networking giant's ideal world, OpenFlow switches would not proliferate, server-based controllers would not decouple the control plane from the data plane, and Application-Specific Integrated Circuit, or ASIC-based networking hardware would remain a distinct fiefdom of sustainable competitive differentiation, robust margins and privileged standing in the world of cloud computing.
The ONF is set on a diametrically opposed outcome. Anybody who's seen, heard or read transcripts of ONF presentations knows that the ONF envisions "networking becoming a part of computing," effectively serving as a deferential element of virtualized infrastructure. The ONF says its mandate is to put power into the hands of customers rather than those of vendors, and to make the network more responsive to the needs of those who operate and use it rather than to the near-term business imperatives of those that sell the gear. The ONF, its technologies and its role as the catalyst of the SDN movement probably represent a bigger threat to Cisco's long-term business interests than do conventional Cisco competitors in "legacy networking."
Cisco, as I've noted previously, has never before met this sort of customer-led, demand-side challenge. The ONF is directed and carefully controlled by customer organizations that refuse to allow vendors to serve on its board and are wary of vendor-led agendas. There's no reason to think that it will cede control of the SDN agenda to the vendor community.
The ONF also is in no rush to standardize on a northbound API. Following the conventions of the software-development world rather than the protocol-incubating rituals of the IETF, the ONF is content to allow the market to decide the matter, just as Roy Chua speculated last month at SDNCentral.
Controllers that get adopted and that develop thriving ecosystems are likely to define the primacy of specific northbound APIs.