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 >>

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.


Enterprise Connect Orlando 2017
March 27-30 | Orlando, FL
Connect with the Entire Enterprise Communications & Collaboration Ecosystem

Stay Up-to-Date: Hear industry visionaries in Keynotes and General Sessions delivering the latest insight on UC, mobility, collaboration and cloud

Grow Your Network: Connect with the largest gathering of enterprise IT and business leaders and influencers

Learn From Industry Leaders: Attend a full range of Conference Sessions, Free Programs and Special Events

Evaluate All Your Options: Engage with 190+ of the leading equipment, software and service providers

Have Fun! Mingle with sponsors, exhibitors, attendees, guest speakers and industry players during evening receptions

Special Offer - Save $200 Off Advance Rates

Register now with code NOJITTEREB to save $200 Off Advance Rates or get a FREE Expo Pass!

January 11, 2017
As cloud communications continues to grow and mature, many enterprises are looking to build a hybrid CPE-cloud strategy. Looking out over the next three years, how should enterprises expect the cloud
December 14, 2016
Cloud UC is being rapidly adopted in the enterprise, but recent research has shown many organizations continue to be challenged with how to effectively integrate cloud in their existing UC ecosystem.
November 30, 2016
With cloud communications platforms and SIP/SIP trunking APIs, enterprises have the opportunity to embed real-time voice and video calling within business applications and processes while leveraging e
January 23, 2017
January 23, 2017
January 23, 2017
January 22, 2017
January 23, 2017