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


Who's Who at Enterprise Connect

NEC

Featured This Week:
Sponsored By


April 24, 2014
Small centers are both excited and nervous about the new wave of innovation converging on them as major disruptive forces - cloud, mobile, big data and social - rock the contact center world. They rea...
April 9, 2014
Recent advances in cloud technology have given rise to wide variety of new tools designed to support contact center performance, staffing and reporting. Join us for a live webinar focused on helping c...
March 26, 2014
As more organizations are focused on maximizing customer experience as a key differentiator to stay ahead of the competition and customer expectations, the focus needs to be on interactions across mul...

Sign up to the No Jitter email newsletters

  • Catch up with the blogs, features and columns from No Jitter, the online community for the IP communications industry. Each Thursday, we'll send you a synopsis of the high-impact articles, podcasts and other material posted to No Jitter that week, with links for quick access.

  • A quick hit of original analysis by the experts who bring you Enterprise Connect, the leading event in Enterprise Communications & Collaboration. Each Wednesday, this enewsletter delivers to your email box a thought-provoking, objective take on the latest news and trends in the industry.

Your email address is required for membership. For details about the user information, please read the UBM Privacy Statement

As an added benefit, would you like to receive relevant 3rd party offers about new products/services and discounted offers via email? Yes

* = Required Field

No longer instrested? Unsubscribe here.