SDN Focus is brought to you in partnership with:

Matt has 20+ years of software-defined networking (SDN), cloud computing, SaaS, & computer networking experience. Matt is currently a Partner at Wiretap Ventures, a management, marketing, and product consulting organization for Cloud Service Providers and Software-defined networking companies. Matthew is a DZone MVB and is not an employee of DZone and has posted 6 posts at DZone. You can read more from them at their website. View Full User Profile

vSwitch is the New Battleground. What Every Datacenter Operator Must Know.

11.11.2013
| 6205 views |
  • submit to reddit

SDN vSwitch Network Virtualization OpenFlow

The virtual switch, soft-switch, or ‘vSwitch’ is quickly becoming the heart of every datacenter network. While the bulk of industry dissuasion, debate, and public activity around network virtualization today is centered around network virtualization or SDN controllers; the real battle for network virtualization (aka software defined networking) is over the vSwitch.
Multiple networking vendors and cloud service providers have asked us where could they acquire a team and technology to build their own vSwitch or build a new open-source vSwitch. We found that surprising, given the wide distribution of Open vSwitch — until we dug down a bit deeper.

What’s at risk? 

Billions in revenue, margins, and valuations. Including the business models and margin structures of any organization which has revenue or profit dependancies on physical or virtual data centers or networks, specifically anyone who is a cloud service provider (CSP)*. As well as which technology vendors and investors will end up as the winners and losses in the network virtualization market.

Editors Update 11/20/12: since this posting we’ve also written a post about the Risk of Open Source SDN software.

Importance of vSwitches

An over simplistic view is there will be a vSwitch on every server. In many data centers, between 48 or 72 servers connect to one physical switch. Meaning there is approximately a 50:1 ratio of vSwitches for every physical switch. Second, network overlay is the leading initial use case for network virtualization. With network overlays you encapsulate packets across multiple vSwitches that forward packets on top of a ‘dumb’ physical network as directed by a network controller that communicates to the vSwitch via OpenFlow or some other protocol. This makes vSwitches the prime real-estate for network virtualization within the datacenter.

What vendors own vSwitches?

A handful — Cisco, IBM, Microsoft, VMWare, and Nicira (now owned by VMWare). VMWare and Microsoft both have their own vSwitch and allow customers to install alternative vSwitches from Cisco and IBM in ESX and HyperV should they choose. Arista has unique capabilities to control VMWare’s vSwitch within ESX and our understanding is they do not own a vSwitch. Nicira has their own proprietary version of Open vSwitch (see below) that also works in Citrix CloudStack and Microsoft HyperV. The Cisco and Nicira vSwitches supports OpenStack via the Quantum plugin.

What about Open-Source vSwitches?

As of this writing, we are aware of only one viable open-source vSwitch**: Open vSwitch (OVS). OVS is embedded in Xen, KVM, and Virtual Box. OVS can also run in Microsoft HyperV and Nicira has hacked it to work within an ESX environment. Additionally OVS is bundled in Linux distributions from Ubuntu, Debian, and Fedora and is the vSwitch of choice for OpenStack via Quantum plugins. OVS has also been ported to Broadcom and Fulcrum reference switching platforms to eventually become the switching software used on high performance hardware switches. OVS is currently offered under the Apache license. Separately, two quasi open-source projects exist that could potentially be turned into a vSwitch: Indigo and Xorplus.

There is an Open-Source vSwitch, but no ‘Open’ vSwitch. 

Many of the more viable open-source projects (e.g. Linux, Apache, Tomcat, etc) succeeded in large part because there was a) large community of developers; b) had developer friendly licensing terms; and c) the contributions and governing bodies of those projects were not dominated by one company (or people affiliated with one company). This enabled a robust open-source ecosystem to emerge around these projects.
What’s different from these projects and OVS is the core contributions and governmence for OVS is controlled by a single company: Nicira.***

Of the 51 contributors listed on the OVS website 18 contributors work at Nicira. Making roughly 35% of OVS’s contributors employed at Nicira where they are paid to develop OVS. Nicira also employes the project lead for Quantum.

Editors Update 7/14/12:  The OVS Contributors page linked above at openvswtich.org has been updated, removing the list used in our research.  Here are the screen shots taken from the Contributors page on openvswitch.org on July 11th, 2012: 1, 2, and 3.  As of July 14th, 2012, a new page on openvswitch.org, lists 70 individuals who ‘have either authored or signed off on commits in the Open vSwitch version control repository’ of which 23 of them have a Nicira email address or roughly 32.8%).

The reality is Nicira controls the features, capabilities, and protocols supported within OVS and when they are released. Since OVS is ‘Open’ Nicira will gladly take your free labor to develop on OVS and give you an Apache license to ‘fork’ your own distribution; but they essecntially decide which features and protocols, from what contributors will be included in the mainline distribution at what time.  This basically masquerades OVS as the ‘free’ switch in a freermium business model where the vendor locks you in with their better, proprietary, paid for version. This is why many others in the networking community are looking for alturnatives to invest their time and development resources.

Furthermore, Nicira — effectively controls 2 of the 6 mainline vSwitches (OVS and Nicira’s proprietary vSwitch). This enables Nicira to leverage the OVS distribution channel to build an installed base to up-sell customers to Nicira’s propritary vSwitch. Only the much larger VMWare also enjoys this type of distribution benefit — and while the scarcity of vSwitches is a problem (3 or 6 via vSwitches controlled by VMWare & Nicira) — the bigger industry– wide issue is, at this early stage of market evolution, the amount of control these two companies have amassed on the vSwitch distribution channels to essentially block out other vSwitch vendors. One can argue that Cisco has the distribution muscle to get past this, but that still leaves the industry with three organizations controlling a) 75% of the viable vSwitches;and b) arguably a higher percentage of the vSwitch distribution channels.

This would not be a problem — if all the vSwitches supported an open, common protocol (perhaps OpenFlow or another standard) — but in this case — all of the commercially viable vSwitches by Cisco, Nicira, and VMWare support different proprietary protocols. Meaning customers get locked into an ecosystem.

How could this play out?

The real battle line is the Cloud Service Providers who demand for network overlay technologies to scale their business. Ironically — it’s many of the same CSPs who helped found the Open Network Foundation to change their cost structure — are now facing a situation of purchasing closed solutions from three vendors. Cisco and VMWare should be no surprise — they are established vendors with history of proprietary solutions.

Nicira on the other hand – is a more problematic situation — Nicira’s founders**** invented OpenFlow, are the stewards of the OpenFlow standard via Open Networking Foundation, and started On.Lab to further open SDN research — have allowed their company to a) take control of OVS contributions and roadmap while b) commandeering the OVS install base and distribution channels. This would make it trivial for Nicira to back away from OpenFlow and promote their proprietary (i.e. non-OpenFlow) protocol that only works with Nicira’s vSwitch and controller.

At the same time, Nicira has the power to ‘slow’ adoption of any technical advances or progress of OpenFlow by dragging the development or release of advanced OpenFlow standards on OVS. This would further distance Nicira and their proprietary approach from OpenFlow by effectively delaying a viable alternative from emerging – all while Nicira’s founders lead the Open Network Foundation guiding and encouraging 70+ member companies to make investments in OpenFlow.

If the inventors and stewards of OpenFlow were to abandon it (instead of work with the community to improve it) — any chance OpenFlow had to become a commercially viable solution would likely evaporate while killing the Open Network Foundation in the process.
This is the exact scenario we are privately being consulted with by senior business and technology executives at leading cloud service providers, networking vendors, and traditional service providers — and provides context around their questions of a) how can the industry create and support an open-source vSwitch that is truly independent from any one vendor; or b) a proprietary vSwitch they can control and own to ‘keep up with the Nicira’s’.

Where do we go from here:

I don’t have an answer today — though we are spending significant time on this topic  – we’d love to hear and discuss your point of view and ideas.

Notes:

* We define cloud service providers to include: SaaS vendors, internet exchanges, service providers, hosting providers, or mobile carriers, cloud platforms, web 2.0 companies.
** There’s also LINC is a brand-new open-source vSwitch that’s mostly lead and controlled by InfoBlox written in Erlang, a relatively obscure programing language
*** Similar situation for Indigo and Xorplus, they are respectfully controlled by Big Switch and Pica 8.
**** Martin Casado, Scott Shenker and Nick McKeown are a) co-inventors of OpenFlow; and b) founders and officers of Nicira; additionally Nick and Scott are founders and board members of the Open Network Foundation responsible for the advancement of OpenFlow; and founders and officers of ON.Lab.

Published at DZone with permission of Matthew Palmer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Hank Bruning replied on Mon, 2013/11/11 - 3:35pm

What kind of hardware is backing up the vSwitch software?  I need to read model/serial numbers , CPU temperatures and report them to the Data Center operator. Is there any kind of standard for the vSwitch hardware ? I'd like to talk to the hardware using IPMI.

http://architects.dzone.com/articles/scaling-ipmi-data-center




Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.