I’ve blogged now about “edge-based” and “interior” NFV service opportunities, and in the latter I noted that I was going to treat the case of “interior nodes” separately. Many of you will probably understand why that is the case, but I hope to show everyone why nodal services are different, and perhaps generate some discussion even among those who’ve known that all along.
A network is a structure designed to generate connectivity through a combination of trunks and nodes. Nodes provide data passage among trunks, what in the general sense is called “forwarding” based on addresses. Trunks connect the nodes. In the old days before virtualization, it was pretty obvious what each of these two things was and most important where they were.
The thing we call “virtualization” (again in its most general sense) has changed networking gradually by allowing for “virtual trunks” that were really paths composited from segments of media. The segments could be parallel, like lambdas, or sequential as in strung along in a line. In the OSI model, a given layer offers abstract services to the higher layer and creates them within its own domain as needed, so “virtual circuits” and paths or tunnels are equivalent to physical layer if that’s how the services are pictured. We’ve had networks based on that for ages.
We’ve also had virtual nodes, in a sense, through VLAN and VPN services. These services look to the user like a kind of device and replace the classic node-and-trunk per-user structures. SDN can augment these virtual-node services because it can provide customized forwarding control that could either structure traditional services in a different way or build new ones with new forwarding rules. You can also simply host a bridge or router instance in a server or VM and create a software node.
The thing that’s common to both legacy and virtual-node models today is that the topology of the network, including the placement of nodes, is fairly static. You may have a real router or an SDN white box or a software router, and you may let it work adaptively or control forwarding explicitly, but it kind of is where it is. In theory, NFV could change that and the question is under what circumstances a change would be useful.
There are a lot of reasons why a network topology could change, the most obvious of which is that the optimum location for nodes was impacted either by changes in traffic flows or by changes in the underlying transport properties on which the trunks were based. The former is obviously the most “dynamic” but you can see the problem immediately; “traffic flows” in aggregate may not be that dynamic. On the other hand, suppose we returned to the notion of networks of old, trunks and nodes, and simply substituted “virtual” into each term? On a per-user basis, topology optimization would be a lot more useful.
If we view VPNs and VLANs as being created by special features at Level 3 and 2 (respectively) by routers and switches then we lose dynamism value by aggregating stuff. If we build private networks, which is what VPNs and VLANs build, in the “old” way with virtual switches and routers then we personalize topology to the service and users.
Virtual trunks of any sort could be married to NFV-deployed virtual routers/switches to create an instant and different model of a virtual private network. Not only that, the nodes could be moved around, replicated for performance, etc. providing that you could tolerate the disruption in the packet flow. Obviously a performance problem or a device failure would create a disruption anyway, so it’s a matter of degree.
This model of a virtual private network/LAN could be connected to user sites through a virtual pipe, which would mean their on-ramp router was in the cloud, or through a virtual trunk from a (likely virtual) router hosted on premises. That could be customer- or carrier-owned. Since the interior router on-ramp would exist in either case, this looks like what I’ve called the “agent model” of service access; a cloud agent represents each network site and you connect with your agent to get the service.
One of the interesting consequences of this model is that connection services live totally in NFV data centers; you can only host virtual routers where you have hosting resources available. That facilitates the introduction of other NFV services since you have direct access to user traffic flows from the places where new service features could be placed. You’d never have to “hairpin” traffic to get to a service chain, for example.
If the model is carried to its logical conclusion and all business virtual network services are hosted this way, you also have a natural way of connecting to applications the operator hosts in their own cloud computing service. The carrier would have a competitive advantage because they’d have direct connection with customer flows; no additional delay or risk of failure would be introduced if cloud applications were co-located with virtual routers carrying the private network traffic.
There are also, obviously, operational questions that would have to be answered. One big one is whether multiplying the router instances needed to build private networks (versus providing for them out of shared devices) generates a risk of greater opex. I think that if we assumed that our trunk underlayment was engineered for reliability and also had path recovery capabilities, you might actually end up with lower operations costs. You’d also eliminate some security issues by partitioning traffic by customer/service below the router layer. But we need work on this point.
We also need work on understanding how the model would apply to multi-user service subnets. If a service is supported on its own subnet like an application, and if users are gated onto that subnet as needed, how would the fact that the users weren’t of the same company impact the topology and costs? That would also help answer the question of how mobile users would impact the VPN/VLAN picture. Does the operator provide a mobile virtual on-ramp in multiple metro areas, and if so how would that be priced and how would it impact traffic and operations?
I believe that virtual routers and switches could have a profound impact on network services, starting with VPNs and VLANs, but I also believe that both operators and vendors have tended to think in too linear a way regarding how they could help. You can never take full advantage of virtualization if you create virtual things that exactly mirror the capabilities of physical devices already in use, then place the virtual things in the same place you put the physical devices.
In some ways, virtual switching and routing deployed by NFV and organized and accessed via SDN could be a killer app for both SDN and NFV. That would be particularly true where an operator had a lot of new customers or moves, adds, and changes and so would be refreshing infrastructure more regularly. Of all the NFV opportunities, deployment of virtual nodes has received the least attention. I think that should change.