This section provides an overview of OpenVirteX’s definition of network virtualization, starting with a high-level view of an OVX-virtualized network.
1.1 Network Virtualization
1.2 OpenVirtex: A High-level View
1.1 Network Virtualization
Network virtualization allows multiple tenants to occupy the same network infrastructure, where each has an illusion that they have a full network to their own disposal. OVX achieves this by giving each tenant access to a virtualized network topology and a full network header space. The former allows tenants to ask for customized topologies, and the latter guarantees functionality and traffic isolation even if different tenants choose overlapping addressing schemes.
While similar in the ability to allow multiple tenants to coexist, this differs from network slicing, which splits up portions of a single header space amongst all of the tenants. For example, two tenants in their own virtual networks can use the same IP subnets and TCP/UDP ports, while in two slices, this will cause traffic to leak between the slices. Another difference is in possible topologies – virtual networks need not correspond to the topology of the underlying network, while a slice is restricted to an isomorphic subgraph.
OVX implements network virtualization as a proxy that sits between the network and the tenants’ network OSes. For each tenant, OVX rewrites OpenFlow messages to translate between what a tenant’s NOS sends and recieves from its virtual network, and what the infrastructure should receive in order to produce the behavior consistent with the network seen by the tenant. This approach has two consequences:
- it allows OVX to present programmable virtual networks that support OpenFlow, so a tenant can control the virtual network with its own NOS, and
- it makes OVX transparent – from the network, it appears to be a controller, and from the tenants, as a collection of OpenFlow-capable switches in their network
As part of this function, OVX acts as a (de)multiplexer for OpenFlow messages that flow between the tenant control planes and the infrastructure. Notably, this process relies on the assumption that each network host belongs to just one virtual network. Host hardware addresses play a key role in associating tenants with their network traffic.
Fig.1.1 shows a network virtualized by OVX to support three tenants.
Fig 1.1: Network virtualization with OVX. Each tenant can supply they own control plane to manage the virtual networks presented to them by OVX.
Lastly, the way in which OVX rewrites OpenFlow messages (i.e. virtualizes the network) before it reaches a tenant’s NOS makes it a network underlay. This is in contrast to a network overlay in which a NOS provides the virtualization to its applications.
1.2 OpenVirteX: A High-level View
OVX maintains logical representations for each tenant’s virtual network, and for the infrastructure (physical network). OVX builds its view of the infrastructure in its physical network representation through topology discovery (Section 3.4), and builds the representations of virtual networks with the aid of configuration information provided through its API (Section 3.9).
As shown in Fig.1.2, OVX limits the coupling of the physical and virtual represeantations to 1) a few shared global structures that store the mappings between the elements in the physical network and the virtual networks, and 2) the virtualize/devirtualize routines in the message event loop that rewrite and (de)multiplex messages in the control channel. The result is a control channel divided into two:
- a virtual half between tenant controllers and the north-facing half of OVX (shown in blue), and
- a physical half between the network and the south-facing half of OVX (shown in orange)
The coupling points are used to translate between the physical and virtual contexts across the two halves of control channel. Since the two halves are logically decoupled, OVX itself is capable of establishing/maintaining connections with datapaths even without the presence of virtual networks and connected tenant controllers.
Fig 1.2: Left) Within OVX, the representation of the physical network (yellow) and the tenant networks (blue) are logically separate. Tenants 1 and 2 can only ‘see’ the virtualized topology presented to them by OVX, labeled vnet 1 and vnet 2, respectively. The topologies of vnet 1 and 2, and the mapping between them and the physical network, are configured via API calls and stored in a global map (green). The contents of the map can be accessed from both physical and virtual networks (orange and blue lines). Right) The physical-virtual split is crossed by the OpenFlow message virtualization/de-virtualization process, which references the global map.
Section 3.5 provides a detailed discussion of how OVX implements this split channel.
We now move onto Section II to take a look at the components and structures used within OVX to represent physical and virtual networks and to map and translate between them.
[ Documentation Home | Next Section ]
Please send feedback and questions to ovx-discuss – at – googlegroups.com