Network Virtualization - A Survey

Network Virtualization – A Survey
Aris Cahyadi Risdianto#1
#
School of Electrical Engineering and Informatics, Institute of Technology Bandung
Ganesa 10th
, Bandung, Indonesia
1aris.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 virtual
network 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 service
developer (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 reserve
resources 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".

Network Virtualization - A Survey

More Related Content

What's hot (20)

Similar to Network Virtualization - A Survey (20)

Recently uploaded (20)

Network Virtualization - A Survey