9 Comments

Summary:

VMware teamed up with Stanford and Berkeley on Tuesday to create an industry consortium around software defined networks, called the Open Networking Research Center. The company, famous for its hypervisors that virtualize servers isn’t about to watch while others build the same disruption in networking.

P8095034

VMware teamed up with Stanford and Berkeley on Tuesday to create an industry consortium around software defined networks, called the Open Networking Research Center. The company, famous for hypervisors that virtualize servers isn’t about to watch while companies attempt to build the same disruption in networking. The consortium counts CableLabs, Cisco, Ericsson, Google, Hewlett-Packard, Huawei, Intel, Juniper, NEC, NTT Docomo, Texas Instruments and VMware as its founding sponsors.

Much as server virtualization abstracts the hardware for the software that runs on it, allowing people to put different virtual machines on top of one server, virtualizing the network abstracts the cables and ports from the demands of the applications. But that’s not enough. To really achieve the flexibility that webscale and cloud companies demand, the network must be both virtualized and programmable.

The current enabler for this shift in networking is OpenFlow, a protocol developed out of Stanford and championed by a group formed last March called the Open Networking Forum. Many of the companies that have joined the VMware at the ONRC are also members of the ONF, including VMware. OpenFlow is a means to separate the intelligence associated with moving packets around the network with the gear that does the moving. At that point the intelligence can run on commodity servers, a factor that was seen as bad news for Cisco, Juniper and other networking companies which may see their margins drop and profits erode.

Allwyn Sequeira, CTO and VP for security and networking for VMware says that the creation of the ONRC is designed to push the concepts of software defined networks in general rather than the OpenFlow protocol. He said an SDN requires three elements: a controller that manages the networking gear; the controller protocol fused to control the devices (this may not be OpenFlow); and the apps on top of the controller that direct the network.

And he notes that OpenFlow adds the critical element of programmability to networking, likely residing in the controller with other protocols, but the creation of a software defined network doesn’t need it. He points to VMware’s own firewall and load balancing products as well as its VXLAN and other networking software as an example.

VMware's networking products.

That’s a common argument from the industry, with folks from Juniper and Cisco pointing to their existing fabrics and products as an example of network virtualziation. So the key for the ONCR and the industry moving forward seems to be about how to make SDNs programmable since they already exist. Sequeira says this requires OpenFlow.

“We had a complete SDN stack with no OpenFlow and it was good enough for almost all the things that customers wanted to do,” Sequeira said. “There is the virtualization of the switches and firewalls and none of that requires OpenFlow. However, to program it requires OpenFlow even though even a little of that can be done without it.”

And while Sequeira recognizes the importance of OpenFlow, he doesn’t see some wholesale migration to OpenFlow-only networks. Current networking software and gear will work with OpenFlow but will not solely use the protocol. Which, given the statements by Urs Hölzle, SVP of technical infrastructure at Google, that there is no easy way for OpenFlow to communicate with other network protocols, have me thinking that we’re going to need more efficient ways to communicate from one network protocol to OpenFlow.

So the biggest battle in SDNs looks like it will be for the controller, which companies such as IBM, Nicira and Big Switch have developed. The question is: will OpenFlow be the lingua franca between rival controllers or will each strive to create it’s own proprietary network — programmable, running on commodity hardware, but still a fundamentally locked ecosystem?

Feature photo courtesy of Flickr user bjorn.watland

  1. Isn’t this feature also available in Windows Server already?

  2. This a great article! Thanks for sharing the information, Stacey. It looks like VMware is really stepping up its game when it comes to maintaining their status as an industry leader in the field of virtualization. It will be interesting to see what the outcomes of this industry consortium will be considering all of the popular players involved.

    Alyssa
    Mosaic Technology

  3. Keith Townsend Wednesday, April 11, 2012

    I haven’t gotten excited about anything network related in a long time. Most of the changes in the last few years have been evolutionary. The idea of a programmable network is revolutionary. I think Cisco and Juniper have protection for market share on the high end but I see this as getting “good enough” sooner than latter and challenging the big guys on the low end.
    I’m more excited about this from a cloud provider’s prospective. This will give providers the ability to create the same multitenant administration constructs for customer networks on commodity hardware similar to server virtualization.

    1. VMWARE already spread in virtualization world, In the past few months, VMware Inc.’s two biggest storage partners — EMC and NetApp — have been making waves as they develop competing pre-integrated infrastructure called FLEXPOD and VBlock

  4. Keith Townsend Wednesday, April 11, 2012

    Reblogged this on Virtualized Geek Blog.

  5. Protocols’ talking to each other is not needed. What is needed is a arbitrator between openflow and traditional and emerging networking protocols. Quagga – under opensourcerouting.org will do just that. Enable all the OF controllers get the same calculated network routes.

    1. hey Bill, we should totally do an update on the ORC.

  6. The same mechanism we use @ ThreatSTOP to use DNS to distribute blocklists can be used to distribute flow identifiers and routing information. We don’t need another protocol, and full set of libraries. The idea of having the control plane and forwarding plane separated is not new. We’ve been using Route Controllers for BGP for years.
    I like the idea of SDNs and routing controllers. Let’s just use what we already have, that is ubiquitous in support: DNS.

  7. anmolmehtaaa Thursday, May 3, 2012

    hi thanks for sharing this news and information but i wanted to also know about Thin Clients if you got the information about it please tell thank you ..

Comments have been disabled for this post