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..

 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.

 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.

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.

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.

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.

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

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

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 3^rd 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

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 3^rd 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

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

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 3^rd 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

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

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 3^rd 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

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

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

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

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.

 

 

 

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.