SHARE



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



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!

March 8, 2017

Enterprise IT's ability to innovate is critical to the success of the business -- 80% of CIOs agree. But the CIO role has never been more challenging than it is today, with rising operational respo

February 22, 2017

Sick of video call technology that make participants look like they're in the witness protection program? Turns out youre not alone. Poor-quality video solutions can give users an unprofessional ap

February 7, 2017

Securing voice communications used to be very simple since it was generally a closed system. However, with unified communications (UC) you no longer have the walled protection offered by a dedicate

February 24, 2017
UC analyst Blair Pleasant sorts through the myriad cloud architectural models underlying UCaaS and CCaaS offerings, and explains why knowing the differences matter.
February 17, 2017
From the most basics of basics to the hidden gotchas, UC consultant Melissa Swartz helps demystify the complex world of SIP trunking.
February 7, 2017
UC&C consultant Kevin Kieller, a partner at enableUC, shares pointers for making the right architectural choices for your Skype for Business deployment.
February 1, 2017
Elka Popova, a Frost & Sullivan program director, shares a status report on the UCaaS market today and offers her perspective on what large enterprises need before committing to UC in the cloud.
January 26, 2017
Andrew Davis, co-founder of Wainhouse Research and chair of the Video track at Enterprise Connect 2017, sorts through the myriad cloud video service options and shares how to tell if your choice is en....
January 23, 2017
Sheila McGee-Smith, Contact Center/Customer Experience track chair for Enterprise Connect 2017, tells us what we need to know about the role cloud software is playing in contact centers today.