25 Dec 2015

Virtualizing the network forwarding plane

http://dl.acm.org/citation.cfm?id=1921162
http://yuba.stanford.edu/~casado/virt-presto.pdf

ref [9] distributed firewall
ref [16] virtual routers on the move VROOM

network services (e.g., policy routes, ACLs, QoS, isolation domain) relies on topology-dependent configuration state [4,9,16] … manual reconfiguration

virtualization not foreign to networks, … component failover (e.g., VRRP). However, these primitives have not significantly changed the operational model of networking, and operates continue to screen scrape CLIs with scripts in order to achieve a limited degree of automation

roughly, the idea is to introduce a new network-wide software layer that exposes one or more logical forwarding elements (similar to [10])

the control software reads and writes to these logical forwarding elements… allows network state (forwarding and configuration) to be largely decoupled from the underlying hardware

the compelling use cases demand a many-to-many mappnig between the logical and physical forwarding elements …

2 virtualization revisited

not provide an adequate abstraction upon which to build topology-independent control software

resource pool of forwarding capacity, and hardware changes do not disrupt the logical view of the system

in order to provide application-independent virtualization, we chose to virtualize the forwarding plane

“network hypervisor” for our proposed software layer to intentionally call to mind the concept of virtualization

network "slicing" are not independent of the underlying physical infrastructure, but instead are a way of multiplexing infrastructure

3 design

3.1 overview

our hypervisor maintains these abstractions, providing the ability to create one or more logical (possibly interconnected) forwarding elements, … these elements also have associated capacities (line speeds, cross-section bandwidth, table sizes) … use this logical abstraction to express the desired network functionality …

a recent line of research (onix, nox, 4D) that provides global network control

our network hypervisor (is thereby given) two network views
(by the control plane) a logical network view of the desired functionality
from below it is given (by a centralized network management system) a view of the physical network topology.
job of the hypervisor
determine how to implement the desired logical functionality through configuration of the physical network

3.3 logical forwarding plane

lookup tables
header overwriting, enqueuing, filtering, multicast groupings … forwarding rules, ACLs, SPAN, and other primitives

3.4 physical forwarding plane

mapping packets to logical contexts
the tag used for identifying logical contexts must not be exposed to systems connecting to the logical switch …
the first physical switch receiving a packet tags it to mark the logical context, and the last switch removes the tag

if a logical forwarding decision is distributed across multiple physical components, the "next hop" will be the next physical component that will continue to execute the logical forwarding component ...

4.2 Network Hypervisor

In our implementation, the network hypervisor is being built as a distributed system that operates as an OpenFlow controller.

5 use cases

distributed virtual switch

End-host virtualization requires switching capability on a host (implemented in the host hypervisor [13]). This is generally realized as an L2 software switch (generally termed vswitch) which connects all co-resident VMs on a physical host.

Even with the ability to control the network at the end-host, the dynamic nature of virtual environments (which may include end-host migration) makes network monitoring and configuration difficult.
Scale-out carrier-grade router
A network hypervisor based solution can replace a single carrier-grade router with a rack of commodity switches. In essence, the commodity switches are used to a form a high capacity switching backplane that the network hypervisor then represents as a single logical switch for a standard (open-source) IGP/BGP routing stack control plane implementation.
Multi-tenant network architecture
In a multi-tenant network environment, the physical network is shared among tenants so isolation between tenant networks is a strict requirement.
The isolation is taken care of by the mappings between physical and logical contexts. In this case, the logical context just happens to correspond to the tenants.
Tenants may be provided with full (self-service) control over their dedicated logical switches, freeing further resources from the physical network management. For example, the tenants can modify per (logical) port ACLs and they can even see (logical) statistics for their traffic.
For IP connectivity, a logical router may represent the IP subnet allocated for the tenant.