Published by Sunay Tripathi

We closed our Series D financing right before Christmas. This is a $50M round led by Temasek and Ericsson. Ericsson, you probably know. Temasek is a $170B plus sovereign fund out of Singapore that is best described as the Berkshire Hathaway of Technology. They were the people responsible for investments into Alibaba. This shows that with Netvisor, our OS/hypervisor, gaining traction in Enterprise Datacenter and Private Cloud markets, the bigger players now believe that SDN switching and applications on Server-Switches is real.

The funding is primarily to scale our business side and help sell more products, build support infrastructure and create an application group that can write more applications on the Netvisor platform to exploit the world of programmable networks.

 

Netvisor as an Application Platform

The best way to explain this is to draw a parallel between Netvisor (as a switch Hypervisor) and a Smartphone.

When Apple released the iPhone, the world was full of small hardware devices like cameras, dedicated GPS navigation systems, etc. IOS (and later Android) took over the world of mobility not because of the phones themselves but rather because of the applications that could run on the phones and the capabilities that well-developed platforms gave mobile developers.

Netvisor is creating the same paradigm for data center switching. Today, you have a physical fabric, a separate visibility fabric (using taps and probes which are sometimes expensive than the physical network they are monitoring), hardware appliances for services and separate overlay networks with their controller appliances, a situation akin to that drawer full of dedicated, application-specific gadgets. Since Netvisor is a Distributed Bare metal Switch OS, all this functionality, previously delivered by dedicated boxes and appliances, can now be delivered via software running on Netvisor. The App Store has come to the network.

Applications “On Fabric “

Continuing to draw parallels with the world of smartphones, IOS enabled a whole new generation of applications. The application could, for example, send data to the network via an API call – the developer could write the application assuming that connectivity would be available through the platform, she didn’t need to understand the details of the underlaying 3G/4G/LTE/bluetooth/Wifi network that carried the data. More importantly, her application doesn’t have to deliver the protocol stack to provide the connectivity, all that was provided by the platform. Netvisor provides the same functionality to network application developers. The network fabric can be Layer 2, Layer 3 or Tunnel based but the applications are always “On Fabric ” and don’t have to understand the physical topology of the network or how the network is connected.

As a function of the platform, the fabric is built with Layer2/3/VXLAN via Netvisor CLI/UI while applications use Netvisor C/Java/Rest APIs and fabric abstractions to program the network, get the analytics, or provide services.

Open Fabric Virtualization – Unify the Overlay and Underlay

We always believed in a data and control plane separation but we always kept the real world in mind. That is why Netvisor has always had a distributed, bare-metal control plane. And it is with these same real-world considerations in mind that we documented several years back that centralized control planes will not scale (see https://sunaytripathi.wordpress.com/2012/07/31/how-does-openflow-sdn-help-virtualizationcloud-part-3-of-3-why-nicira-had-to-do-a-deal/).

While our approach of doing bare-metal control plane (separate from data plane) is earning increasing validation, we see much of the industry going on a tangent with separate overlay and underlay networks. This is the wrong approach, one which complicates the server and network and hinders visibility as well.

We are currently starting beta tests of Netvisor Open Fabric Virtualization, a service that offloads VXLAN tunnel processing overhead from host machines back onto the network, where we allow the tunnels to move to switches and encapsulation rules are created to switch hardware on demand.

When a VM wants to talk to another VM, Netvisor gets the ARP packet (or a L2 miss) and automatically creates encapsulation rules using its vflow API. This allows the servers to go back to being Linux/KVM based servers without worrying about tunnels and network topology and lets Netvisor based switches to deal with tunnel tables the same way they deal with switching tables and routing tables. This helps make for a more efficient overall data center as tunnel workloads, which are not handled very efficiently or cost-effectively by general x86 compute resources are moved onto the network where they are very capably handled by switching hardware, which is now doing exactly what it was designed for. Better performance, less power consumption, and tools all being used the way they were intended to be.

Summary

2015 is going to be an interesting year. We have the funding to accelerate a variety of activities at Pluribus, which is going to help push us to a tipping point. On a larger scale, we also see large scale SDN reaching a tipping point. Networking will finally arrive in 21st Centaury.