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 email@example.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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.