ELEN90011 Directed Studies
1
Table of Contents
Executive Summary .......................................................................................... 6
1. Introduction................................................................................................. 8
2. Network Virtualization................................................................................. 9
2.1. Types of virtualization....................................................................................10
2.2. Virtualization Tools ........................................................................................11
2.2.1. Xen..........................................................................................................11
2.2.2. VMware ...................................................................................................12
2.2.3. OpenVZ...................................................................................................12
2.3. Performance Evaluation ................................................................................13
3. Virtual Network Interface .......................................................................... 15
3.1. Network virtualization approaches.................................................................15
3.2. Network virtualization Technology.................................................................18
3.3. Xen prototype ................................................................................................22
3.4. OpenFlow prototype ......................................................................................24
4. Performance Improvement and Control of Virtual Network Elements ...... 27
4.1. Improvement on Xen prototype .....................................................................28
4.1.1. Xen migration ..........................................................................................28
4.1.2. I/O virtualization techniques ....................................................................29
4.2. Improvement on OpenFlow prototype ...........................................................30
4.2.1. OpenFlow migration ................................................................................31
4.2.2. OpenFlow discovery................................................................................32
4.2.3. OpenFlow spanning tree .........................................................................32
5. Autonomic Systems in Context-Aware Technologies............................... 34
5.1. Architecture and operation of autonomic systems ........................................34
5.2. Piloting with multi-agent systems ..................................................................35
5.3. Content-aware technology for network control..............................................38
6. Providing Isolation and Quality of Service to Virtual Networks................. 40
6.1. Difficulty in packet forwarding using Xen.......................................................40
6.2. Maximum Usage Controller...........................................................................42
7. Piloting System......................................................................................... 45
7.1. Autonomic Piloting Systems..........................................................................45
7.2. The multi-agent APS .....................................................................................48

2
8. Management and Control: The Situated View.......................................... 53
8.1. The fuzzy control system...............................................................................53
8.2. Anomaly Detection for Autonomous Management Virtual Networks System
(ADAGA) .................................................................................................................54
9. Internet of things (IoT) .............................................................................. 56
10. Software Defined-Network on Virtual Network and IoT.......................... 57
10.1. The Network Operating System ..................................................................58
10.2. The SDN interface.......................................................................................58
10.3. Network virtualization on SDN.....................................................................59
10.4. Internet of Things (IoT) on SDN ..................................................................60
11. Conclusion.............................................................................................. 62
12. References ............................................................................................. 63

3
Figure list
Figure 2.1 Non-virtual vs virtual computational environment [1] ....................... 9

Figure 2.2 Pluralistic architecture of virtual networks [1]................................. 10

Figure 2.3 Full Virtualization [2]....................................................................... 11

Figure 2.4 Paravirtualization [2]....................................................................... 11

Figure 3.1. Network Architecture: Monist and Pluralist modes [5].................. 15

Figure 3.2 Types of Virtualization Interface [6]................................................ 16

Figure 3.3 Network Virtualization Models [7]................................................... 17

Figure 3.4 Xen virtual networking: one data and control planes per virtual
router [9]................................................................................................... 18

Figure 3.5 OpenFlow virtual networking: a shared data plane per node with all
the control planes [9]................................................................................ 19

Figure 3.6 Header fields in an OpenFlow Network [1]..................................... 19

Figure 3.7 The centralized OpenFlow controller model [1].............................. 20

Figure 3.8 Forwarding table in TCP/IP and OpenFlow based networks [9] .... 21

Figure 3.9 Network relocation using Xen and OpenFlow [1]........................... 22

Figure 3.10 Xen prototype architecture [10].................................................... 23

Figure 3.11 Controller, physical and virtual router module interactions [10] ... 24

Figure 3.12 OpenFlow prototype architecture [7]............................................ 25

Figure 3.13 Application layer in OpenFlow GUI [7] ......................................... 26

Figure 4.1 Relationship between piloting plane and virtualized network element
[11] ........................................................................................................... 27

Figure 4.2 The architecture of virtual network elements [11] .......................... 28

Figure 4.3 Router migration between virtual and physical nodes [10] ............ 29

Figure 4.4 The FlowVisor operation [12] ......................................................... 30

Figure 4.5 The hierarchy of FlowVisor [12] ..................................................... 31

Figure 4.6 The operation of Flow Migration [13].............................................. 32

Figure 4.7 LLDP frame format [14].................................................................. 32

Figure 4.8 Network Topology by using spanning tree algorithm [1] ................ 33

Figure 5.1 The architecture of an autonomic element [16].............................. 34

Figure 5.2 Autonomic control loop [1].............................................................. 35

Figure 5.3 A multi-agent system architecture [17]........................................... 36

Figure 5.4 Ginkgo architecture [15]................................................................. 36

4
Figure 5.5 Dimax architecture [15] .................................................................. 37

Figure 5.6 JADE architecture [18] ................................................................... 38

Figure 6.1 Xen Architecture with two virtual networks [1]................................ 40

Figure 6.2 Packet forwarding in Xen-based networks [22].............................. 41

Figure 6.3 Availability of the secure data plane update via using MUC [1] ..... 43

Figure 6.4 Influence of MUC over the RTT [22] .............................................. 43

Figure 6.5 Resource sharing control by using MUC and TC [21].................... 44

Figure 7.1 An autonomic piloting-oriented architecture [25]............................ 46

Figure 7.2 Architecture of autonomic piloting system [1] ................................ 47

Figure 7.3 Different situated views based on the definition of algorithm [1].... 47

Figure 7.4 The piloting system in three autonomic planes [27]....................... 48

Figure 7.5 Class diagram of the PAs information model [28].......................... 49

Figure 7.6 The multi-agent system for self-management of VNs [29]............. 50

Figure 7.7 Recovery time with the multi-agent system and SCP [25] ............. 51

Figure 7.8 The Cloud environment with the multi-agent system of the VN [28]
................................................................................................................. 52

Figure 8.1 The Fuzzy control system architecture [6] ..................................... 54

Figure 8.2 The Processor utilization of a virtual router with and w/o controller
[31] ........................................................................................................... 54

Figure 8.3 Network components in an ADAGA system [31]............................ 55

Figure 10.1 Traditional and Software-Defined Network architectures [34]...... 57

Figure 10.2 The NOS Architecture [37]........................................................... 58

Figure 10.3 The SDN Interface [38] ................................................................ 59

Figure 10.4 Typical IoT gateways for smart homes [40] ................................. 61

Figure 10.5 SDN enabled IoT gateways for smart homes [40] ....................... 61

5
Table List
Table 2.1 Performance Evaluation of Virtualization Tools [1] ......................... 13

Table 5.1 An architecture of context-aware systems [15] ............................... 39

Table 6.1 CPU consumption on dom0 [21] ..................................................... 41

Table 7.1 The architecture of Virtual Network environment [25] ..................... 45

Table 7.2 The main functions of Autonomic Piloting Systems [26] ................. 46

6
Executive Summary
The network has led us into the digital society with information exchange
instantly around the world. However, with the growth complexity of the
traditional network, it becomes difficult to manage based on close or
proprietary network architectures and provide customized services to the
subscribers. To deal with the limitation for physical networks, virtual networks
are proposed depending on a pluralist network architecture, enabling multiple
virtual networks to coexist on a shared virtualization layer for a dynamic multi-
stack network.
A virtual network divides slicing of a physical resource into several virtual
resources including of a set of virtual routers and links on the same physical
infrastructure to enhance network performance. Xen and OpenFlow are
introduced for network virtualization, allowing multiplex several virtual networks
without performance loss.
In the traditional network model, a router comprises a control plane and data
plane. The control plane decides how to cope with network traffic and data
plane forwards traffic depending on the decisions made by the control plane.
The Xen architecture enables several Virtual Machines (VMs) to execute
simultaneously on the same hardware. Each VM runs a virtual router with its
own control and data planes that can be virtualized to provide influential and
flexible platform for network control and management. Moreover, It allows
adding new functions such as hop-by-hop packet processing, which can
implement network authentication and access control.
On the other hand, OpenFlow is an open standard architecture that allows
providing open protocols, and programing the flow table in different switches
and routers by centralizing control planes in a controller and separate the data
planes in the routers. Therefore, OpenFlow can easily maintain the whole
topology over all the virtual nodes.

7
The OpenFlow architecture is based on Software-defined network (SDN),
which can provide the following benefits:
• Dynamic and adaptive management
• Low cost
• Centralization and optimization
• Load-balancing and scalability
• Fault tolerance
SDN allows the network administrator to manage and program resources
according to user requirement via available Application Programming
Interfaces (APIs), which are proprietary or open on a controller. By using the
SDN data-control separation, it allows establishing slices based on multiple
parameters such as bandwidth, flowspace and CPU loads. Each slice is
independent without interference of other slices and subdividing slices can
establish the hierarchical model to improve the performance of SDN virtual
networks.
Furthermore, The SDN can modify the network behavior according to user
needs and provides flexible network management on Internet of things (IoT).
With an OpenFlow-based virtual network, it enables the Internet access control,
user management and monitoring according to usage capacity for each user or
device.
In the smart home, the IoT acts as a gateway to connect each of smart sensor-
embedded devices and forward data to external networks. If there are
thousands of hundreds IoT gateways in the smart home networking, they will
become very difficult to manage with high costs for organizations when the
network policy changes or the requirement of updating the software. By using
SDN, IoT gateways are regarded as the SDN-enabled switches and
programmed by the controller for routing, access control, and secure tunnel
establishment between the IoT gateway and data centers. Therefore, the SDN
controller can effectively centralize management of each IoT gateway for the
implementation of smart homes.

8
1.Introduction
With the advanced technology of the Internet, the network facilitates the
information exchange around the world. Nevertheless, the traditional network
becomes too complicated to manage because of closed and proprietary
network architectures. It is difficult to establish new and innovative services on
a single data center or interconnected data centers for enterprises. The main
cause of a traditional network limitation is that using switches, router and other
network devices to implement the large number of distributed protocols
becomes too complex on closed and proprietary interfaces. This has led to
four major issues.
Difficulty of optimization is the first issue. It is difficult for network operators to
introduce new revenue services and optimize the costly infrastructures such as
data center, wide area networks and enterprise networks. Known issues like
security, mobility, robustness and manageability of traditional networks are the
second problem that have not been successfully dealt with so far. Capital costs
are another problem. Operating costs continuous growth but the return of
investment has not been compensating yet. Difficulty of customization is a
further issue. Network operators and third parties are able to provide
customized cost effective solutions to subscribers because of proprietary and
closed networks.
In order to cope with the current limitations and support new requirements,
network virtualization is proposed based on a pluralist network architecture,
allowing multiple virtual networks to coexist on the top of a shared virtualization
layer for a dynamic multi-stack network. By doing so, service providers have
more opportunities to provide real-time multiple end-to-end and customized
services to customers with security levels.

9
2.Network Virtualization
Virtualization is a technique for sharing computational resources from physical
hardware, allowing levels of isolation between virtual environments. The
difference between a non-virtualized and virtualized computational
environment is shown in Figure 2.1. The left side of the figure is a conventional
computational architecture that an Operating System (OS) controls the bottom
hardware and applications are run on the OS. On the contrary, a virtualized
computational environment offers a virtualization layer, which enables multiple
OSs to execute simultaneously. Each OS has its own applications and controls
their access to the hardware [1].
Figure 2.1 Non-virtual vs virtual computational environment [1]
The benefit of virtualization can centralize storage pools by using virtual
volumes to consolidate free capacity and also integrate management interface
in order to reduce complexity and enhance system effectiveness.
Furthermore, virtualization technique can provide multiple virtual networks that
are comprised of a set of virtual routers and links [2]. Each virtual network has
a particular network stack to share a single physical network infrastructure, as
shown in Figure 2.2.
Virtual router resources include Central Processing Unit (CPU), Random
Access Memory (RAM), storage devices and network. CPU is used for
incoming packets processing. RAM is utilized to store forwarding the tables,
which is comprised of packets [3]. The main use of storage device is to store
Virtual Machine (VM) images. Network conducts forward packets as a task of a
router.

10
Figure 2.2 Pluralistic architecture of virtual networks [1]
Virtualization is implemented by a hypervisor or Virtual Machine Monitor (VMM)
that multitask the computational resources between multiple virtual
environments or known as VMs [1].
In order to establish a hypervisor for hardware virtualization, there are three
requirements: efficiency, resource control and equivalency. First of all, the
instructions of virtual CPU (vCPU) should be effectively running in the real
CPU without intervention from the hypervisor. Secondly, the hypervisor can
control all of the resources [2]. Finally, a virtual interface can provide to virtual
environment equivalent to the original interface.
2.1. Types of virtualization
CPU virtualization includes full virtualization and para-virtualization. Full
virtualization virtualizes the original interface that is exposed to virtual
environment and the guest OS located in the VM shown in figure 2.3.
Therefore, the guest OS can execute directly without modifications [2].

11
Figure 2.3 Full Virtualization [2]
Para-virtualization means alongside virtualization that communicate between
the guest OS and the hypervisor to provide better performance and efficiency
shown in Figure 2.4. However, the guest OS has to be modified and
recompiled to produce para-virtualized OS images.
Figure 2.4 Paravirtualization [2]
2.2. Virtualization Tools
There are three virtualization tools: Xen, VMware and OpenVZ.
2.2.1. Xen
Xen is an open-source hypervisor that uses the para-virtualization technique
and runs multiple VMs simultaneously on a single physical machine. Xen
architecture consists of a hypervisor resided above the physical hardware and
VMs located over a hypervisor. Each VM can run its own OS and applications
as shown in Figure 2.5 [4].

12
Figure 2.5 The Xen architechture [4]
2.2.2. VMware
VMware is based on the full virtualization and the architecture is comprised of
the hardware interface, VMM, resource manager, service console and VM
shown in Figure 2.6. VMware can dynamically share sources that can allocate
and relocate by the system administrator [3].
Figure 2.6 VMware architecture [3]
2.2.3. OpenVZ
OpenVZ is an open source OS-Level virtualization tool shown in Figure 2.7. A
Virtual Private Server (VPS) isolates each virtual environment and looks like a
physical layer with its own process, files, Internet Protocols (IP) addresses,
system configuration and permission of root shell access[1]. Hence, each VPS

13
can have its own applications and services independent of each other.
Nevertheless, due to the limitation of the same Linux OS on OpenVZ, it
becomes less flexible compared to Xen and VMware.
Figure 2.7 OpenVZ architecture [1]
2.3. Performance Evaluation
In order to distinguish the performance among three virtualization tools, the
same specification hardware was adopted to test CPU, Memory, Hard disk, file
system performance and network performances via algorithms and
benchmarking tools. The result was shown as Table 2.1.
Performance Xen VMware OpenVZ
CUP Good Poor Fair
Memory Fair Poor Good
Hard Disk Fair Poor Good
File System Poor Fair Good
Network Excellent Poor Fair
Table 2.1 Performance Evaluation of Virtualization Tools [1]
In general, Xen not only outperformed among CPU, memory and virtualized
network but also shares the same computer resources between the VMs with
no attenuation of performance caused by the hypervisor. On the other hand,
VMware performed the worst result in the test and does not allow modification
of source codes that become more inflexible. Similarly, although OpenVZ had
great computational performance, it is limited to the same OS and kernel that

14
result in different levels of router complexity [1]. As a result, and Xen becomes
the best ideal virtualization tool for building virtual routers that support any OS
inside the VMs.

15
3.Virtual Network Interface
There are two network architectures: monist and pluralist shown in Figure 3.1.
In monist model, only one protocol stack carries out over the physical layer at a
time that support all the applications. In opposition, pluralist model can
simultaneously support multiple networks, allowing each network to run a
protocol stack that meets the requirement of applications. It is obvious that
adopting multiple networks to provide different services is easier to deal with
multiple services at the same time than only a unique network [5].
Figure 3.1. Network Architecture: Monist and Pluralist modes [5]
Moreover, a further advantage of the pluralist architecture is the intrinsic
backward compatibility that each network can be one of supported networks in
parallel [5].
OpenFlow is based on Software Defined Network (SDN) and proposed by
Standford University to create virtual network in parallel. It is an open standard
structure to provide an opened protocol, which programs the flow table in
different switches and routers [1]. Developers can control flows by themselves.
3.1. Network virtualization approaches
Virtualization is considered a resource that divides slicing of a physical
resource into several virtual resources of the same structure but with different
capacities, as shown in Figure 3.2 [6].

16
Figure 3.2 Types of Virtualization Interface [6]
The concurrent exist of several virtual slices over the same resource is critical
because the virtualization layer separates the real resource and slices. Figure
3.2 also illustrates computer virtualization and network virtualization. The
computer virtualization is run by the Virtual Machine Monitor (VMM), which
supplies VMs with a virtual interface similar to hardware devices such as a
processor, memory, Input and Output (IO) devices. Likewise, each VMs can
implement directly over the physical hardware, but actually the resource of
hardware is shared among several VMs [7]. This is also called resource
sharing slicing that each VM is isolated and cannot interfere with each other.
Furthermore, computer virtualization is widely used in data centers to conduct
multiple servers in a single physical device.
The network virtualization originated from Virtual Private Networks (VPNs) and
Virtual Local Area Networks (VLANs) [8], allowing router virtualization by a
customized network protocol stack. Furthermore, the network virtualization can
be illustrated in the virtualization layer of architectural design shown in Figure
3.3.

17
Figure 3.3 Network Virtualization Models [7]
Figure 3.3 a) shows the traditional network element model with a single control
and data plane. In a router, the control plane is in charge of execution of the
network control such as routing protocols while the data plane is responsible
for implementing forwarding tables and hardware data routes.
In Figure 3.3 b), the control plane is virtualized on the virtualization layer,
allowing multiple control software to run on it and sharing the same data plane.
This model allows implementing multiple and customized protocol stacks
rather than single one protocol stack that greatly enhance programmability. In
Figure 3.3 c), both control and data planes are virtualized, enabling
customization data plane by sacrificing the performance of packet forwarding.
For example, each virtual control plane may not completely isolate and
interfere with each other in Figure 3.3 c) that results in dropping packets during
storing forwarding tables [7]. This will become a trade-off between network
programmability and performance.

18
3.2. Network virtualization Technology
By implementing shared data planes, Xen and OpenFlow can be used for
network virtualization, enabling multiplex several virtual networks without
performance loss compared to the same packet rate handled by a single virtual
network.
Xen enables several VMs to execute simultaneously on the same hardware as
shown in Figure 3.4. Each VM runs a virtual router with its own control and
data planes in the Xen virtualization layer [9]. Both data and control planes can
be virtualized to provide influential and flexible platform for network control and
management. It allows adding new functions such as hop-by-hop packet
processing, which can be used for network authentication and access control.
Figure 3.4 Xen virtual networking: one data and control planes per virtual router [9]
On the other hand, OpenFlow can separate control and data planes in order to
carry out the packet forwarding procedure in the data plane and the network
control procedure in the control plane. A controller includes a shared data
plane which is used for flow table while all the control planes are centralized in
a node, enabling running applications under the control of virtual network
shown in Figure 3.5 [9].

19
Figure 3.5 OpenFlow virtual networking: a shared data plane per node with all the control planes
[9]
The data plane in OpenFlow is a flow table described by counters, header
fields and actions. The header fields are a 12-tuple model that describes the
packet header shown in Figure 3.6. The 12-tuple structure supports high
flexibility for packet forwarding because a flow not only can be in Transmission
Control Protocol (TCP/IP) network, but also on the TCP port for the Medium
Access Control (MAC) address. For the objective in the future, packet header
will be described by virtual network administrators for a combination of fields
instead of fixed fields. By doing so, OpenFlow can forward packets by running
any protocol stack in networks.
Figure 3.6 Header fields in an OpenFlow Network [1]
The controller in OpenFlow works as an interface between the network
applications and forwarding elements that supplies the basic functions to
obtain packets from a flow to monitor nodes. An OpenFlow protocol between

20
the controller and network has to be compatible with any controller to run
network applications in Figure 3.7 [1].
Figure 3.7 The centralized OpenFlow controller model [1]
If using a single controller model to establish several virtual networks, different
applications running over the same OS are not isolated. This may terminate
the function of the controller and lead to harming all other virtual networks if
one application has bugs by itself. Hence, multiple controllers are preferable
adopted by FlowVisor, which enables different controllers to work over the
same physical network. FlowVisor is regarded as a proxy between the
forwarding elements and controller to ensure that the failure in one virtual
network will not impact the others[1]. OpenFlow can provide a flexible model
by reallocating network resources for distributed forwarding elements and
centralized control planes.
Both Xen and OpenFlow can support the Internet pluralist architecture. They
have different structures of virtualization. Xen established virtual networks by
dividing physical network elements into coexistent virtual routers. Therefore, a
virtual network is viewed as a set of interconnected virtual routers distributed
over the physical device. On the other hand, OpenFlow creates virtual
networks by centralizing control planes in the controller, enabling setting the
forwarding tables of each switch [9].
Furthermore, it is much more flexible that OpenFlow provides a forwarding
table than the TCP/IP table based on source to destination IP addresses
adopted by Xen. In contrast, OpenFlow utilizes an N-dimensional space to

21
define each flow, where N is the number of header fields for specifing a flow [9],
as shown in Figure 3.8.
Figure 3.8 Forwarding table in TCP/IP and OpenFlow based networks [9]
By using N-dimensional space in the forwarding table, it enables packets to be
forwarded not only on the IP but also other protocols. Consequently, OpenFlow
can support more virtual networks running in parallel while Xen is limited to the
number of VMs that can be multiplexed over the network hardware.
In order to maintain the same virtual topology in the Xen virtual network,
migrating virtual routers are used to transfer a physical router and establish
tunnels from neighborhood. On the other hand, OpenFlow, is simpler for
network reallocation because of the centralized control plane, which maintains
the whole topology over all the nodes, identifying where the physical devices
are and how they connect [1], as shown in Figure 3.9.

22
Figure 3.9 Network relocation using Xen and OpenFlow [1]
3.3. Xen prototype
Xen prototype is based on Web services that contain two main sections: the
Virtual Machine Server (VMS) and piloting plane as shown in Figure 3.10. The
piloting plane is for the management of virtual network elements by sending
commands to the VMS and provides services for integrated interface to control
network Xen machines. However, the piloting plane can be replaced by a
Graphic User Interface (GUI), which can access to whole network
administrative tasks by the Web service communication interface [10].

23
Figure 3.10 Xen prototype architecture [10]
On the other hand, there are other modules that have to be developed for
critical tasks in the VMS. For example, in order to obtain information related to
CPU, memory and network-related data, a data gatherer module is needed. In
the same way, the topology discovery module is also required to obtain the
virtual and physical network topologies. Migration module is needed for
migration of virtual routers without packet losses as well as control the virtual
router throughput. A further module is a scheduler for Virtual CPUs of the
virtual routers. These modules are required to retrieve data from virtual,
physical routers and the controller. Consequently, communication module is
needed to interconnect all of them shown in Figure 3.11. There is another
client communication module establishing exchange Extensible Markup
Language (XML) messages with the request and then delivering it via a socket
to the server communication module executing inside the physical router [10].
If the request comes from the virtual router, then the physical layer acts as an
intermediate between the virtual router and controller.
All in all, VMS is used to address physical and virtual hosts of the network
while the GUI simplifies the network administration by the Web service
communication interface.

24
Figure 3.11 Controller, physical and virtual router module interactions [10]
3.4. OpenFlow prototype
The OpenFlow prototype is based on Web Services. The communication
between the prototype and external applications utilizes the HTTP (Hyper Text
Transfer Protocol) to exchange XML messages. In Figure 3.12, the Network
Operating System (NOS) controller offers the OpenFlow protocols and
implements the secure channel for running the applications. There are six
applications running on a NOS controller: Stats application is used to collect
switch-related statistics and convert them into XML messages. Discovery
application explores the network topology and describes it as an XML
message. Spanning Tree application implements a spanning tree algorithm to
avoid network loops and redundant broadcast retransmissions. Flow Manager
application carries out flow changes by adding, deleting and modifying flows.
Flow Migration application conducts flow modifications by migrating a flow from
one path to another [7]. Web Server application undertakes the HTTP protocol
to provide an interface between NOS controller and the external application.

25
Figure 3.12 OpenFlow prototype architecture [7]
Moreover, users can access the interface, execute commands and queries,
and modify flow tables to facilitate configuration and network management via
a Web browser.
The OpenFlow GUI is comprised for three layers shown in Figure 3.13. Data
link layer is the first layer, which is comprised of a NOX controller and its
applications. It is used to conduct user commands and collect data. The
second layer is data processing layer that contains a Web server for
processing all received information before sending to other layers. The
presentation layer is the third layer that consists of script files and mark
described by the web browser such as Hyper Text Markup Language (HTML).
It organizes and displays the data to the user. Furthermore, the application
communicates among these layers over the HTTP protocol [7].

26
Figure 3.13 Application layer in OpenFlow GUI [7]

27
4.Performance Improvement and Control of Virtual
Network Elements
Piloting plane is developed to execute intelligent algorithms to automatically
instantiate, delete virtual network, migrate network elements and set resources
allocation of parameters as shown in Figure 4.1. Therefore, piloting plane can
dynamically allocate resources to each virtual network based on the condition
of current network, number of users, priority of per virtual network and Service
Level Agreements (SLA) [11].
Figure 4.1 Relationship between piloting plane and virtualized network element [11]
A virtual network element consists of the virtualization and piloting planes. The
virtualization plane offers the platform for running logical network elements
over a single shared physical network. The piloting plane supports the
intelligence performance of network optimization based on SLAs for each
virtual network.
In Figure 4.2, the controller is regarded as the piloting plane that aggregates
and receives information sent by nodes. All nodes are required to provide an
interface with piloting plane and convert to XML control message [11]. Sensors
and actuators also form the virtualization system. Sensors collect information
and actuators implement actions.

28
Figure 4.2 The architecture of virtual network elements [11]
4.1. Improvement on Xen prototype
The Xen-based prototype consists of controller, router and client nodes. The
controller node is used to receive and consolidate data from all network nodes.
It obtains data and sends commands to physical and virtual router. Router
nodes include physical and virtual routers that execute several modules and
receive commands from the controller node. Finally, the client node enables
users to interact with the controller by using the GUI for user monitoring and a
simple control interface shown in Figure 3.11.
The controller node involves the VMS and client communication. The VMS
uses a Simple Object Access Protocol (SOAP) interface to interact with the
piloting plane and client node. It integrates all prototype information and runs
algorithms. The client communication communicates with other router nodes
running on other routers [10]. In addition, if a request is addressed to a virtual
router, the proxy module in the physical router is forwarded to the virtual router
as a message channel.
4.1.1. Xen migration
The purpose of Xen migration is to organize virtual networks or routers among
physical resources with influencing the packet forwarding and network control
service. Xen migration also can reconfigure dynamically of the network
topologies without turning off the running routers.
In Figure 4.3, the virtual node B is migrated from the physical node 2 to node 6.
Nevertheless, there is no one-hop neighbor of the physical node 1. Hence, a

29
tunnel from the physical node 6 to node 1 requires to be established to
simulate a one-hop neighborhood in order to conduct link migration. Another
solution is to build a new virtual router to replace the tunnel [10].
Figure 4.3 Router migration between virtual and physical nodes [10]
4.1.2. I/O virtualization techniques
I/O virtualization is undertaken by the VMM, which is required to multiplex
outgoing data flows and de-multiplex incoming data flows. I/O virtualization
techniques are comprised of direct assignment of device, multi-queued devices
and Single Root I/O Virtualization (SR-IOV). The direct assignment of device
uses Direct Memory Access (DMA) to transfer data directly to a VM without
being processed by VMM or hypervisor.
Multiple queues are address by the Interface Card (NIC) in order to classify
packets using a certain pattern such as the virtual local area network (VLAN)
or MAC destination address and push them into the appropriate queue.
Consequently, each queue has its own traffic isolated from each other.

30
The SR-IOV standard can share Peripheral Component Interconnect Express
(PCI-Express) devices such as NICs access among VMs [12]. It also can
bypass the VMM involvement in data transfer.
4.2. Improvement on OpenFlow prototype
The FlowVisor is adopted to allow multiple NOS controllers to execute in
parallel in order to divide the physical network into several virtual networks. It
regulates the sharing of network resources such as the bandwidth, traffic,
usage of switch CPU and flow tables [1].
The FlowVisor is regarded as a special type of OpenFlow controller. In Figure
4.4, the FlowVisor intercepts the flow messages delivered by guest controller
that verifies the user slicing policy. Then it modifies the message to refine the
control to a slice of the network [12]. Finally, if the message matches the slice
policy, FlowVisor forwards it from switches to guests.
Figure 4.4 The FlowVisor operation [12]

31
The FlowVisor hierarchy virtualizes several switches in parallel. In Figure 4.5
FlowVisor 1 recursively divides the virtual slices defined by FlowVisor 2 and 3.
The OpenVisor aims at five network resources: bandwidth isolation, topology
exploration, traffic, device CPU surveillance and control of forwarding tables.
Figure 4.5 The hierarchy of FlowVisor [12]
4.2.1. OpenFlow migration
Flow Migration defines a new route between source and destination of
OpenFlow switches, and then modifies the current path of the flow to new path
without packet loss. Dijkstra Algorithm is utilized to calculate the smallest path
from the source to the destination for the Flow migration shown in Figure 4.6 in
order to minimize the number of hops in the new path [13].

32
Figure 4.6 The operation of Flow Migration [13]
4.2.2. OpenFlow discovery
The discovery application carries out the Link Layer Discovery Protocol (LLDP),
which enables nodes to send information of capabilities and the current status
of network devices. The LLDP frame format is shown in Figure 4.7. With this
information, the application establishes a data structure, which involves the
source switch and port, and destination switch and port. Therefore, the data
structure is used to identify a link and the aggregation of all links in a network
describes the network topology [14].
Figure 4.7 LLDP frame format [14]
Moreover, the default application only provides the physical network topology,
but information about the prototype of virtual networks also required. Therefore,
the modified discovery application is adopted to obtain the definition and
forward traffic in virtual networks.
4.2.3. OpenFlow spanning tree
Multiple paths between a source and destination are a common characteristic
of network topologies. However, although these redundant paths raise network
reliability, it can also lead to errors during broadcast in Ethernet networks. As a

33
result, the spanning tree algorithm is used to establish a topology for
broadcasting frames without creating loops as shown in Figure 4.8 [1].
Figure 4.8 Network Topology by using spanning tree algorithm [1]

34
5.Autonomic Systems in Context-Aware Technologies
Autonomic systems such as multi-agent systems (MASs) are used for a pilot
system to adapt complex environment, conduct the autonomic computing of
highly dynamic networks without intervention and increase network scalability
[15].
5.1. Architecture and operation of autonomic systems
The architecture of an autonomic element is composed of a managed
component and correspondent autonomic manager. An autonomic manager
undertakes the requirement of self-monitoring and self-adjusting. An automatic
manager includes an internal monitor, external monitor, self-monitor, self-
adjuster and heartbeat monitor as shown in Figure 5.1.
Figure 5.1 The architecture of an autonomic element [16]
An internal monitor looks up the state of the managed component and sends
the information to the self-monitor for action and assessment. Likewise, an
external monitor examines the state of the environment through an autonomic
signal channel, which connects to the other autonomic managers and passes
the information to the self-monitor component. A self-adjuster enables the
status adjustment of the managed component. A heartbeat monitor
summarizes the state of autonomic element and sends to other autonomic
elements for the control of the autonomic state [16].

35
Autonomic systems work as the autonomic control loop that comprises collect,
analyze, decide and act factors as shown in Figure 5.2. The loop collects a
variety of information including conventional network sensors, reporter streams
and high-level devices following by analysis of a model construction [1].
Afterwards the decisions are executed by the act of users or administrators
and then the process goes to the next control cycle.
Figure 5.2 Autonomic control loop [1]
5.2. Piloting with multi-agent systems
An agent is viewed as an entity of thinking and acting independently of the
environment [17]. A multi-agent system can perceive, follow objects in the
environment and interact with other agents based on the goals and motivations
shown in Figure 5.3.

36
Figure 5.3 A multi-agent system architecture [17]
In order to establish context-aware infrastructure, an autonomic platform
including a knowledge plane and piloting plane has need to be created. There
are three types of autonomic platforms: the Ginkgo, Dimax and Java Agent
Development Framework (JADE) platforms [15].
The Ginkgo platform provides the knowledge plane with application information
and distributed knowledge in real time shown in Figure 5.4.
Figure 5.4 Ginkgo architecture [15]
Dimax is a fault-tolerant multi-agent platform that provides multiple services. It
can divide into three levels: the middleware, application and monitor layers

37
shown in Figure 5.5. The middleware layer offers naming, fault detection,
observation and replication services. The naming service maintains a list of
agents within its administration domain. The failure detection service is used to
detect agents at the faulty server from the list and then replicate them to other
hosts. The observation service controls replication and replication service
avoids failure of MASs. At the application layer, it provides a list of libraries to
build multi-agent applications [15].
Figure 5.5 Dimax architecture [15]
JADE platform includes the libraries, which is used to develop application
agents and the run-time environment. Each instance of the JADE run-time is
known as containers and offers homogeneous layers shown in Figure 5.6 [18].

38
Figure 5.6 JADE architecture [18]
5.3. Content-aware technology for network control
A context-aware system can be used to characterize the situation of an entity
by any information. It also enables the system and network control to work
automatically without human intervention [19].
The context-aware system consists of three functions of subsystems: sensing,
thinking, and acting shown in Figure 5.7. The first sensing subsystem breaks
into sensors and raw data retrieval layers. Sensors are developed to detect
context information from physical and virtual networks. After gathering data by
the raw data retrieval layer, sensors translate raw data into XML data
structures for request by agents. The context information can control the
resource allocation among virtual networks. The computational resources of
network elements include the memory, bandwidth, traffic and network topology.
With the context information, the piloting system can deal with environmental

39
changes in order to ensure the isolation and the resource allocation of each
virtual network.
The second thinking subsystem is comprised of preprocessing and
storage/management layers. The preprocessing layer converts and aggregates
all context information from different sensors to offer more accurate information.
The storage/management defines knowledge representation techniques and
store context information in a machine process form.
The third acting subsystem is part of the piloting system responsible for
adapting to environmental changes based on the context information collected
or situations recognized by the sensing or thinking subsystems. The acting
subsystem has four applications: establishment of multiple tailored network,
flexible management, real-time control and monitoring [15].
The establishment of multiple tailored networks can be used in each virtual
network with its own protocol stack, network topology and administration policy.
This can allow service providers to allocate an end-to-end virtual path to
provide customized network services with Quality of Service (QoS) guarantees.
Flexible management in network virtualization layer can move a virtual network
component from one physical hardware to another without the modifying the
virtual network topology. Real-time control supports real-time dynamically
allocation of resources to each virtual network depending on the network
condition, number of users, priority of virtual networks and service level
agreement. Monitoring is a further application for observing available
bandwidth, processor, memory usage, connection and end-to-end delay [19]
Applications Application
Subsystem
Storage/Management
Thinking
SubsystemPreprocessing/Reasoning
Raw Data Retrieval
Sensing
SubsystemSensors
Table 5.1 An architecture of context-aware systems [15]

40
6.Providing Isolation and Quality of Service to Virtual
Networks
A dynamic control, which comprises the local and global control, is proposed to
ensure isolation, Quality of Service (QoS) and improve the Xen network
management and overall performance. The local control can guarantee the
isolation and Service Level Agreement (SLAs) with each physical node in the
Xen network while the global control deals with physical node failures by using
a distributed fault-tolerant algorithm and migrates virtual nodes [20].
6.1. Difficulty in packet forwarding using Xen
A virtual network is viewed as a set of virtual routers established over the
physical infrastructure. Xen architecture consists of a hypervisor, a privileged
virtual machine called dom0 and normal virtual machine, called user domains
(domUs) shown in Figure 6.1 [1].
Figure 6.1 Xen Architecture with two virtual networks [1]
The Xen hypervisor manages the access to the physical resource. Dom0 can
directly access the hardware and establish an interface between the virtual
drivers resided in the domUs and physical device. Nevertheless, the Xen
hypervisor cannot effectively isolate dom0 utilization of resources shown in
Table 6.1. A malicious or fault action in domUs can easily consume the dom0
CPU utilization that may lower the overall performance of other domains [21].

41
CPU (%) Description
0.71 ± 0.60 Basic CPU consumption on dom0
66.43 ± 8.93 TCP traffic from domU to dom0
85.49 ± 5.91 TCP traffic from domU1 to domU2
1.79 ± 1.01 TCP traffic from an external machine to domU
Table 6.1 CPU consumption on dom0 [21]
The traditional Xen architecture is inefficient for running networks because the
packet forwarding of domUs consumes more time and longer path shown in
Figure 6.2a). In opposition, the plane separation can improve the forwarding
performance because data packets are forwarded directly by a shared data
plane in dom0 shown in Figure 6.2b) [22].
Figure 6.2 Packet forwarding in Xen-based networks [22]

42
6.2. Maximum Usage Controller
In order to provide isolation to the Xen virtualization platform by managing the
use of dom0 resources, the Maximum Usage Controller (MUC) is proposed for
a fixed amount of resources and a parameter known as the weight. The fixed
resource reservation ensures the availability of minimal resources to each
virtual network while the weight aims at idle resources, which allocates among
virtual networks [23].
MUC monitors bandwidth by looking up the volume of bits transmission on
each output physical link. If a router exceeds the distributed bandwidth in the
out link, the MUC punishes a router by dropping its packets. Similarly, the
MUC can manage memory utilization by observing the size of the forwarding
table of per virtual router. If the memory of dom0 reaches the limits, all virtual
routers will occupy more memory. Hence, the fixed resource reservation will be
punished to reduce the size of the routing table [22]. This will reduce
forwarding performance by domUs instead of packet drops.
In addition, a malicious behavior occurs when a domU attempts to break or
damage isolation in virtual networks. It is classified as an opponent domain,
which is also punished by dropping packets or routes. Furthermore, the
punishment should not influence the low-value transmission, but it can avoid a
domU exhausting all dom0 resources.
An effective MUC is analyzed in opponent domains to confirm the efficiency for
sharing resources. The success probability of data plane updates with the
traffic between two virtual machines shown in Figure 6.3 a). The MUC
punishes traffic from domU2 to domU1 to avoid the overload of Dom0
resources [1]. Therefore, MUC guarantees the update of a secure data with
high availability and high-performance connection between routers.

43
Figure 6.3 Availability of the secure data plane update via using MUC [1]
In Figure 6.4 a), the round trip time (RTT) is measured the background traffic
with MUC. Without the background traffic, the result shows that data
transmission with a low RTT for both MUC and no MUC. Nevertheless, when
background traffic is implemented, the dom0 CPU is overloaded and
increasing the response time of the system also known as the RTT. On the
other hand, MUC avoids dom0 CPU being overloaded [22]. Although MUC
control leads to packet drops, the drops do not cause a main impact on traffic
shown in Figure 6.4 b).
Figure 6.4 Influence of MUC over the RTT [22]
Another experiment is the average throughput of the TCP and User Datagram
Protocol (UDP) traffic from external virtual machines conducted by the
resource sharing of MUC and traffic control (TC) shown in Figure 6.5. The
available resources are allocated equally between two virtual networks.
Although MUC introduces a more variation in traffic than TC, the average
throughput of MUC has a lower error rate [21]. This result indicates that MUC
has a higher fairness in the link resource sharing for Xen architecture.

44
Figure 6.5 Resource sharing control by using MUC and TC [21]

45
7. Piloting System
The piloting system is used to deal with Virtual Networks (VNs) such as control
and management entities over a multi-agent system. Also, the piloting
architecture is based on piloting agents (PAs) in federations [1].
7.1. Autonomic Piloting Systems
Autonomic Piloting Systems (APSs) are proposed by IBM and provide different
management tasks among various nodes, links and services. In order to solve
a problem of conflicting configurations between two sub-networks, the piloting
plane allows collaboration of different autonomic control loops that are non-
conflicting [24].
The architecture of VN environment involves four planes shown in Table 7.1.
The data plane is used to transmit data from a sender to one or multiple
recipients [25]. The management and control planes conduct algorithms for
diagnostics, failure detection, routing, security control and management, and
flow control.
Plane Type Function
Data Plane Forwarding data
Control Plane Control algorithms
Management Plane Features of management
Piloting Plane Provide real-time information to the management and
control plane
Table 7.1 The architecture of Virtual Network environment [25]
This architecture can be viewed as autonomic piloting-oriented architecture
illustrated in Figure 7.1. The piloting plane consists of two sub-planes: the
Knowledge Plane (KP) and Orchestration Plane (OP). The KP provides
knowledge for control and management algorithms while the OP synchronizes
networks elements. The main purpose of the Piloting Plane (PP) is to
supervise and integrate all other planes’ behaviors. The PP also can be
regarded as a control framework that can be federated with other PPs,
optimizes monitoring of network and ensure the availability of the required
knowledge [25].

46
Figure 7.1 An autonomic piloting-oriented architecture [25]
The PP works as a control workflow for all APSs. Each APS deals with a
cluster of virtual devices or networks by a common policies and knowledge
with the functions in Table 7.2 [26].
Name Functions
Federation Allow the APS or piloting domain to merge into a large
domain
Negotiation The APSs act as the entity and negotiate other
autonomous entities in order to support SLAs
Distribution The APS offers communication and control services that
divides tasks and run simultaneously over multiple PAs
with the PP
Governance Each APS can conduct in an individual, distributed or
cooperative modes
System Views The APS can store and disseminate information via KP
through interfaces
Table 7.2 The main functions of Autonomic Piloting Systems [26]
According to Figure 7.2, APSs consist of three types of architecture: The first
type is the dynamic planner, which is used for policy-based dispatcher. It
establishes and eliminates behavior, and conducts the interface for the PAs
and main inter-management functions. The second type implements piloting
tasks and works as a proxy for the communication between APSs and PAs. A

47
further type is the situated view, which comprises of the intra-system and inter-
system views. The difference between them is that the intra-system regards a
single APS as an overall view whereas the inter-system views the APSs as a
whole of the entire PP [1].
Figure 7.2 Architecture of autonomic piloting system [1]
Furthermore, situated views may be different depending on the algorithm for
the entire, intermediate and one-hop views illustrated in Figure 7.3.
Figure 7.3 Different situated views based on the definition of algorithm [1]
Similarly, an autonomic system is divided into three autonomic planes shown
in Figure 7.4. The OP manages and integrates behaviors in real time via the
dynamic planner. Each behavior is considered as a specialized function
conducted by the agent. In the KP, agents in the network environment review
the situated view for important modifications. In control and data planes,
Network Elements (NEs) are configured such as the condition of computing
bandwidth[27].

48
Figure 7.4 The piloting system in three autonomic planes [27]
7.2. The multi-agent APS
Piloting Agents (PAs) in the APS are used to monitor and control physical and
virtual resources. The PAs are resided in routers and send data over the link
shown in Figure 7.5. All communication is depending on the dissemination of
information stored in the KB, which can be assessed by the behaviors [28].

49
Figure 7.5 Class diagram of the PAs information model [28]
Moreover, the PAs can break into four behaviors: monitor, analyze, plan and
execute, which are conducted periodically in order and creates the autonomic
cycle of the manager. Monitor gathers data from virtual and physical nodes,
and stores in the KB. Analyze diagnoses the usage of physical network link. If
the utilization exceeds the threshold, the KB will update the information to
inform other behaviors. Plan makes a proposal when a threat occurs. Execute
takes an action and inform the modifications for other behaviors [28].
The multi-agent system can be used for a distributed architecture to allow self-
management of VNs over the PP such as self-configuration, self-optimization
and self-protection illustrated in figure 7.6. This distributed management
architecture with self-organizing VNs maintains effective utilization of physical
resources, monitors the target link and minimizes the network traffic load via
the migration of virtual nodes. It is conducted by the self-organization based on
the autonomic control loop [29].

50
Figure 7.6 The multi-agent system for self-management of VNs [29]
Furthermore, the multi-agent system is required for failure recovery. Failures
can appear via problems in virtual or physical nodes or even in the physical
links. Hence, agents have a responsibility to diagnose virtual routers and
inform other neighbors for information. Also, an autonomic control loop for self-
healing of VNs is carried out by the dynamic planner and four behaviors of
Monitor, Analyze, Plan and Execute [29].
If the virtual router is failed to connect, it can recover by self-management of
two ways. The first establish a VM from the image file and the second restores
the machine from the backup memory file. The recovery time T! from a VN can
present to the equation:
T! = T! + T! + T! + T!
where T! is failure diagnosed time; T! is the time of planning action which
includes information exchange between agents; T! is the time of creating the
VM and T! is the time of routing protocols.
Similarly, the static and dynamic routings are used for self-management in the
VN. The virtual router is manually configured by the static routing while
dynamic routing conduct the virtual router by the Open Shortest Path First
(OSPF) algorithm [27].

51
The multi-agent system with the Secure Copy Protocol (SCP) can also be used
for monitoring the recovery time of the virtual router shown in Figure 7.7. The
dynamic routing consumes more time due to the convergence time the routing
algorithm. Although the approach is time-saving for transmission and storage,
the backup can influence the network performance during the high utilization.
Therefore, distributed storage and increased memory can alleviate the
overhead [25].
Figure 7.7 Recovery time with the multi-agent system and SCP [25]
Finally, the idea of an APS to deal with VNs can also be applied to a cloud
environment shown in Figure 7.8. The PAs monitors network resources and
conducts actions such as power management based on SLA. PAs can be
formed as a group into domains like neighborhoods. A neighborhood
comprises the PAs that can request an action from other neighborhoods such
as the requirement of increasing the bandwidth of the VN [28].

52
Figure 7.8 The Cloud environment with the multi-agent system of the VN [28]

53
8.Management and Control: The Situated View
Control and management of network virtualization allows multiplexing
hardware access and offering logical slice of resource to virtualize networks.
The knowledge plane stocks information of each virtual network elements and
allocates in different nodes, which have a partial view of the knowledge plane.
Therefore, the situated view is a partial view of the whole network subject to
the environment and ambient. The knowledge plane has difficulty in the
schedule of making decisions and updating network element information.
Hence, mechanisms are proposed to detect and correct based on the Xen
platform [1].
8.1. The fuzzy control system
The fuzzy control system depends on the detection of SLA violations and the
real-time penalty of misbehaving virtual nodes. It calculates the system load
based on the processor and memory. Furthermore, The fuzzy control system
has small computational complexity and can enhance system performance to
reduce the response time of the controller [6]. The control system architecture
has a distributed management of controller agents, which manage both
physical and virtual routers shown in Figure 8.1.
There are five modules composed the controller agent. The Strategy and
Policy Module (SPM) uses management strategies to control and update the
current strategy for each control and monitoring daemon. The Service Level
Module (SLM) manages the database of each virtual router. The Knowledge
Base Module (KBM) stores information and description of violations, estimates
migration and updates detections. The Actuator Module (AM) obtains the
profile and statistics of each virtual router. The Communication Module (CM)
exchanges information among controllers via secure channels [6].
The fuzzy control system consists of three mechanisms. The profile generation
is the first mechanism to offer utilization statistics and SLA detection of
violation. The system load estimator is another mechanism that combines
multiple resources at the output. The adaptive punishment mechanism is a
further mechanism that produces a level of punishment to the system [30].

54
Figure 8.1 The Fuzzy control system architecture [6]
The experiment shows that without the controller, the virtual router may occupy
the main resource of utilization, possibly lower the performance of other
routers illustrated in Figure 8.2. With the controller, the virtual router is limited
to the processing consumption of the virtual machine based on the SLA [31].
Figure 8.2 The Processor utilization of a virtual router with and w/o controller [31]
8.2. Anomaly Detection for Autonomous Management Virtual
Networks System (ADAGA)
The ADAGA system can collect, analyze data and send alarms to notify
possible abnormality happening in network environments. It regards the
initialization of all time series as zero by the correct predictor, which analyzes
false positive and negative values when predictor parameters are different.
False positive means that alarms were wrongly sent because of no anomalies.

55
False negative means that alarms were not generated when anomalies
occurred [31].
The ADAGA system focuses on detecting anomalies and fixing mechanisms
on virtual networks. The network components in ADAGA system are
composed of identification, location data of equipment and connections with
multiple processors, memories and network interface models shown in Figure
8.3. Analyzing the data statistics rather than collecting real data defines an
effective anomaly detection system. The feature not only provides more
effective processing and storage but also avoids issues with privacy of the data
packets [31].
Figure 8.3 Network components in an ADAGA system [31]
In time series, a fixed sampling interval may lead to distortions in the
observations because an unpredictable event may synchronize and also
cannot accurately observe periodic behaviors on the virtual network. This issue
reduces accuracy of detection. The time series management module in the
ADAGA system provides and controls the time series with the received
observations to minimize the overhead. Also, the ADAGA system offers an
alarm control with the cumulative notices of alarms. If the system detects an
anomaly during the observations, the alarm will be sent to notify the system
based on a counter threshold defined by the network administrator [32].

56
9.Internet of things (IoT)
Internet of things (IoT) is an integrated system of connected physical objects
that can access via the Internet. The things in IoT can an electric device with
built-in-sensors as an example. The object is assigned an IP address and able
to collect and transfer data over the Internet without manual assistance or
human intervention.
IoT allows the things to gather data without any help from us. Therefore, we
can track and analyze every thing, which not only greatly reduce costs, waste
and loss but also increase convenience and performance. Via IoT, we can
know the instant information from everywhere. It allows devices to observe,
identify and understand a circumstance or the surrounding without being based
on human help [33].
IoT can connect embedded devices in different systems to the Internet. When
the devices are connected online, they can be controlled from anywhere. IoT is
an innovation force that can help industries improve performance and provide
better results. For instance, Business in the utilities, oil, gasoline,
manufacturing, and transportation can utilize IoT to provide instant monitoring
and up to date information for the customers.
Furthermore, IoT can help organizations reduce the expenditure via improve
process efficiency, productivity and property utilization. With improved devices
tracking by using sensors and connectivity, IoT can benefit the real-time
services for smarter devices of the things.
However, if the IoT is used in traditional networks, it may be limited to the
proprietary or close network. The data center of traditional architecture has
become too complex and difficult to deal with if the thousands of hundreds
data are sent to the data center from the IoT devices at the same time.
Therefore, virtual networks are proposed to solve the situation and provide a
better network architecture to improve the efficiency and performance on IoT.

57
10. Software Defined-Network on Virtual Network and IoT
Software-Defined Network (SDN) is a network architecture that provides
dynamic and adaptive management with the low cost and high bandwidth. The
architecture separates the control plane, which is the network control for
software applications and data plane that is used for data processing in
forwarding tables, allowing a centralized control plane in a controller with
multiple data plane supported by the OpenFlow protocol illustrated in Figure
10.1 [34].
Figure 10.1 Traditional and Software-Defined Network architectures [34]
In traditional network, the network administrator can only configure some basic
parameters via low level commands and each modification in the network
policy needs individual configuration from each network devices. On the other
hand, SDN allows the network administrator to manage and program
resources according to user requirement via available Application
Programming Interfaces (APIs), which are proprietary or open on the controller
[35].
The advantage of OpenFlow is the elements and functions of network devices
can be control externally. The elements include routing tables and functions
such as read the header, send a packet to the port and discard a packet. By
updating the firmware, the physical network devices can support OpenFlow
without the replacement of hardware to implement SDN services [36].

58
10.1. The Network Operating System
The Network Operating System (NOS) is based on the notion of OpenFlow
that the operating system enables users to establish applications through high-
level abstraction of information and resources. The abstraction is divided into
southbound and northbound APIs. The northbound API allows application and
management system to program the network and request services such as
routing, computing data path and security. The southbound API uses the
OpenFlow protocol and defines a set of open commands for data forwarding
that enables routers to explore the topology of the network and define the
physical behavior and virtual switches based on the request by the northbound
API shown in Figure 10.2 [37].
Figure 10.2 The NOS Architecture [37]
10.2. The SDN interface
The SDN interface is comprised of the three-tiered architecture. The top tier is
applications and high-level policies. The control plane tier is in the middle for
data traffic and the data plane tier comprises physical and virtual switches [38].
A northbound API communicates with a high-level element whereas a
southbound API enables a particular network to communicate with a lower-end
element illustrated in Figure 10.3.

59
Figure 10.3 The SDN Interface [38]
10.3. Network virtualization on SDN
Virtual network allows different operating systems to share hardware resources,
which means multiple virtual networks can run on the same infrastructure with
its own topology and routing protocols. Nevertheless, the typical virtual network
is controlled only by the network administrator with finite parameters such as
port numbers and some particular network protocols. By using the SDN data-
control separation, it allows establishing slices based on multiple parameters
such as bandwidth, flowspace and CPU loads. Each slice is independent
without interference of other slices and subdividing slices can create the
hierarchical model to improve the performance of SDN virtual networks [37].
Moreover, the controller duplicates the configuration of flow tables from the old
to new switch and modifies the routes automatically, allowing replacing a
network device with the disruption or packet loss. Therefore, the SDN virtual
network can dynamically turn off or deactivate the unused network devices on
weekends or at nights and automatically enable them for the traffic
requirement [38].

60
10.4. Internet of Things (IoT) on SDN
The Internet of Things (IoT) enables active participants such as the number of
users and devices to communicate among themselves by exchange data,
information and establishing services via a unified framework [39]. The SDN
can modify the network behavior based on user needs and offers flexible
network management on IoT. With an OpenFlow-based virtual network, it
enables the Internet access control and user management and monitoring
according to usage capacity for each user or device. For example, the smart
home with automatic appliances such as the air conditioning, watching
machine, smart plug and other sensor-embedded devices of lighting and
multimedia is commonly used on the IoT [37].
The IoT acts as a gateway to connect each of smart home devices to external
network. It has some significant features. Firstly, the IoT gateway forwards
data from the smart devices to outside and protects the devices from external
attacks. Furthermore, the IoT gateway support confidentiality when data is
transmitted over the Internet and priority of critical messages from devices over
other traffic such as Point-to-Point (P2P), File Transfer Protocol (FTP), social
networking applications and other bandwidth-consuming applications. The
typical IoT gateways for smart homes are illustrated in Figure 10.4. For the
utility companies, it is pricey to deploy and manage hundreds of gateways in
the area of home networking [40].

61
Figure 10.4 Typical IoT gateways for smart homes [40]
On the other hand, SDN provides a controller host for simple and scalable
management. IoT gateways are viewed as SDN enable switches and
programmed by the controller for routing, access control, secure tunnel
establishment between the IoT gateway and utility server, and prioritizing
critical traffic [40]. In other words, the SDN controller centralizes management
of each IoT gateway for smart homes shown in Figure 10.5.
Figure 10.5 SDN enabled IoT gateways for smart homes [40]

62
11. Conclusion
In order to deal the limitation of traditional networks such as optimization of
utilization and customized services, virtual networks are proposed to provide
integrated management interface in order to reduce complexity and enhance
network effectiveness via the pluralist model for multiple virtual networks.
Virtual networks enable different operating systems to share hardware
resources running on the same infrastructure with its own topology and routing
protocols. OpenFlow is proposed with an open standard architecture that
allows providing open protocols and programming flow tables in various virtual
switches and routers based on the SDN. By doing so, the SDN can provide
dynamic and adaptive management with the low cost but large bandwidth and
high throughput by centralizing control planes in a controller and separate the
data planes.
Furthermore, The SDN can modify the network behavior more effectively
based on user requirement and offers flexible network management on IoT.
With an OpenFlow-based virtual network, it enables the Internet access control
and user management and monitoring according to capacity for each user or
device.
For instance, the IoT in the smart home acts as a gateway to connect each of
smart home sensor-embedded devices and transfer collected data to external
network. If the network policy changes, it will become high-priced to
reconfigure each IoT gateway among thousands of hundreds smart homes for
enterprises such as utility companies. Via SDN, the IoT gateways are viewed
as SDN enable switches and programmed by the controller for routing, access
control, secure tunnel establishment between the IoT gateway and the data
center.
The SDN allows administrators to have a global view of the network and
provides a distinct advantage that facilitates the implementation of the IoT
smart city in the near future.

63
12. References
[1] O. C. M. B. Duarte and G. Pujolle, Virtual Networks: Pluralistic
Approach for the Next Generation of Internet. Great Britain: Wiley, 2013.
[2] G. J. Popek and R. P. Goldberg, "Formal Requirements for Virtualizable
Third Generation Architectures," Communications of the ACM, vol. 17,
pp. 412-421, 1974.
[3] K. Adams and O. Agesen, "A Comparison of Software and Hardware
Techniques for x86 Virtualization," OPERATING SYSTEMS REVIEW,
vol. 40, pp. 2-13, 2006.
[4] N. Egi, A. Greenhalgh, M. Handley, M. Hoerdt, L. Mathy, and T.
Schooley, "Evaluating Xen for Router Virtualization," 2007 16th
International Conference on Computer Communications & Networks, p.
1256, 2007.
[5] T. Anderson, L. Peterson, S. Shenker, and J. Turner, "Overcoming the
internet impasse through virtualization," Computer, p. 34, 2005.
[6] N. C. Fernandes, M. D. D. Moreira, I. M. Moraes, L. H. G. Ferraz, R. S.
Couto, H. E. T. Carvalho, et al., "Virtual networks: isolation,
performance, and trends," Annales des Telecommunications, p. 339,
2011.
[7] D. F. Macedo, Z. Movahedi, J. Rubio Loyola, J. A. Astorga Rivera, G.
Koumoutsos, and G. Pujolle, "The AutoI approach for the orchestration
of autonomic networks," 2012.
[8] J. V. D. Merwe, J. L. Rexford, and Y. Wang, "Virtual router migration,"
2011.
[9] P. S. Pisa, N. C. Fernandes, H. E. T. Carvalho, M. D. D. Moreira, M. E.
M. Campista, L. H. M. K. Costa, et al., "OpenFlow and Xen-Based
Virtual Network Migration," 2010, pp. 170-181.
[10] R. d. S. Alves, M. E. M. Campista, S. H. M. K. Costa, and O. C. M. B.
Duarte, "Towards a pluralist internet using a virtual machine server for
network customization," presented at the Proceedings of the Asian
Internet Engineeering Conference, Bangkok, Thailand, 2012.

64
[11] Y. Wang, E. Keller, B. Biskeborn, J. v. d. Merwe, and J. Rexford, "Virtual
routers on the move: live router migration as a network-management
primitive," SIGCOMM Comput. Commun. Rev., vol. 38, pp. 231-242,
2008.
[12] D. M. F. Mattos, N. C. Fernandes, V. T. da Costa, L. P. Cardoso, M. E.
M. Campista, L. H. M. K. Costa, et al., "OMNI: OpenFlow MaNagement
Infrastructure," 2011 International Conference on the Network of the
Future (NOF), p. 52, 2011.
[13] N. Gude, T. Koponen, J. Pettit, B. Pfaff, N. McKeown, and S. Shenker,
"NOX: towards an operating system for networks," SIGCOMM Comput.
Commun. Rev., vol. 38, pp. 105-110, 2008.
[14] R. B. Freitas, L. B. de Paula, E. Madeira, and F. L. Verdi, "Using virtual
topologies to manage inter-domain QoS in next-generation networks,"
International Journal of Network Management, vol. 20, pp. 111-128,
2010.
[15] A. Ranganathan and R. H. Campbell, "An infrastructure for context-
awareness based on first order logic," Personal & Ubiquitous Computing,
vol. 7, pp. 353-364, 2003.
[16] R. Sterrit and D. Bustard, "Towards an Autonomic Computing
Environment," 2003, pp. 694-698.
[17] M. Woolridge and M. J. Wooldridge, Introduction to Multiagent Systems:
John Wiley 2001.
[18] R. H. Bordini, Multi-agent programming. [electronic resource] :
languages, platforms and applications: Springer, 2009.
[19] S. Loke, Context-aware pervasive systems. [electronic resource] :
architectures for a new breed of applications: Boca Raton, FL :
Auerbach Publications, 2007.
[20] N. C. Fernandes and O. C. M. B. Duarte, "XNetMon: A Network Monitor
for Securing Virtual Networks," 2011 IEEE International Conference on
Communications (ICC), 2011.
[21] D. M. F. Mattos, L. H. G. Ferraz, L. H. M. K. Costa, and O. C. M. B.
Duarte, "Virtual Network Performance Evaluation for Future Internet
Architectures," Journal of Emerging Technologies in Web Intelligence,
vol. 4, pp. 304-314, 2012.

65
[22] N. Egi, A. Greenhalgh, M. Handley, M. Hoerdt, F. Huici, and L. Mathy,
"Fairness issues in software virtual routers," Applications, Technologies,
Architectures & Protocols for Computer Communication, p. 33, 2008.
[23] H. E. T. Carvalho and O. C. M. B. Duarte, "Elastic Allocation and
Automatic Migration Scheme for Virtual Machines," Journal of Emerging
Technologies in Web Intelligence, vol. 4, pp. 333-342, 2012.
[24] Y. Cheng, R. Farha, M. S. Kim, A. Leon-Garcia, and J. Won-Ki Hong, "A
generic architecture for autonomic service and network management,"
Computer Communications, vol. 29, pp. 3691-3709, 2006.
[25] C. C. Marquezan, L. Z. Granville, G. Nunzi, and M. Brunner, "Distributed
autonomic resource management for network virtualization," Network
Operations & Management Symposium (NOMS), 2010 IEEE, p. 463,
2010.
[26] I. Fajjari, M. Ayari, and G. Pujolle, "VN-SLA: A Virtual Network
Specification Schema for Virtual Network Provisioning," Ninth
International Conference on Networks (ICN), p. 337, 2010.
[27] H. Derbel, N. Agoulmine, and M. Salaün, "ANEMA: Autonomic network
management architecture to support self-configuration and self-
optimization in IP networks," Computer Networks, vol. 53, pp. 418-430,
2009.
[28] M. A. Soares and E. R. M. Madeira, "A multi-agent architecture for
autonomic management of virtual networks," 2012 IEEE Network
Operations & Management Symposium, p. 1183, 2012.
[29] J. Kodama, T. Hamagami, H. Shinji, T. Tanabe, T. Funabashi, and H.
Hirata, "Multi-agent-based autonomous power distribution network
restoration using contract net protocol," Electrical Engineering in Japan,
vol. 166, pp. 56-63, 2009.
[30] F. Silveira and C. Diot, "URCA: Pulling out Anomalies by their Root
Causes," IEEE, p. 1, 2010.
[31] D. Brauckhoff, K. Salamatian, and M. May, "A Signal Processing View
on Packet Sampling and Anomaly Detection," IEEE, p. 1, 2010.
[32] S. Ali, I. U. Haq, S. Rizvi, N. Rasheed, U. Sarfraz, S. A. Khayam, et al.,
"On mitigating sampling-induced accuracy loss in traffic anomaly

66
detection systems," SIGCOMM Comput. Commun. Rev., vol. 40, pp. 4-
16, 2010.
[33] P. Wang, R. Valerdi, S. Zhou, and L. Li, "Introduction: Advances in IoT
research and applications," in Information Systems Frontiers vol. 17, ed,
2015, pp. 239-241.
[34] M. Casado, N. Foster, and A. Guha, "Abstractions for Software- Defined
Networks," Communications of the ACM, vol. 57, pp. 86-95, 2014.
[35] H. Farhady, H. Lee, and A. Nakao, "Software-Defined Networking: A
survey," Computer Networks, vol. 81, pp. 79-95, 2015.
[36] T. Suyama, Y. Kishino, and F. Naya, "Abstracting IoT devices using
virtual machine for wireless sensor nodes," in Internet of Things (WF-
IoT), 2014 IEEE World Forum on, 2014, pp. 367-368.
[37] Á. L. Valdivieso Caraguay, A. B. Peral, L. I. Barona López, and L. J.
García Villalba, "SDN: Evolution and Opportunities in the Development
IoT Applications," International Journal of Distributed Sensor Networks,
pp. 1-10, 2014.
[38] K. Kirkpatrick, "Software-Defined Networking," Communications of the
ACM, vol. 56, pp. 16-19, 2013.
[39] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, "Internet of Things
(IoT): A vision, architectural elements, and future directions," Future
Generation Computer Systems, vol. 29, pp. 1645-1660, 2013.
[40] V. R. Tadinada, "Software Defined Networking: Redefining the Future of
Internet in IoT and Cloud Era," in Future Internet of Things and Cloud
(FiCloud), 2014 International Conference on, 2014, pp. 296-301.

Virtual Network based on SDN and IoT

More Related Content

What's hot (18)

Similar to Virtual Network based on SDN and IoT (20)

Virtual Network based on SDN and IoT