Published on SDN Central

The momentum around the Software-Defined Networking (SDN) Northbound API keeps growing. When is it going to be standardized? Who is in charge of standardizing it? Which implementation is likely to be the most adopted?

Before getting into these questions, let’s first take a closer look at what defines the Northbound API. There are two APIs in the SDN architecture, as shown on Figure 1 below:

• The Southbound API allows for physical and virtual switches to exchange control information with the SDN controller platform. This API could be proprietary or standard. The only industry standard today is OpenFlow developed by the Open Networking Foundation (ONF).
• The Northbound API makes the control information of the network available to higher instance abstractions such as applications. They could be traditional network services such as firewalls or load balancers or orchestration across cloud resources (storage, compute and network) like OpenStack.

Figure 1 – SDN Architecture Diagram

Early on, the Southbound API got a lot of visibility thanks to the growing adoption of OpenFlow by major physical infrastructure vendors (HP, Brocade, Juniper, Extreme, IBM and soon Cisco) and the wide availability of virtual switches with interfaces providing network control information. Now that the foundation for SDN-enabled infrastructure is becoming more of a reality, all the attention is turning to the Northbound API.

—

Why so much interest? SDN disrupts the traditional networking market dynamics and several companies want to seize the opportunity to innovate and capture value. The Northbound API has several attractive characteristics over the Southbound API especially for smaller companies trying to get into the networking market.

First the Northbound API is not constrained by hardware innovation cycle time. Looking at Figure 2, we see that both ends of the Northbound API live in software products. This enables faster development cycles, lower investment costs and easier trial and error approaches compared to the Southbound API.

Figure 2 – Hardware and Software in an SDN Architecture

Contrary to the Northbound API, the Southbound API is tightly dependent on the forwarding plane of the underlying physical infrastructure. It takes on average two years to build a new switch (hardware and software) from scratch, and subsequent hardware refreshes (reusing the same software) take 9 months. In addition of long development cycles, these projects require significant upfront investment. Even if newcomers focus on the software end of the Southbound API (i.e. the control plane), they are highly dependent on the innovation pace on the network side of the API. In contrast, developing on top of the Northbound API only requires software investments enabling faster innovation and solution creation. These SDN applications can continuously evolve over time without any deadline or dependence on fixed hardware components. A more agile execution means less risk for companies to get into new markets and a shorter path to revenue generating products.

Second most of the SDN value will be created and captured at the application layer on top of the Northbound API. Everything below this API (i.e. the control and forwarding planes) still delivers the same traditional networking functionalities. The main difference is in the architecture with control information logically centralized for the entire network instead of distributed across multiple networking devices. The network basically keeps doing the same thing; what is new is that applications can now access all the network control information via the API. The network can thus be programmed with software applications instead of command line interface (CLI). SDN applications can instantly change network configuration to make it aligned with business objectives such as forwarding packets over the least expensive path, dynamically adapting QoS based on available bandwidth and user subscription, dropping suspicious packets and tracking back their source for containment, etc. Security, traffic engineering, multi-tenancy management, network monitoring and so forth are just a few examples. These applications solve real networking problems and have an ROI easier to justify than the controller or the OpenFlow support on a switch (the later typically is a free feature). Each problem requires a different type of expertise and each application can be tuned for a specific market segment making the realm of possibilities endless in a space used to slower innovation cycles as discussed earlier.

Finally market dynamics favor the Northbound API for newcomers since traditional networking vendors have a competitive advantage on the Southbound API. Incumbents already own an installed base of customers and control the pace at which the Southbound API is implemented on their equipment. Most of them are large companies (such as Cisco, Dell, HP, Juniper, etc.) with significant resources and strong incentives to maintain high  barriers to entry. On the other hand, the Northbound API has less legacy and many more players. The SDN application market is more diversified with smaller and more specialized players leaving room for newcomers to innovate and create new complementary services alongside more traditional vendors. IT departments are craving for more diversity and more openness for their cloud infrastructure. OpenStack, CloudStack and others are great illustrations of this trend in the orchestration market.

—-

So with so much value to offer, why is the Northbound API still not standardized? Well by its very nature, i.e. software, the Northbound API is very different than past networking protocols. Per our point earlier, developing an implementation of a protocol linked to hardware components is time consuming and requires significant investments. In the past, organizations like IETF or IEEE took a lot of time upfront defining standards before members agreed that they were stable enough to implement and invest in. One example could be VXLAN, standardized back in mid-2011 and coming out in implementations only now.

In software ecosystems, the process is very different. Implementation takes place first and standards emerge later, driven by developer adoption. Different companies offer a variety of APIs and SDKs and the market adoption will then decide which of these APIs/SDKs become the de facto standards. There could be more than one winner. A good illustration would be the mobile application industry where mobile platforms can be compared to networking platforms (or controllers) the Northbound API based on. iOS SDK was released in March 2008 and currently has more than 700,000 applications. Android SDK was released in June 2012 and already has more than 600,000 applications. They are the clear de facto standards on which most of the mobile innovation is taking place. One the other hand, Nokia Ovi Store and Blackberry have failed to impose themselves with less than 30,000 applications for their respective platform.

Criteria for a successful standardization for APIs/SDKs are numerous. The most obvious are number of developers familiar with the programming language used, friendliness of the development environment, level of abstraction and quality of the information offered as well as licensing model for monetization and Intellectual Property(IP) protection.

As SDN is still an emerging industry it is too early to define all these unknown to properly standardize the Northbound API. Networking was not exposed to too much programing in the past so language and environment are still uncertain (C has been widely used on switches but most of the current API gravitate around REST and Python). None of the SDKs are really friendly at the moment as companies are more focused on defining the abstraction and depth of the network control information provided. Indeed security applications need a different set of parameters than load balancer or orchestration ones. The licensing model is also still evolving but, at the moment, open source projects are very popular.

For all these reasons, the ONF has concentrated its standardization efforts mainly on OpenFlow and left the Northbound API to individual companies creativity until the market matures and selects the best API implementations as the foundation for standardization effort. This said, while the ONF is not standardizing this API, it still ensures that the underlying architecture will be able to provide the forwarding abstraction and other dependencies the API will rely on. This role is assumed by the newly created Architecture and Framework Working Group.

—

So who will be the winners of this gold rush? There is a broad variety of strategies being used at the moment. The Northbound API is part of the controller and obviously controller vendors have a strong incentive to have their API and SDK adopted by as many developers as possible.

Within the traditional networking vendors, some companies like HP or Cisco provide the whole SDN stack (existing switches, newly developed controller and existing applications such as network management or orchestration) with more or less openness on the Southbound API (HP uses OpenFlow while Cisco keeps it proprietary) and an open API for the Northbound (Cisco names its one PK) limiting their partnership to the application level. Others like Dell, Extreme or Brocade have decided to focus on their current core competencies (existing switches and applications) and partner for the controller platform using either their own Northbound API (Dell calls it the Dell abstraction layer) and/or the controller partner’s one.

Newcomers have a different approach altogether. Some like Nicira/VMware or Midokura prefer to control the whole stack (switch, controller and application) limiting the scope of their solution by the number of environments supported and the number of applications offered (in Nicira’s case network virtualization). Others like Big Switch focus on the controller and application layers providing an open Northbound API for application partners to complement their offering. Finally others like Pica8 or Plexxi prefer to control the forwarding plane and deliver switches and controllers with or without an open Northbound API and applications. Most of them are using open source as licensing model either Apache or General Public License (GPL). Finally a new category is appearing with companies only developing SDN applications like vArmour and making a bet on a few vendors Northbound API to define their addressable market.

—

The Northbound API is a new revolutionary concept in the networking industry. Dynamics are different and software innovation cycles can take place independently from underlying physical infrastructure. But we are still in exploratory time and market leaders have not emerged yet. As knowledge of users and developers needs keeps increasing, standardization will progressively emerge.

In spite of many uncertainties, the promise this API holds is strong enough to attract many players, networking incumbents and start-ups, all racing to develop a massive ecosystem of applications around their API and become the de facto standard and as a result market leader.

Like with the Gold Rush, the first explorers to have found gold did not necessarily become the richest, neither did those with better gold-recovery technique. Merchants around the miner ecosystem did. They captured more value than miners. Similarly, while Northbound API and controller vendors are key to unlock the value of a Software-Defined Network; they may not capture most of that value. Applications are where the richness of the ecosystem lies, and this is clear to all the vendors who turned their attention to the Northbound  API. Regardless of their personal success, all 49-ers contributed to the creation of a new territory that is now one of the driving forces in this world; SDN pioneers including controller vendors will similarly change the networking landscape for good.