Things To Consider For Your SDN Strategy : OpenFlow

Social Share Toolbar

SDN expands the realm of possibilities for cloud networking and, per my earlier blog, there are many ways to address current and future network limitations. When considering an SDN solution, you should be clear on what problem you are trying to solve and over which period of time you will roll out your SDN solution. Since this is an emerging market and many players and solutions are first generation, you should also assess the level of risk you and your organization are willing to assume.  Regardless of the use cases you have in mind, I will discuss in my next blogs and this one a few major criteria to consider when defining your SDN strategy and selecting your vendors, with the first of them being going or not with OpenFlow.

Many companies are working together around OpenFlow to standardize SDN but not all these companies are implementing it today.

Some consider OpenFlow not mature enough. Indeed this standard is the most common denominator among the set of features supported by forwarding planes and different vendors. If some vendors want to innovate further than traditional networking features, this could be limiting. An option would be to use OpenFlow extension field where each vendor can exchange information between the forwarding devices and the controller and another option would be to create one’s own protocol as a complement or replacement for OpenFlow. For instance, NEC has opted for the former option; following the OpenFlow standard (OpenFlow v1.0) and leveraging the extension field for unsupported functions like IPv6 (only coming with OpenFlow 1.2 and 1.3 versions). While Cisco seems to be doing the later; OpenFlow enhanced by the proprietary OnePK protocol for functions specific to their forwarding plan.

The table below summarizes the current support for a few selected representative companies. While most incumbents support OpenFlow, start-ups are equally split between OpenFlow and proprietary protocols. As the technology matures and new versions of the OpenFlow standard are released, we should expect more players supporting OpenFlow. Players with the most significant market share (Cisco, Juniper, VMware) are trying to retain control with the promotion of their proprietary protocol in parallel of OpenFlow support.

Vendor specific interfaces may become successful if the associated forwarding plane (switch) or the integrated end-to-end solutions gain enough market share or address the needs of a broad enough installed base. For instance, in Table 1, players leaning towards vendor-specific interfaces are incumbents with a large market share (Cisco, Juniper, VMWare) or players targeting a large installed base (Anuta only supports Juniper, Cisco and VMWare environments) or players offering their own forwarding plane (Plexxi, Midokura) for an integrated solution.

 

OpenFlow

Vendor specific

START-UPS

Anuta

X

Big Switch

X

Glue Networks

X

Midokura

X

Pica8

X

Plexxi

X

Pluribus

X

Vello

X

ESTABLISHED

Brocade

X

Cisco

X

X

Juniper

X

X

Dell

X

HP

X

IBM

X

NEC

X

VMWare

X

Table 1 – OpenFlow or vendor specific support

 Understanding vendor dynamics and logic around their OpenFlow offering should help you make informed decision for your SDN strategy.

In the long run, OpenFlow support should be in the best interest of customers as:

  • It enables multivendor environments. It is always a good thing to keep the option of having several vendors in your network or of switching vendor later down the road if needed.
  • It also offers a nice horizontal architecture for your network to evolve separating the hardware platform from the applications.

This said, taking advantage of this flexibility by selecting the best of breed vendors comes with a price. You will have to ensure interoperability between your selected vendors and that may require some integration work for features beyond OpenFlow.

Now if you have (or plan to have) OpenFlow-enabled platforms in your existing network from different vendors and/or have significant software development resources (like Google or Indiana University), the integration investment may very well be worth it and you will end up with a better customized solution and a real competitive differentiator.

If the solution you need today does not support OpenFlow, you should make sure to understand when it is scheduled on the roadmap, and how easily it will be added later on as well as the level of prioritization for your vendor.

In the short term and especially if you are deploying SDN in a greenfield environment or as a new extension of your network (e.g. new data center), you may decide to let go the OpenFlow criteria. Several useful applications have been developed by start-ups without OpenFlow. This was a conscious choice so their R&D resources could focus more on the logic and application above the forwarding plane than keeping up with the different OpenFlow versions.  If you are going down this path:

  • There are many solutions available today without OpenFlow. So if you find an SDN solution addressing your main pain point (e.g. VM migration, tapping, simplified network operations, traffic engineering, device management or else) and need it urgently, this is probably the best way to go.
  • The deployment should be fast and easy since it is contained and vertically integrated (i.e. same vendor for the physical or virtual switch, controller and even some applications).
  • But adding more solutions later on will mean adding different vendors (e.g. for firewall, load balancer, data traffic analysis etc.) and this may not be as straightforward. Since OpenFlow is not supported, you will have to make sure that your vendors will collaborate around integration and interoperability testing.

Finally there are use cases where the OpenFlow criteria is not relevant, for instance,

  • When looking at L4-7 network services only comparable to what Embrane offers, or
  • When directly integrating at the cloud management layer like Lyatiss, or
  • With a Network-As-A-Service subscription like what Pertino offers.

I have tried to summarize my point in this table but keep in mind that this is very generic. It is meant to help your thought process but has to be put in perspective. There are exceptions. For instance, a vendor that integrates with Cisco and VMware proprietary APIs would fit very well for an existing network and would require minimum integration cost without support of OpenFlow.

OpenFlow

Not OpenFlow

Pros

Cons

Pros

Cons

Multi-vendor environments Standard still evolving More choice available today Vertically integrated (vendor specific)
Solid foundation for future SDN evolution Slower time to market – less choice Contained simple and fast deployment Extra work later on to define a platform across vendors (retrofit to OpenFlow)
Easier integration with existing networks More integration effort to support multiple vendors day one Easier for greenfield or network expansion

I will discuss other aspects you should consider in your SDN strategy, but please feel free to share your thoughts with me posting a comment or sending it to info@sdneasy.com

SDN Start-Ups You Will Hear About in 2013

Social Share Toolbar

Published on SDN Central

Many SDN start-ups came out of stealth mode in 2012 and a few others are gearing up towards launch in 2013. As the momentum around SDN increased, so did the number of start-ups in this space. Keeping track of their development stage, their offerings, and more importantly the problem(s) they aim to address is a difficult task. This blog is an attempt at providing a snapshot on SDN start-ups worth watching in 2013.

Increasing SDN Innovation. I had the pleasure to interview 11 start-ups (see below) in Q4 2012. All were very supportive of this blog as they recognized the need for more education on SDN to help customers understand relative positioning..

1 SDN Start-Ups List

 Figure 1 – SDN Start-Ups Worth Watching in 2013

SDN is a broad and powerful concept but it can be implemented in many different ways. Each of these start-ups turns SDN into a reality but each innovates in a unique manner, supports different IT environments and solves a variety of customer issues. Each player addresses an important piece of the puzzle and can win a defined segment of the market.

Today SDN is still an emerging market and we cannot really talk about competition between these companies. For now, customers should focus on which one is solving their problem and work in their environment while investors should look at solidifying their portfolio across multiple complementary solutions.

Growing VC investment in SDN. Thirteen Venture Capital (VC) firms are behind these eleven start-ups. LightSpeed Venture Partners has the highest number of investments in this space with Embrane, Plexxi and Pertino and shows a great diversification strategy (their offerings – described later – are quite different). Koshla Ventures (Big Switch and Contrail), New Enterprise Associates (Embrane, Pluribus) and Northbridge Venture Partners (Embrane, Plexxi) have two investments each while the other VCs have invested in only one of the start-ups I interviewed.

2 SDN Start-Ups Reference Series Figure 2 – Amount of VC funding

On the figure above, comprehensive seed funding information is missing but can in general be assumed to be less than $2M. Lyatiss series A is not public information. Vello is owned by the management team and its employees and has no VC funding.

Start-ups with pure software offering have received series A and/or series B funding ranging between $10M (Contrail) to $39M (Big Switch). I expect Plumgrid, Pertino and Lyatiss to run for a Series B shortly. Contrail was acquired by Juniper in December 2012.

Higher investments and series C have been made for companies also delivering hardware in their portfolio such as Plexxi (with a total of $48.5M) and Pluribus (with $42M). Pica8 is the exception to this rule, thanks to bootstrapping and early generation of revenue from traditional networking products.

3 SDN Start-Ups Reference SeriesDates

Figure 3 – Timeline of VC funding

Young, moving fast and evolving the SDN architecture. Most of these companies were created between 2010 and 2011 and six have already launched. Contrail, Lyatiss, Pertino, Plumgrid and Pluribus are still in stealth mode at the time of writing, though that should not last much longer…

Individual offerings will be described later but let’s start with the most common trends:

  • Application Plane – In my previous blog, Network Virtualization was one of the possible applications developed on top of the northbound API offered by the controller. Many start-ups have also developed applications on top of network virtualization to create another application layer within this plane.
  • Northbound API – As a result there are now two types of Northbound API: one at the controller level usually used for network services (like firewall, load balancer etc.) exposing more granular information, and one at the network virtualization level for more abstracted applications like cloud orchestration.
  • Control Plane – Most of these vendors offer centralized access to the network control information but often with distributed logic behind it in the form of software or VM hosted across multiple servers or switches or appliances or mix of the above.
  • Southbound API – To reduce complexity and dependency, several solutions often include some part of the forwarding plane (usually via software agents deployed directly on edge devices and/or network switches)removing the need to open up their southbound API to other vendors with OpenFlow. In all cases, OpenFlow is still a roadmap item tough.
  • Forwarding Plane – Here the distinction between virtual and physical switches goes a step further than in my previous blog with, for instance, a virtual switch with an origin that could be different from the server OS or hypervisor vendor.

To illustrate these points and simplify comparisons, I will use the following SDN architecture as a reference to describe each vendor solution.

4 SDN Start-Ups Reference Arch

Figure 4 – Reference Architecture

SDN for the Physical Infrastructure

While many vendors plan to support OpenFlow on their switches, few switches are available today and most of them only support OpenFlow v1.0 (instead of v1.3, the latest standard version issued by the ONF).

Several start-ups have decided to build their own physical switches as show on Figure 5 (e.g. Pica8, Pluribus, Plexxi, Vello) to control and accelerate innovation on hardware components. Often they decouple the software hosted on these switches from the hardware itself to facilitate programmability. The separation between control and forwarding planes become blurred. In these configurations, the controller is no longer limited to just collecting control information and instead also handles the networking operating system of these switches managing firmware upgrades, for instance, or having services delivered on the switch itself (versus at the application layer). In other words, the switches themselves become programmable not just the network.

5 SDN Start-Ups Reference Environment

Figure 5 – Support of pSwitch and vSwitch

SDN for the Virtual infrastructure

Some start-ups have decided to focus on virtual switches only. Many are supporting Open vSwitch (OVS) or even packaging it with their offering, some added their own code to Linux bridge (less sophisticated than OVS) or interface with open APIs from VMware (for vSphere switches – former ESX) or Microsoft (for Hyper-V virtual switch).

OpenFlow proving to be a nice to have but not a must

As mentioned earlier, to remove dependencies or innovate faster than the current standard, many SDN start-ups do not support OpenFlow today unless they leverage OVS or other open source offerings. Since OpenFlow is the most frequent migration path of currently deployed physical switches (from Juniper, Brocade, eventually Cisco etc.), these solutions are targeted at customers expanding or replacing their physical network, or deploying SDN on their virtual infrastructure only.  In the long run, all these companies plan to support OpenFlow to enable support for multi-vendor environments. Customers should then be able to deploy SDN by simply upgrading their existing infrastructure.

6 SDN Start-Ups Reference OpenFlow

Figure 6 – OpenFlow Support

Open API but… open to whom?

While the majority of start-ups offer an open Northbound API, the proactive development of an ecosystem around it is usually still limited. At the moment, most companies focus on developing their own in-house applications and adding partners as dictated by customers’ production environments. As their solutions become more mature so will their packaging and go-to-market and more partnership announcements should be expected.

SDN and Cloud orchestration

Several of these start-ups integrate with cloud orchestration software such as OpenStack, CloudStack or vSphere. The level of integration and dependency varies a lot. Some offer a plug-in so any changes made by the user at the cloud orchestration level will be reflected on the underlying network while others use these orchestration applications as their own management interface.

Individual SDN Start-up Snapshots

This section is intended to show the variety and creativity generated around SDN by each start-up. A simple reference model (shown in Figure 4), a brief solution description and a highlight of their differentiators should help you get an initial overview. I have collaborated with each and every one of these companies to ensure that each snapshot reflects public and accurate information.

To limit the length of this blog, we will roll out 3 or 4 start-up snapshots a week in reverse alphabetical order. If you would like to see a start-up added into future blogs, please send your suggestions to info@sdneasy.com.

How to read the reference diagram

  • Colored components are the components offered by the vendor.
  • Grey components are components offered by partners via the vendor’s open API.
  • Absence of components compared to the reference diagram means that they are not part of this vendor’s solution or do not require an interface (i.e. API).
  • OpenFlow support is indicated by the OpenFlow logo on the southbound interface between the controller and the associated networking device.

BIG SWITCH NETWORKS

7 SDN Start-Ups Reference Big Switch

Figure 7 – Big Switch Networks Architecture

Big Switch Networks offers a controller and two SDN applications: Big Tap and Big Virtual Switch (their network virtualization application). The commercial controller is based on an open source code (Floodlight) enhanced for high performance, high availability and other functionalities. Two northbound APIs are available one on the controller itself suited for network services and one more abstracted on top of Big Virtual Switch for more advanced applications like orchestration. The southbound API is based on OpenFlow and support both physical and virtual switches.

It is worth noting that Big Switch Networks is the only start-up offering an SDN controller supporting physical switches but not manufacturing its own networking device. In addition of the usual network virtualization, they also offer a non-intrusive application (Big Tap, an out-of-band network monitoring) that only requires the addition of OpenFlow-enabled switches (no upgrade or replacement of core switches already deployed). Finally they have one of the most developed ecosystem of partners on both the southbound and northbound APIs.

CONTRAIL SYSTEMS

8 SDN Start-Ups Reference Contrail Systems

Figure 8 – Contrail Systems Architecture

Contrail Systems offers Network Virtualization via at a Layer 3 overlay level and can communicate with any infrastructure device supporting the new IETF Draft (BGP-signaled end-system IP/VPNs draft-marques-l3vpn-end-system). They also offer an agent hosted on virtual switches. In addition of network virtualization, network services such as load balancing and firewall are available. An open API allows for 3rd party to add their applications or to integrate with orchestration applications such as OpenStack.

It is worth noting that Contrail offers their solution as software on premise but also in the cloud and that a Layer-3 approach compare to a Layer-2 overlay allows for network appliances already in the infrastructure to be reused easily.

Note that since I started working on this blog, Contrail Systems has been acquired by Juniper Networks.

EMBRANE

9 SDN Start-Ups Reference Embrane

Figure 9 – Embrane Architecture

Embrane provides network services and a solution to orchestrate them that runs on top of both traditional and software-defined networks. It optimizes the delivery of L3-7 network services from Embrane (load balancer, firewall/VPN) or 3rd parties and allows charging for these services based on subscription, usage or perpetual licensing. Their solution can run in both Citrix and VMware environments.

Unlike other start-ups, Embrane does not configure or change the underlying infrastructure (traditional or virtualized). This explains why in the past they claimed not to be an SDN company, to highlight this difference. But, in my opinion, they definitely contribute to make networks more software-defined. It is worth noting that Embrane can run on any existing infrastructure (e.g. switches, routers) and with any deployed network appliance as they focus solely on network services and their usage optimization.

LYATISS

10 SDN Start-Ups Reference Lyatiss

Figure 10 – Lyatiss Architecture

Lyatiss’ solution interfaces any network software used in cloud deployments. It optimizes traffic between storage and compute resources of public or private clouds in order to optimize application performance and availability as well as cost for customers using multiple cloud providers in different geographic zones or for different applications.

It is worth noting that Lyatiss focuses on the logic behind the existence of a flow (i.e. why and how applications are accessing compute and storage resources) as well as different cloud providers’ billing and performance systems to dynamically adapt the cloud subscription. Unlike many SDN start-ups, Lyatiss does not change the infrastructure itself (i.e. configuration of the switches) but acts through the cloud application and network service API to serve both cloud providers and their customers.

MIDOKURA

11 SDN Start-Ups Reference Midokura

Figure 11 – Midokura Architecture

Midokura offers an integrated SDN controller and network virtualization software under the name of MidoNet. MidoNet is part of an end-to-end solution that includes a virtual switch that sits on the hypervisor and communicates over the physical infrastructure via tunnels to edge gateways. Policies are implemented at the edge on a virtual topology and then dynamically reflected on the underlying infrastructure. MidoNet is distributed on multiple servers and can also interface other SDN controllers and 3rd party applications like OpenStack via its Open Northbound API.

It is worth noting that Midokura has been extremely active (and recognized) at OpenStack. Its offering also integrates with other cloud orchestration solutions such as CloudStack. While MidoNet focuses on virtual switches only, integration with other SDN controllers make the expansion to the physical infrastructure possible in the future.

PERTINO

12 SDN Start-Ups Reference Pertino

Figure 12 – Pertino Architecture

Pertino provides a Network-As-A-Service offering where subscribers download an agent on their devices that sends traffic and information to Pertino’s virtual switches located at different cloud datacenter-based POPs that host the SDN controller. Network virtualization and other services from Pertino (and in the future their partners) are performed as an overlay to one or more service provider infrastructures as subscriber traffic flows end-to-end through the Pertino cloud solution. Subscribers can then benefit from improved network performance and programmability anywhere their devices are and add applications as needed.

It is worth noting that Pertino is not a traditional SDN vendor. They do not offer SDN equipment but a NaaS solution that leverages SDN technology. They also use their own cloud orchestration technology to manage their services, optimize their resources and provision and bill their subscribers.

PICA8

13 SDN Start-Ups Reference Pica8

Figure 13 – Pica8 Architecture

Pica8 offers a physical switch that can be used as a traditional switch (in IP Fabric mode), an OpenFlow switch (in SDN mode) or as a hybrid switch. The network OS is distributed between all the switches and a few servers that also host the management software and a 3rd party OpenFlow controller. The controller uses OpenFlow and, as a result, can interoperate with both physical and virtual switches. Pica8 includes Open vSwitch (OVS) as part of its offering. RYU is the open source controller used for its reference architecture but they also demonstrated interoperability with Floodlight and NOX.

In my opinion, one of Pica8’s strengths is to have a traditional networking offering that can progressively become SDN over time. Being one of the few start-ups using OpenFlow, Pica8 can virtualized both physical and virtual infrastructure as well switches from other vendors delivering significant openness in their architecture.

PLEXXI

14 SDN Start-Ups Reference Plexxi

Figure 14 – Plexxi Architecture

Plexxi delivers network orchestration and control in the form of software distributed on switches and centralized on servers. The network orchestration dynamically modifies the Plexxi network configuration based on workload affinity requirements received via APIs from applications or cloud orchestration systems. Their switches offer traditional Ethernet and Optical ports with the latter used to interconnect Plexxi switches. A Northbound API allows workload affinities to be exchanged with business applications, networks services, cloud orchestration or network virtualization applications as well as with other SDN controllers or traditional networks.

It is worth nothing that Plexxi offers an SDN solution for Plexxi networks and could be enhanced to potentially other non-Plexxi physical switches or virtual switches via other SDN controllers.

PLUMGRID

15 SDN Start-Ups Reference Plumgrid

Figure 15 – Plumgrid Architecture

Little can be said with certitude on Plumgrid solution as they are still in stealth mode and more secretive than average. I will share my personal expectations about their offering based on readings and discussions within the SDN community and with them.

Plumgrid solution is entirely software and includes network virtualization. OpenFlow will not be supported day one but as the standard evolves and becomes more complete there could be a convergence. Based on the background of the team I suspect that even with a software solution,tight integration will be done at the chip level and thus I expect Plumgrid to support both virtual and physical infrastructure.

PLURIBUS

16 SDN Start-Ups Reference Pluribus

Figure 16 – Pluribus Architecture

Pluribus delivers a physical switch called server-switch that runs Netvisor, their distributed network operating system as well as SDN controller capabilities and network services. Pluribus offers services such as load balancing, DHCP, DNS, Firewall etc. Their integrated SDN controller also supports OpenFlow to interface with OVS for the virtual infrastructure and potentially other physical switches as well.

A few facts are worth noting. Pluribus solution is entirely distributed across its physical switches. Pluribus is also part of Oracle Partner Network as their solution is based on Linux and their Northbound API is actually the Linux API.

VELLO

17 SDN Start-Ups Reference Vello

Figure 17 – Vello Architecture

 Vello offers OpenFlow-enabled physical Ethernet and optical switches and virtual switches (OVS) as well as SDN controller functionalities, network services and network virtualization. Vello has several applications running on top of their network virtualization such as storage replication and disaster recovery. Through the OpenFlow support, their solution can handle both physical and virtual infrastructure as well as any OpenFlow-capable switch from other vendors. Vello has very specific use cases and applications that facilitate the access and management of storage devices.

 

 

 

The SDN Gold Rush To The Northbound API

Social Share Toolbar

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 (HPBrocadeJuniperExtremeIBM 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. OpenStackCloudStack 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.