Router virtualisation explained

It's clear that we're in the "Virtualisation Age" in the technology markets, and while there is certainly no shortage of hype in the space, there is significant value in virtualisation.

Networks are involved in most of the efforts so far -- from server virtualisation to cloud computing. But assigning a supporting role to the network can disguise the value of virtualisation as applied in the network itself.

All forms of virtualisation are based on the assumption that hardware and operations costs are incurred per device, but devices often have the internal resources to support multiple independent missions. If virtualisation capabilities are exercised, some operations and hardware costs can be saved. All router virtualisation strategies create multiple virtual or logical routers from a single physical device. These virtual router instances are linked in their own networks, creating multiple virtual networks so traffic in one is a "ship in the night" with respect to traffic in others -- at least in theory. Clearly as router virtualisation expands, it increasingly becomes network virtualisation.

Virtual device management issues

From the beginning, most routers have supported a primitive form of virtualisation in the ability to partition their routing tables. Virtual Routing and Forwarding (VRF) supports multiple instances of routing tables and so effectively creates virtual routers. Another form of router virtualisation can be created using MPLS label-switched paths and independent edge routers or "Label Edge Routers" (LERs), which are at the edge of an MPLS network and whose nodes are Label Switch Routers (LSRs). This effectively create a set of independent router networks that share core network resources. Both of these capabilities are in use today, but they have some common limitations.

One limitation of "first-generation" router virtualisation is that there is no hard partitioning of resources between the virtual instances. Control plane processing requirements are normally increased in proportion to the number of virtual router instances in VRF, and all such processes compete for the processor/memory resources of the same router control plane blade. There may be other interdependencies in handling parallel virtual router instances, depending on the implementation. With segmented-core virtualisation using MPLS, you must either deploy independent LERs for each virtual network or design the LER routing tables carefully to prevent cross-routing traffic. These systems may also share trunk facilities among virtual router instances, creating further interdependence of traffic and performance.

Resource interdependency also tends to set an upper limit on the number of virtual router instances and virtual networks that can be deployed. Again, this limit is vendor-specific, but it relates to the fact that virtual router control plane handling requires one type of router blade, and data port/trunk connection requires another. Since there is a fixed amount of space in any rack, the need for more control blades means less space for data blades.

A final issue is the management of virtual devices versus real devices. Operations costs of network equipment are actually 55% of total cost of ownership (TCO), and capital cost is only 45%. If virtual router instances "appear" as real routers in an operations sense (meaning that they require the same operations processes as a real device), then virtualisation will not reduce operations costs. In fact, if managing the virtualisation process is anything beyond trivial (which it normally is), router virtualisation may actually have higher operations costs that would need to be offset by additional hardware savings.

Five design factors to facilitate virtualisation

The new-generation of router virtualisation is characterized by a number of improvements in design that address these issues. In addition, some aspects of router design facilitate virtualisation, so it's important to review all of these factors to optimize router or network virtualisation.

1. Direct support for virtualisation within the router operating system. This will reduce the operations burden associated with managing virtualisation. It may also provide control over whether routing protocols run for each virtual image -- which can increase traffic but provide more responsive adaptive routing -- or whether a "master" protocol is run for all images. Virtualisation support within the router's operating system is also likely to determine whether the router can be managed as a single device, no matter how many virtual images it hosts, reducing overall operations costs.

2. Explicit partitioning of control plane and forwarding plane processing for the router. If a router doesn't provide a hard separation between the two, virtualisation processing will probably slow forwarding performance, which is highly undesirable. There is a trend toward supporting hosting router control planes on a separate device to allow for control plane expansion without reducing the number of slots available for port/trunk cards, as well as to centralize the control plane processing of a set of routers for operating efficiency.

3. Explicit assignment of port, trunk and other resources to virtual routers/networks. To create a firm border between virtual networks in a static way, it is essential to separate best-effort services from premium services. It may also be required in some markets for regulatory reasons. For example, application of net neutrality principles might mandate that premium IPTV or enterprise VPN services be separated from Internet traffic to avoid violating equal-handling-for-all-traffic mandates.

4. Expansion of virtualisation to non-router devices. Many networks use Ethernet/IP hybrids for access and core networking. Virtualisation strategies should cross the protocol boundary seamlessly and without additional management burdens. If a single topology protocol (such as OSPF) is used to manage topology for multiple virtual instances, it is also helpful if that same protocol can populate GMPLS tables for control over the optical layer and support management of MPLS-TP and other fixed paths as well.

5. Version control in router software. If multiple virtual routers have different software requirements, they may compete or collide if they're installed on the same device, or there may not be a stable software version that supports the total set of features used. Users debate how important single-code-version support is for normal networks, but virtualisation will surely make it more important.

Finding the virtualisation balance

Virtualisation strategies for all types of resources are a compromise of the cost (software and operations) of virtual deployment and the savings (in capital and operations costs) versus maintaining independent parallel networks. Newer virtualisation strategies are making it easier to find a favorable balance in these trade-offs, and most network operators will find virtualisation to be a benefit to their service plans.