What a Virtual Network Looks Like: InfrastructureWhat a Virtual Network Looks Like: Infrastructure

Current-generation virtual networking comes in three flavors, each of which has significant infrastructure implications.

We hear a lot about "virtual networks" these days, despite the fact that virtual private networks (VPNs) and virtual LANs have been with us for decades. Software-defined networking (SDN) and network functions virtualization (NFV) have expanded our notion of what a virtual network is, and can do for us, but the whole virtual network picture is more complicated than just a few new options. That's particularly true at the infrastructure level.

A Generational Thing
In "real" networks (if that's the opposite of "virtual") connectivity is created by a set of cooperating devices dedicated to the network. We built Ethernet networks from Ethernet switches, and IP networks from routers. The first generation of virtual networking simply partitioned these "real" networks so that each partition appeared to be real. In effect, this generation hosted virtual networks on real networks.

The second generation of virtual networks was inaugurated by Nicira, now part of VMware (and then of Dell). In this iteration, Nicira hosted a virtual network on a combination of real connective infrastructure and servers. The approach created a set of tunnels from server to server, over whatever happened to be there in the way of server connectivity. These tunnels created user- or application-level connectivity by combining with simple forwarding rules enforced at each server hop.

The current, or third, generation of virtual networking jumps off from this model, but in three directions. One direction, which we could call software-hosted networking, uses servers to host instances of switch and router software. This creates something very much like our original real network except that it's not based on custom devices. The Vyatta acquisition gave Brocade a leading role in this model of virtual networking.

A second direction in the current virtual network generation is SDN, which uses hosted route control software, combined with "white box" simplified forwarding devices, to create connectivity. The OpenFlow protocol connects the controller and the devices. While route controllers could in theory create any model of connection that was useful, most SDN applications recreate Ethernet and IP services.

The final variant on our third generation of virtual networking is NFV, which decomposes network services into virtual functions (meaning service features) that can be deployed in hosted form and connected using either "real" or other "virtual" network technologies -- SDN being the popular flavor of the moment. If NFV were fully adopted it could eliminate most of the network devices above the optical layer except perhaps those SDN devices that would still be used for forwarding control.

Network Shake-up
The common theme in all this virtualization is a reduction in the number of network devices needed to provide services to consumers and businesses. VPNs replace private networks, and these would otherwise have required their own routers. SDN could replace both switches and routers with low-cost general-purpose forwarding devices, and NFV could chuck the whole thing in favor of hosted software. Virtualization moves away from proprietary implementations of service features in appliances/devices and instead toward software and an open feature model. All of this could change how networks are built.

The venerable OSI model said that the network itself had three layers -- physical, data-link, and network (the other four OSI layers are not in the network but rather are part of the connection-point or user software stack). Operators tell us that most of the capex and opex costs are associated with Levels 2 and 3 (now usually Ethernet and IP), and virtual networking would gradually replace these layers with cheap forwarding elements and server-hosted software components. Thus, instead of a network stack of three layers, we'd have a network of optical devices supporting a bunch of cloud data centers in which service features themselves were hosted.

Manageability -- or Not
SDN and NFV, as industry standards or specifications, have been working out the details of this substitution, but both started at the bottom, defining low-level procedures like forwarding control and hosting. Neither SDN nor NFV has addressed the management questions, and those questions are the dominant issues in virtual network evolution today.

We know how to manage real networks, and even first-generation virtual networks. Beyond that, management strategies have lagged behind, which means we can't be sure how much managing the wonderful future world of cloud-over-optics would cost -- or whether it's manageable at all. How would you correlate faults in virtual components, or know where to send a service tech if something broke? Vendors have answers to these questions, but operators don't have proof of those answers at scale, which is understandably worrying to them.

A further complication in this third phase of virtual networking is the presumption that the cloud layer serves everything, and so uses all services and features to justify an efficient pool of resources. While that pool is developing, resource costs are higher and risks of failure or congestion are likewise. It's easy to see why operators would want to dip their toes into virtual networks, but hard to see how this cautious approach could build the economies of scale needed to justify migrating to virtual networking in the first place.

We now know that managing virtual networks is just as radical a change as building them, and that the two will somehow have to evolve in synchrony if we're to get the most from virtual networks. But management and infrastructure are the responsibility of two totally different organizations within service providers, and in the main two different vendor communities offer the products and solutions. Virtual networking also changes the services networks offer and how users have to plan for and manage their use of network services in the future. We'll consider all these dimensions in the rest of this series.

Follow Tom Nolle on Google+!
Tom Nolle on Google+