Network Virtualization – A SurveyAris Cahyadi Risdianto#1

#School of Electrical Engineering and Informatics, Institute of Technology BandungGanesa 10th, Bandung, Indonesia1aris.risdianto@gmail.com

Abstract— Current service platforms or frameworks, e.g., Cloud solutions, do not take sufficiently into consideration the infrastructure, which is necessary for the execution of the service,. They take resources e.g. network connectivity for granted and do not provide an integrated networking approach considering Quality of Service (QoS) or other real-time aspects of the message exchange between possibly thousands of components. There is a requirement to have a fully managed network virtualization framework for providing the required connectivity between components within a virtualized service platform respecting all service requirements, e.g. as expressed by interactive real-time services, on transport layer [1]. Network infrastructures, especially optical network should support the extensibility that enables rapid provisions of diversified service networks, and also network virtualization is one key technology for this purpose. Here, network virtualization is a mechanism for running multiple networks, which are customized to a specific purpose, over the shared infrastructure, which may deteriorate network performance and stability due to interference by other service networks [3].

Network virtualization has become a common research topic that many researchers consider a basis for defining a new generation network architectures [2]. Despite of any challenges on optimal resources allocation in the physical infrastructure, network virtualization presents a promising approach to overcome ossification and facilitate service deployment for a future Internet [4]. This paper summarizes the concept and decent development of network virtualization including backgrounds, benefits, architecture and management, and also some implementation examples, etc.

Keywords— Cloud solutions, new generation network architectures, ossification, QoS, virtualization.

I. INTRODUCTION

Α. Background

Some facts that drive network virtualization are outlined as follow. First, Infrastructure Usage Utilisation is not cost effective, usage of one physical infrastructure for one specific network or specific services is not cost effective, because it will increase cost investment (CapEx) for the network or service provider. On the contrary, a usage of shared physical infrastructure will increase the efficiency of the usage without sacrifice quality of services or performance caused by interference between services. Second, Cloud Solutions (Cloud Computing, etc) do not concern on the infrastructure, service or application developers always assume that network

resources always available for their application and services, and do not consider any QoS approach from the services for transmitting through the network [1]. And third, Requirement of connection respect all service requirements, connectivity between components within virtualized service platform must be respecting all service requirements, e.g. as expressed by interactive real-time services, on transport layer [1].

Β. Definition

There are some definitions for network virtualization and most of them have the same approach. Oberle and his team [1] define it as ”A promising approach to cover individual and dynamic resource provision while keeping strong individual QoS requirements and optimising the overall resource usage”. Nakao and his team [2] regards network virtualization as "A technique for isolating computational and network resources through virtualization to allocate them to a logical (virtual) network for accommodating multiple independent and programmable virtual networks". Lastly, Miyamura and his team [3] delineate it as "A mechanism for running multiple networks, which are customised to a specific purpose, over the shared infrastructure".

Moreover, there are several differences when comparing traditional concept of legacy VPNs and network virtualization. While VPNs only offer apparent and dedicated connectivity in the current network architecture, network virtualization aims to achieve the additional features: (1)programmability: a virtual network may be equipped with programmable control plane, (2) topology awareness: a virtual network may be topology aware rather than offering only connectivity, (3) quick reconfigurability: a virtual network may be quickly provisioned and reconfigured, (4) resource isolation: a virtualnetwork may be allocated a set of computational and network resources, and (5) network abstraction: a virtual network may accommodate a new architecture different from the current Internet architecture [2].

C. Key Features

According to the definition of network virtualization, there are two benefit based on the purposes by implementing multiple network architectures and services in isolated logical networks on top of a single shared physical infrastructure. First, in the long run, we can define a meta-architecture to accommodate multiple architectures concurrently. Secondly,

in the short term, we can construct testbeds to experiment with multiple disruptive network architectures and services concurrently without interference among those experiments [2].

From another point of view, there are several important features in the respect to network virtualization which are segmentation, isolation, and encapsulation. Segmentation allows several different services to share a physical link with given specific QoS properties. Encapsulation enables services developers to design service specific on the overlay networks at a high level of abstraction, and then disburden them from dealing with highly complex physical network infrastructures. Finally, means for isolation are imperatively needed to suppress any unwanted crosstalk between the services which run on shared physical links [1].

II. CONCEPT OF NETWORK VIRTUALIZATION

A. Architecture

SERVICE ORIENTED INFRASTRUCTURE

Virtualization paradigm has gone through its first critical transition from Service Oriented Architecture (SOA) into the Service Oriented Infrastructure (SOI) paradigm. SOIs build based on previous advancements in Distributed Systems, Grid Computing, Cloud Computing, Virtualization, SOA and related technologies. Typical current SOI realisations, e.g., Grid or Cloud solutions, do not take the network infrastructure into consideration. The concept of a network virtualization framework bridging these gaps by dynamic on demand provisioning of network resources based on individual highly abstracted service requests [1].

The basic purpose of an Intelligent Service Oriented Network Infrastructure (ISONI) reduce the complexities for service providers or developers to roll out new network based on services requirements as it takes care of the automatic deployment of the services on best fitting resources distributed in a network. A major task of the ISONI is to completely separate the management of all kind of hardware resources distributed in a network from deployed services and their associated service components. With this task, the actual status and distribution of resources are hidden from the service developer’s view.

Figure 1 illustrates the principal service deployment performed by the ISONI. The upper part of the figure shows the highly abstract view of two example services in form of “Virtual Service Networks” (VSNs) as provided by the servicedeveloper (the examples are distinguished in the figure by dashed lines for the second VSN). Each VSN is composed of multiple components, called Service Components (Scs) which interconnected by specific virtual links and identified by a

virtual link description. The lower part of Figure 1 shows the mapping of the highly abstracted resource requests (two VSNs) onto the network of real resources, execution environment (Virtual Machine Units) and real links through the network(s) between those VMUs.

Figure. 1 Services Deployment in ISONI [2]

VNET ARCHITECTURE

VNET architecture is network virtualization architecture which have a goal to see which players are necessary to offer virtual network based services to everyone. By identifying these players, we can on the one hand identify different business opportunities and on the other hand disentangle the technical issues from the business decisions. Considering the kind of network virtualization, leads to the re-definition of existing, and addition of new, business roles:

• Physical Infrastructure Provider (PIP), which owns and manages the physical infrastructure (substrate), and provides wholesale of raw bit and processing services (i.e., slices) which support network virtualization.

• Virtual Network Provider (VNP), which is responsible for assembling virtual resources from one or multiple PIPs into a virtual topology.

• Virtual Network Operator (VNO), which is responsible for the installation and operation of a VNet over the virtual topology provided by the VNP according to the needs of the SP, and thus realizes a tailored connectivity service.

• Service Provider (SP), which uses the virtual network to offer his service. This can be a value-added service and then the SP acts as a application service provider or a transport service with the SP acting as a network service provider.

These various business roles lead to the architectural entities and organisation depicted in Figure 2. In principle, a single company can fill multiple roles at the same time. For example

it can be PIP and VNP, or VNP and VNO, or even PIP, VNP, and VNO. However, we decided to separate the roles as it requires different groups within the company. For example running an infrastructure is fundamentally different from negotiating contracts with PIPs about substrate slices [5].

Figure. 2 Interfaces between players in the VNET architecture [5]

CABO INFRASTRUCTURE

Cabo separates the notion of conventional ISPs into two distinct entities: infrastructure providers and service providers. An infrastructure provider owns and maintains the network equipment (e.g., routers and links) that forms an infrastructure network. A service provider establishes agreements with one or more infrastructure providers for access to a share of these router and link resources. Cabo facilitates sharing of physical resources by subdividing a physical node (i.e., router) or link into many virtual nodes and virtual links. A virtual node controls a subset of the underlying node resources, with guarantees of isolation from other virtual nodes running on the same machine. Similarly, a virtual link is formed from a path through the infrastructure network and includes a portion of the resources along the path. Cabo can guarantee bandwidth or delay properties on these links using schedulers that arbitrate access to shared resources, such as CPU, memory, and bandwidth.

Figure. 3 CABO Architectures [6]

A virtual network consists of virtual nodes and links that belong to the same service provider. For example, in Figure 3, service provider 1 has a virtual network using physical

resources belonging to infrastructure providers 1 and 3 to provide end-to-end services between end hosts A and B; the end hosts may run virtual machines that connect to different virtual networks, possibly run by different service providers. A virtual node might even be subdivided into multiple virtual nodes, and a virtual link itself comprise multiple virtual links. Also, an infrastructure provider might offer some services beyond the basic support for virtual components.

B. Addressing

From the technical based architecture (ISONI architecture) [1], for abstracting from the underlying network infrastructure and isolate VSNs against each other, a layered addressing scheme has been developed to provide a flexible connection between the addresses assigned to the ISONI SCs and the actual hardware that is used to run that SC. Virtual Address Layer, the address layer that is used inside the VSN description is treated as a virtual address layer. Addresses at this layer are not required to be globally unique, as they are only considered in the context of the (unique) name space that is assigned to each VSN by the ISONI. The VSN Creator has to specify the virtual addresses that will be used by the ISONI SCs in the VSN description.

Physical Address Layer, the separation of virtual address space and rout able address level (the physical address space of the transport network) allows to migrate running VMUs live within and between ISONI Nodes. The IXB of each ISONI Node is attached to one or multiple transport networks. The network traffic exchanged between ISONI SCs is encapsulated by the IXB depending on the used network path in relation with the used transport networks. This allows the ISONI to deploy SCs on any ISONI Node that is capable to execute this ISONI SC.

C. Network Control Mechanism

1. One-Hop Source Routing [7]

Network virtualization found as the basis for routing overlays. Routing overlays are virtual network structures dedicated to forwarding arbitrary data. Routing overlays can apply their own address and routing scheme and may have arbitrary topology. The actual topology and routing may be defined by available transport resources.

Recently, various architectures of routing overlays have been proposed A highly promising approach is the concept of one-hop source routing. Hereby, the user data is forwarded one-time only to a specific intermediate node which then relays the traffic to its destination using ordinary IP routing. The dedicated forwarding can be easily achieved by

establishing a tunnel to the intermediate node. The advantage of one-hop source routing is the simple control of performance by selecting an appropriate intermediate node while still being scalable.

2. Adaptive network control mechanism [3]

The attractor selection-based VNT control adapts the environmental changes by selecting attractors using stochastic behaviour, deterministic behaviour, and simple feedback. The dynamic system that is driven by the attractor selection uses noise to adapt to environmental changes. In the attractor selection, attractors are a part of the equilibrium points in the solution space in which the system conditions are preferable.

In order to apply the attractor selection to VNT control, we consider the gene regulatory and metabolic reaction networks as optical and service overlay networks, respectively.

D. Resources Allocation

Fundamental problem in instantiation of Virtual Networks (VNs) is an optimal allocation of resources offered by a physical IP network. A key objective for the design of a VN instantiation is how to select substrate nodes with sufficient CPU, disk and the other hardware capabilities as well as substrate links with enough spare bandwidth, while minimising the usage of total resources of SN [8].

Some basic goals for a policy driven resource management system for VNs include: (i) system must allow users to reserveresources diametrically across the network, for providing a predictable and reliable operation, (ii) system must provide enough isolation, in order to avoid users from interfering with each others reservations, and (iii) system must have admission control mechanism so that only a limited number of requests are en queued for receiving service and thus avoiding congestion [8].

Approaches to resource assignment in VNs can be categorised as static and dynamic, before the former approach was not allowing any change in resource assignment during the life-time of a VN, and the latter approach allows to adaptively change the resource allocations on the basis of current demand and performance of VN.

1. Static Approaches [8]

• A basic algorithm: The problem of static assignments of resources to a VN has been investigated in as an assignment without reconfiguration.

• Traffic constraints based algorithm: A cost effective method for designing VNs, though which may not yield optimal results due to NP-hard nature of problem.

• Splitting and Migration of Paths: A greedy node mapping algorithm with an objective to maximise

revenue. It defines amount of resources available at node as a product of CPU capacity and link bandwidth. Link mapping is performed by k-shortest path algorithm [8].

2. Dynamic Approaches [8]

Dynamic assignment of resources is a weighted sum of reconfiguration rate, node and path switching. The selective reconfiguration algorithm depends on: (i) periodic marking of critically stressed nodes and links of substrate and (ii) per VN reconfiguration and performance monitoring.

• DaVinci, Framework for Dynamically Adaptive Virtual Networks for a Customized Internet. This architecture advocates a periodic reassignment of bandwidth among multiple VNs, which are sharing virtual resources derived from a common SN. The weakness of this approach are packet reordering problem because of usage multiple (virtual) paths, and SN need to know the performance objective function of all VNs which is not possible.

3. Miscellaneous Approaches [8]

• Autonomic Systems based: A combined approach comprising of VNs and Autonomic computing where a customer will request for the creation of a VN that is capable of delivering a desired level of a service. After the VN has been instantiated, its performance will be measured at regular intervals.

• Control Theoretic based systems: Computer systems should be designed in a way that they are amenable to feed-back control laws. In the same breath, one of the promising techniques of resource allocation in virtualized network environments is adaptive control theory.

III. PROOF OF CONCEPT

A. 4WARD VNet on HEN [4] [5]

The prototype implementation at HEN (Heterogeneous Experimental Network) which includes more than 110 computers connected together by a single non-blocking, constant-latency Gigabit Ethernet switch. The prototype takes advantage of node and link virtualization technologies to allow the instantiation of VNets on top of a shared substrate. It relied on Xen’s paravirtualization for hosting virtual machines, since it provides adequate levels of isolation and high performance VNP and VNO, so that the prototype can realize the instantiation of Vnets.

HEN physical nodes compose the substrate (PIP) which offers resources to the VNP for on-demand creation of virtual

networks. The NOC of the VNP establishes direct connection with a dedicated management node belonging to the PIP. This node is mainly responsible for realizing all the VNet requests to the PIP. It used an XML schema for the description of virtual resources with separate specifications for nodes and links. Our implementation supports resource discovery either at PIP (i.e., resources are not advertised) or at the VNO (i.e.,when VNO is aware of physical resources).

The prototype supports two options for node virtualization: (i) the virtual machines are created and booted on-demand as guest domains (DomUs), or (ii) the PIP has allocated CPU and memory to virtual machines in advance, avoiding their creation and booting upon receiving a VNet request.

Figure. 4 Prototype Overview at HEN Network[4]

For the inter-connection of the virtual nodes, we currently use tunnels with IPv4-in-IPv4 encapsulation. But it is not a limitation, other link-virtualization mechanisms, such as MPLS, could be used with this prototype.

Substrate node, illustrating the interaction between the management (i.e.,Dom0) and the guest domains (i.e., DomUs). Dom0 acts as the driver domain for the physical hardware, including the network interface cards (NIC). Xen splits a NIC driver into a front-end and back-end driver. The front-end resides in the kernel space of the guest operating system (i.e. in DomUs)while the back-end is part of the Dom0 kernel. Xen creates I/O channels between a Dom0 and eachinstantiated DomU connecting their corresponding back-end and front-end interfaces. In this sense, any packet sent through the back-end interface appears as being received by the front-end device in the DomU and vice versa. The standard Xen configuration results in bridging all the existing back-end interfaces (that correspond to separate DomUs) onto a single physical NIC. Alternatively, we provide the option using Click, in the case where bridging is not desired.

Figure. 5 Substrate Node with Bridge Configuration on the Prototype[4]

The substrate topology is constructed by configuring VLANs in the HEN switch. This process is automated via a switch-daemon which receives VLAN requests and configures the switch accordingly Virtual links are set up by encapsulating and demultiplexing packets, as shown in Fig. 5. More precisely, each virtual node uses it's virtual interface to transmit packets, which are captured by Click for encapsulation, before being injected to the tunnel. On the receiving host, Click demultiplexes the incoming packets delivering them to the appropriate virtual machine.

Figure. 6 Virtual Link Setup on the Prototype[4]

B. VINI on PlanetLab [10]

PlanetLab was a natural choice for a proof-of-concept VINI prototype and deployment, both due to its large physical infrastructure and the virtualization it already provide. PlanetLab isolates experiments in virtual servers (VServers). Each VServer is a lightweight “slice” of the node with its own namespace. Because of the isolation provided by PlanetLab, multiple PL-VINI experiments can run on the same PlanetLab nodes simultaneously in different slices.

VINI also leverages PlanetLab’s slice management infrastructure. VServers enable tight control over resources, such as CPU and network bandwidth, on a per-slice (rather than a per-process or a per-user) basis. The PlanetLab CPU scheduler grants each slice a “fair share” of the node’s available CPU, and supports temporary share increases (e.g., via Sirius). Similarly, the Linux hierarchical token bucket

(HTB) scheduler provides fair share access to, and minimum rate guarantees for, outgoing network bandwidth. Network isolation on PlanetLab is provided by a module called VNET that tracks and multiplexes incoming and outgoing traffic.

A networking experiment running in a slice in user space needs the illusion that each virtual node has access to one or more network devices. User-Mode Linux (UML), a full-featured Linux kernel that runs as a user-space process, for this purpose. For each user-space tunnel in our overlay topology, PL-VINI creates a pair of interfaces on a common subnet in the UML instances at its endpoints. Routing software running inside UML is in this way made aware of the structure of an overlay network. PL-VINI then maps packets sent on these network interfaces to the appropriate tunnel at a layer beneath UML. Our prototype also uses a modified version of Linux’s TUN/TAP driver to allow applications running in the networking experiment’s slice to send and receive packets on the overlay.

Our modifications to the driver allow it to preserve the isolation between different slices on PlanetLab: every slice sees a single TUN/TAP interface with the same IP address, but our changes allow multiple processes (in different slices) to read from /dev/net/tunX simultaneously, and each will only see packets sent by its own slice. For PL-VINI, we create a virtual Ethernet device called tap0 on every PlanetLab node, which has unique IP address chosen from the 10.0.0.0/8 private address space to route all match packets onto slice's own the overlay network.

Figure. 7 An IIAS Router on PL-VINI [4]

The Internet In a Slice (IIAS) is the example network architecture that we run on our PL-VINI . Researchers can use IIAS to conduct controlled experiments that evaluate the existing IP routing protocols and forwarding mechanisms under realistic conditions. IIAS employs the Click modular software router as the forwarding engine, the XORP routing

protocol suite as the control plane, OpenVPN as the ingress mechanism, performs NAT (within Click) at the egress, and use PL-VINI ’s tap0 device as an ingress/egress mechanism for applications running on a PL-VINI node. Figure 7 shows the IIAS router supported by PL-VINI. Routing protocols implemented by XORP, running unmodified in a UML kernel process, construct a view of the overlay network topology exposed by the virtual Ethernet interfaces. Each XORP instance then configures a forwarding table (FIB) implemented in a Click process running outside of UML.

The next development of VINI prototype implementation is GpENI-VINI [9] which made from two parts: MyPLC and IIAS (Internet In A Slice) tools. MyPLC is portable PlanetLab central (PLC) software which acts as a VINI resource manager on the GpENI testbed. It manages all aspects of the testbed such as sites, resources (nodes), users, and slices. IIAS tools help researchers to create virtual infrastructure (interfaces and virtual links) inside a slice includes a set of programs to create and get the topologies.

IV. CONCLUSION

Network Virtualization is key technology to run multiple network in the shared physical infrastructure and provide rapid provisions for service respecting network. Some "proof of concept" project has been implemented in order to prove that network virtualization can overcome ossification and facilitate service deployment for future internet.

REFERENCES

[1] Karsten Oberle, Marcus Kessler, Manuel Stein, Thomas Voith, Dominik Lamp, Sören Berger, "Network Virtualization: The missing piece", ICIN, 2009.

[2] Akihiro NAKAO, "Network Virtualization as Foundation for Enabling New Network Architectures and Applications", IEICE, March 2010.

[3] Takashi Miyamura, Yuichi Ohsita, Shin’ichi Arakawa, Yuki Koizumi, Akeo Masuda, Kohei Shiomoto, and Masayuki Murata, "Network Virtualization Server for Adaptive Network Control", ITC Specialist Seminar, Hanoi, 2009.

[4] Panagiotis Papadimitriou, Olaf Maennel, Adam Greenhalgh, Anja Feldmann, Laurent Mathy, ”Implementing Network Virtualization for a Future Internet”, Hoi An, Vietnam, 2009.

[5] Panagiotis Papadimitriou, Olaf Maennel, Adam Greenhalgh, Anja Feldmann, Laurent Mathy, ”Network Virtualization Architecture: Proposal and Initial Prototype", VISA, Spain, 2009.

[6] Nick Feamster, Lixin Gao, Jennifer Rexford, "How to Lease the Internet in Your Spare Time".

[7] K. Tutschku, T. Zinner, A. Nakao, P. Tran-Gia, "Network Virtualization: Implementation Steps Towards the Future Internet", Electronic Communications of the EASST Volume 17, 2009.

[8] Aun Haider, Richard Potter, Akihiro Nakao, "Challenges in Resource Allocation in Network Virtualization", ITC Specialist Seminar, Hanoi, 2009.

[9] Ramkumar Cherukuri, Xuan Liu , Andy Bavier, James P.G. Sterbenz, and Deep Medhi, "Network Virtualization in GpENI: Framework, Implementation & Integration Experience", IEEE/IFIP International Workshop, Ireland, 2011.

[10] Andy Bavier, Nick Feamster, Mark Huang, Larry Peterson, Jennifer Rexford, "In VINI Veritas: Realistic and Controlled Network Experimentation".