Network virtualization is unique in our virtualizing world in that it’s both a goal and a facilitator. We want to use network virtualization to change both the services networks can offer and the way that familiar services are created, and at the same time we expect virtualization to answer new questions on resource connection and reconnection, emerging in cloud computing and NFV. Consistent with our industry’s regrettable tendency to look at everything from the bottom up, network virtualization seems almost disconnected from both missions by sensationalistic positioning—white-box takeovers that drive Cisco into the grave. Chambers was right to dismiss that threat, but it was never what he needed to be worrying about in the first place.
The basic principle of networking today is that of the connection network. Things that want to communicate have an “address” that’s part of a structured address space. The network, by some means or another, learns the way that these network users are connected, meaning where the users are in a topological sense. The network then figures out routes for traffic delivery. All this discovery is today based on adaptive exchanges of route/reachability/connectivity information. SDN proposes to change that to exercise central control of connection points and routing policy.
Network virtualization, whether you think of it in SDN terms or as an evolution to legacy devices and protocols, is all about changing the connection network model. Rather than starting with the “how” and talking the same bottom-up approach I’ve criticized others for taking, let me start by dealing with the “why?”
Yes, it’s true that you could use SDN to displace existing switching/routing, and it’s also true that this displacement could create a new model where traffic engineering and SLAs were created more at the “virtual wire” level than at L2/L3. That would facilitate building networks with virtual switch/router instances and thus really threaten Cisco. The problem is that this is a complex evolution that, like most paths toward NFV, presents limited benefits until you’ve committed thoroughly to the transition. No operator likes that kind of bet. What would be helpful is a means of justifying SDN deployment without massive churning of infrastructure, which means addressing SDN as a facilitator. Of what? The cloud, and NFV.
In a world of cloud computing and virtual functions, there’s an obvious problem with the simple notion of a static address space. When a cloud component or VNF is deployed, it has to be given an address through which it can be reached, which is a requirement for “normal” deployments as well. The problem that cloud or cloud-like approaches (including server virtualization) introduce is dynamism with respect to network location. It was here a minute ago, and now it’s somewhere else. Or maybe it’s several places.
When these changes in the mapping of an addressed component with a network access point occur, they have to be reflected somehow. If I change location of the NSAP without changing the address itself, then packets to that address have to be routed differently, which means routing tables have to change. If I decide to change the address, then everyone who knew the function by its “old” location has to be given the new one, and I still have to build routability to that new location.
A second problem introduced by both the cloud and NFV is that of public versus private addresses. Any time I build up applications or services from assembled components, the assembly process creates routes for traffic among the pieces. If those routes (based on addresses of ports exposed by the components) are “public” meaning that they’re visible in the same address space as the users would be, then it’s possible to attack or hack them. But some of the component addresses actually represent connections to the outside world, connections that have to be visible. Where assembly of components is more dynamic, it’s possible that what’s seen from the outside would depend on exactly how the interior components were assembled.
We’re not done yet; there’s a third problem. The most popular application of NFV at this moment is virtual CPE (vCPE), which uses something called “service chaining”. In service chaining, traffic is stitched between selected functions in the same way that function-based appliances might be cabled together. A firewall device, for example, might be connected to a WAN port, and then a VPN appliance, and so forth. What makes this difficult is that there is no “natural order” of appearance along the traffic path; you have to specify.
These challenges have to be addressed in a framework that balances the need to solve the problem and the need to retain compatibility with current software practices. We have some notions of what the results might look like in Amazon’s elastic IP and Google’s Andromeda.
A starting point to a virtual networking strategy to address these problems is support for multiple addresses for network elements. Google Andromeda shows this by depicting a network service point as a vertical silo with an appearance in several different virtual networks. Each of the virtual networks would have an address space that’s a subset of a larger space so that the address of a packet would implicitly identify the virtual network. Within a collection of components, open addressing on one virtual network could occur based on a routing scheme linked to cloud topology, and public access could be provided on another.
Amazon’s mechanism of elastic IP makes the process clearer, though it seems less general. All cloud-hosted components are assigned an IP address from the RFC1918 space but related to the location of the component in the Amazon cloud. These can be mapped selectively to public IP addresses. The mapping can be changed to reflect movement of an element.
Neither of these strategies address the issue of explicit function chains, the third problem noted above. Explicit routes are supported in various IP standards through a routing stack or “source routing”, but in service chaining there is no assurance that that we’d know the first component along the path or whether that component would know to originate the stack, and if so with whom.
SDN would allow the creation of an explicit service chain because the central network control element would (or could) know of the notion of a “chain” element set which would be an ordered list of ingress-egress ports. As various sources have pointed out before, the only issue might be efficiency in interconnecting vSwitch and “real” switch elements to avoid hairpinning traffic.
It appears that it would be possible to define a virtual networking approach to address all of the issues noted above and retain compatibility with current software. Interestingly, this could involve using a new SDN connection model to augment the familiar LINE, LAN, and TREE—the CHAIN model just noted. If so, virtual networking might represent the first specific enhancement to the connection model we’ve managed to propose, despite the fact that in theory SDN could support an arbitrary set of such new models.
Another interesting question is whether SDN could be augmented to control the address management part of virtualization. Certainly it would be possible to build forwarding rules to support traffic division by address, but public/private mapping could require the use of SET and STRIP features of OpenFlow that are not mandatory.
Network virtualization opens some interesting topics in intent modeling of services too. Obviously the CHAIN example I just cited is one, but also consider the question of simply adding an instance to some component or VNF. You have to deploy that instance and connect it, and the latter mission will involve both the simple point of running a pipe or joining a subnet and the potentially more complicated task of adding load balancing and changing DNS. Might an intent model for a service then include functions like “scale-out-component” or “redeploy?” If we add those things in, we significantly facilitate open implementation because any solution that functionally meets requirements could be adopted with confidence that the implementation of the model itself would do all that’s required.
I think that virtual networking could be the strongest argument for SDN/OpenFlow adoption, but I also think that the state of the industry lags the potential virtual networking represents. There are some indications (such as the recent meeting of ISG parties at CableLabs to talk about SDN integration) that thinking will advance to include these topics, but it’s also very possible that other industry groups with collateral interest (like the IETF) will take this up before the ISG gets to it. Whoever manages to come up with something clear and useful here will do the industry and themselves a major service.