ABOUT THE AUTHOR


Tom Nolle
Tom Nolle is the president and founder of CIMI Corporation and the principal consultant/analyst. Tom started his career as a...
Read Full Bio >>
SHARE



Tom Nolle | August 13, 2012 |

 
   

Is Virtual Networking Really New Networking?

Is Virtual Networking Really New Networking? To really revolutionalize networking, virtual networks need to be an underlay or an inlay, not just another type of overlay.

To really revolutionalize networking, virtual networks need to be an underlay or an inlay, not just another type of overlay.

The purchase of Nicira by VMware has led to a lot of predictions that the emergence of virtual networking will cut the heart out of network vendors like Cisco. There's no question that a lot of the speculation is an outgrowth of the desire to be exciting or controversial, but down deep inside this issue is there a speck of reality? Could virtual networking really change things?

Most of the stuff we call virtual networking today is really little more than a retread on some older concepts--tunnels or pseudowires. You can create a virtual path over almost any Level 2 (Ethernet) or Level 3 (IP) protocol, and these virtual paths can "look" to devices or software like physical links. That means that routing or switching logic can use them as trunks and you can create a kind of piggyback network on top of the real one.

That "on top of" point is the critical one here. In order to create a tunnel you need a network to tunnel over, and that means switches or routers. By themselves, overlay networks really just let you tweak connectivity, meaning that you can build "sub-networks" that offer services to a subset of the real network’s connective community. You can't replace those real networks or add QoS or other capabilities to them, because you're just a user, an overlay.

But you don't have to build on top, and that’s the real story of virtual networking. Suppose for a moment that you could create an entirely new OSI layer, that I'll call "Fithernet" for "Fiber/Ethernet", combining Layer 1 and Layer 2. Since we're inventing this layer, we can give it features, right? We'll call the gadgets that create this unified layer "Fitherswitches". OK, we'll say that this new layer offers Fitherpipes that can represent optical paths or electrical subsets of those optical paths--a combination of Layer 2 tunnels and Layer 1 optical wavelengths, for example. Suppose we can manipulate those Fitherswitches easily with software, setting Fitherpipes up, tearing them down, switching in a new one if an old one breaks. A carrier or an enterprise could, in theory, build an entire network core out of Fitherswitches, a core that recovered from failures by switching a Fitherpipe to a new path if the old one failed. And it looks to current networks like the physical layer--in part, because it includes the physical layer.

This new layer could wind up co-opting the current gear or rendering it obsolete. All network resiliency is limited by the redundancy of physical facilities, and if our Fitherpipes exercise facility resiliency fully, then this new Fithernet is as reliable as anything that could be created at the higher layers, right? OK then, that means we don't need recovery at those layers any more. We've just taken a big bite out of the differentiation at the Ethernet and IP level. By collapsing the layers underneath, you reduce operations costs at Level 3; instead, you’re handling failures at Level 2--the new virtual network’s control layer..

OK, now suppose that we have a Fitheredge. This Fitheredge has the ability to take a mesh of Fitherpipes and make them look like a standard Ethernet or IP service. It communicates with other Fitheredges to tell them what IP subnets or Ethernet addresses are attached to it, but through a central software process, a kind of service registry. To the users attached to our Fitheredge, their services look the same as always, or maybe better. Why? Because we could use our Fitheredge and application awareness to shunt critical applications onto faster, better, Fitherpipes than the routine traffic. In fact, if we made Fitheredges application- and user-aware, we could create any number of parallel networks with different capabilities, and they'd be completely independent except at the Fitheredges where they touched their real users.

What happened to bridging protocols, to IP discovery, to IP traffic engineering, in our Fithernet? In this example--which I admit is extreme--these things all go away. So while virtual networks as overlays don't pose any threat to the network vendors, virtual networking applied low on the OSI stack could completely transform networking.

And of course we can assume that if we could make our Fithernet elements aware of current protocols, and if we could make our current network devices aware of Fithernet features and able to use that central software process that mediates connectivity in Fithernet, we could create hybrid services that would be richer than our current ones but more compatible with our current equipment investments.

This is the hidden truth of network virtualization. Overlay virtual networks mean nothing absent some means of pushing the capabilities of virtualization downward to create a virtual underlay or inlay rather than an overlay. If network virtualization creates those "central software processes" that can mediate connectivity without discovery and that can stitch new routes when old ones fail, then the virtualization is a step to change. Otherwise it's a tunnel retread, a new label on an old concept.

For vendors it’s the option of creating a "Fithernet-friendly" evolution of equipment that creates the opportunity and the risk. Yes, Fithernet will change things and will threaten the current order in networking. But you can't push a gusher back into the ground. The OpenFlow protocol disconnects forwarding from current protocols, and that means it can connect anything to Fithernet. Any current optical device can be a Fitherswitch, any current IP or Ethernet edge device can be a Fitheredge, and any overlay network virtualization player can provide that central software. So someone will, it's only a question of when...and who.



COMMENTS



September 24, 2014
Distributed enterprises face a long list of challenges when deploying UC services to remote offices, including survivability, security and performance. IT managers need flexible and reliable solutions...
September 10, 2014
Cloud solutions offer companies the unprecedented ability to forego the costly and painful process of updating their contact centers every few years in order to maintain some semblance of modernity, i...
August 27, 2014
Whether your organization has decided to move to the cloud, or you are considering the possibility, this webinar will help you cut through the all the "checklists" and give you four must-hav...