Network Virtualization Using Openflow Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Advancement in Virtualization and cloud computing have completely changed the IT world, providing more scalability and on-demand features. However, in parallel to this flexible world of Cloud computing, we have to manage networks which are often more static, have more physical constraints and require manual interventions. The primary issue is that traditional networking methods might slow-down the whole infrastructure hindering the cloud deployment. Industry needs new techniques that are scalable and provide automated approach to the next generation network management. Network Virtualization is a flexible and software driven network and IP management services, making it easier to manage the existing networks and can be used by both administrators and users alike. It also provides users with the freedom of self-service over their network configuration. Once a Virtual network is deployed it becomes extremely difficult to maintain the integrity of Network Virtualization requirements. Hence it is vital for the Virtual Network controller to have the knowledge of all the devices in a network in real time. Our goal for the project is to develop an application that will run on top Floodlight OpenFlow controller and it will use OpenFlow technology instead of any discovery protocol. It will monitor all incoming requests and keep account of all the devices connected to the virtual network and ensures that the integrity of virtual network is maintained by forwarding packets with a given profile to the network virtualization controller for further analysis.

Table of Contents

Chapter 1 Introduction ………………………………………………………….……..… 4

1.1 Project goals and objectives

1.2 Problem and motivation

1.3 Project application and impact

1.4 Project results and deliverables

1.5 Market research

1.6 Project report structure

Chapter 2 Project Background and Related Work ………………………………. 8

2.1 Background and used technologies ………………………………………… 8

2.2 State-of-the-art technologies…………………………………………………. 12

2.3 Literature survey ……………………………………………………………….. 12

Chapter 3 Project Plan and Schedule………………………………………………….. 14

3.1 Project team and tasks ………………………………………………….. 14

3.2 Project milestone schedule and detailed schedule ………………………. 14

Chapter 4 Software System Requirements and Analysis ………………………. 19

4.1 Domain and Business Requirements

4.2 Customer-oriented requirements

4.3 Software system function requirements

4.4 Software system behavior requirements

4.5 Performance and non-function requirements

4.6 Context and interface requirements

4.7 Technology and resource requirements

Chapter 5 Preliminary Software System Design

5.1 Software system architecture design

5.2 System data and database design

5.3 System interface and connectivity design

5.4 System user interface design

5.5 System component API and logic design

5.6 System design problems, solutions, and patterns

Chapter 6 Used Tools and Standards

6.1. Used Tools

6.2. Adopted Standards

Chapter 7 Testing and Experiment Plan

7.1 Testing and Experiment Scope

7.2 Testing and Experiment Approaches

References……………………………….……………………………………………………… 23

Chapter 1 Introduction

1.1 Project goals and Objectives

In last two decades, the idea of network virtualization has gathered quite a bit of attention in the area on how to improve the new generation networking model that can take over the existing Internet. Network architects who still believe in networking designs see network virtualization as an instrument to evaluate fresh architectures, whereas others view virtualization as a key attribute of the new generation architecture.

In order to overcome the limitation of managing virtual networks, a new Network Monitoring Tool is described which runs on top of a Virtual network controller using OpenFlow technology. It will increase the awareness regarding the properties and state of the network in order to bridge the gap between high-level management goals and the con¬guration that achieves them. In this respect, we consider an infrastructure that manages both information ¬‚ow and processing within the network as an important stepping-stone towards this objective. The goal of our project is:

Study the basic architecture of Virtual Network Controller.

Identify the security issues related to monitoring Virtual Network.

Propose a software development approach for the application that will perform device discovery using OpenFlow.

Validating the proposed application by creating the prototype first.

1.2 Problem and Motivation

In last two decades, the idea of network virtualization has gathered quite a bit of attention in the area on how to improve the new generation networking model that can take over the existing Internet. Network architects who still believe in networking designs see network virtualization as an instrument to evaluate fresh architectures, whereas others view virtualization as a key attribute of the new generation architecture.

There are five requirements that characterize the infrastructure in network virtualization. And they are:

(1) Abstraction

All types of available resources at physical layer such as link, computational or storage are thoroughly abstracted and named in order to be manipulated via well-defined and extendable interfaces and are allocated in a way to create or modify a slice.

(2) Isolation

Resources that are used in creating a slice are kept separated from those that are used to create other slices so that they may not obstruct each other in order to maintain performance, security, and that any slice may not create disruptions to the entire network.

(3) Elasticity

Resources for creating a slice are properly arranged, reclaimed and released when there is a demand so that operators can maximize the space for multiple slices and optimize the use of resources both spatially and temporarily. It also allows immediate resource consumption as well as non-stop usage of resources.

Figure 1. Network Virtualization Framework

(4) Programmability

Resources used in building a slice may be programmed for creating, experimenting and deploying with the new communication protocols for the innovative data distribution and to facilitate efficient data processing that can be enabled inside a slice.

(5) Authentication, Authorization, and Accounting

Utilization of resources to create a slice need to be authenticated and authorized in order to achieve safe and protected operations of slices averting the abuse of resources and attacks on them. It is important to account for the allocation of resources in the network so that the reliability of resources may be monitored and examined, also and the usage of the resources may be enhanced.

Once a Virtual network is deployed it becomes extremely difficult to maintain the integrity of the above five Network Virtualization requirements. Hence it is vital for the Virtual Network controller to have the knowledge of all the devices in a network in real time. There are many discovery protocols like LLDP, CDP, NDP and etc. But none of them is capable to manage and perform network discovery in a Virtual Network that is running using OpenFlow. Hence our goal for the project is to develop an application that will run on top network virtualization controller and it will use OpenFlow technology instead of any discovery protocol. It will monitor all incoming requests and keep account of all the devices connected to the virtual network and ensures that the integrity of virtual network is maintained by forwarding packets with a given profile to the network virtualization controller for further analysis.

1.3 Project application and impact

The Virtual Network monitor we have planned to design will be able to collect data from the virtual environments in a dynamic and adaptable way. It will be able collect information about CPU, memory, and network usage for each of the device in a virtual network, even though they can be created, executed, and shutdown at run-time. This is important as each device represents a virtual resource in a virtual network. With a business point of view this will broaden our perspective on how we look at virtual networks. The major benefit of our application is that it will ease the managing of virtual networks by a greater extent. Our application can be a role model for new college graduates trying to come up with some new application on the similar lines.

1.4 Project results and deliverables

Following are the expected project deliverables:

Project Proposal - This document gives the specific objective and motivation behind the project. It describes an estimated cost and schedule for completion of the project. It ensures the customer that they will not lose their investments.

Project Report - Project report gives a detail study of the software requirement analysis, software design, tools, and testing plan.

Project Journal - This document maintains a record of all the minutes of the project meetings and the milestones reached in the project's lifecycle.

Source code - The code which contains the technical and working logic behind the project.

Test Methodologies - The document will contain all the testing methodologies and a tutorial to repeat the test again if the issue of quality ever comes up.

Setup Document - The document will consist of a manual with instruction on how to install the executable on customer's system.

User Manual - The most important document that comes with every product. It will consist of all the details on how to setup the environment and instructions to use our application the intended manner.

Chapter 4 Software System Requirements and Analysis

4.1 Domain and business requirements

Domain Requirement ID

Domain Feature


Switch shall follow OpenFlow specifications.


Linux based Server with moderate configurations dedicated for OpenFlow controller.


Shall follow Computer Society and ACM Approve Software Engineering code of ethics.


OpenFlow switch shall have a flow table and shall perform packet lookup and forwarding.


OpenFlow switch shall form a secure channel to an external controller.

Figure 1. Domain Requirements

Business Requirement ID

Business Feature


Real time product development shall be optimized according to the market needs.


Will meet the ISO requirements and no more than what is required.


Testing in the early phases of the software development life cycle shall be done to lower the future maintenance cost.


Regression testing before product launch.

Figure 1. Business Requirements

The following represents the domain class and activity diagram of the systems.

Figure 3: Domain Class and Activity Diagram

The discovery application can be broken down into the following:

Figure 3: Device Discovery Flowchart

4.2 Customer-Oriented requirements

The Customer-Oriented requirements are as follows:

Customer Requirements



Target users of the application will be network administrators who will be using OpenFlow technology.


Application will be used on daily basis.


Knowledge of OpenFlow technology, switches and controller is a must.


No age limit, and required knowledge about the technology to operate is situational.

Figure 3: Customer-Oriented Requirements

Following is the use case diagram for the system:

Figure 3: Use-case Diagram

Use Cases



User visualizes statistics and information about a switch in the OpenFlow network.


User adds a new flow to a flow table of one switch.


User removes a flow from a flow table of one switch.


User visualizes statistics and information about a flow over the network.


User visualizes statistics and information about a flow and decides to migrate it.


Agent monitors the packet loss rate, and migrate the flow when the rate reaches the threshold.

Figure 3: Use-cases

4.3 System Function Requirements

The main system function requirements of OpenFlow based network discovery application are:

Function Requirements



Visualize of network statistics.


Add new flows on an OpenFlow netowork on demand.


Remove flows on an OpenFlow network on demand.


Migrate flows on an OpenFlow network.


Monitor flows and to take actions on a scenario of packet losses.


Manage a OpenFlow network.

Figure 3: System Function requirements

4.4 Performance and Non-Function Requirements

The Performance and Non-Function Requirements of the systems are:





Must offer low network control message overload.


Must send minimum number of control messages to switches, in order to reduce the control traffic over the network.


The web interface must be responsive, thus as one action takes place into the network, it must be reflected into the web interface as quickly as possible, being the same valid to the agent perspective.


A request for a web service should be answered within a few seconds.


If an action taken by the administrator delays more than a few seconds, it may be already ineffective.

Figure 3: System Performance requirements

4.5 System Behavior Requirements

Chapter 5 Preliminary Software Design

5.1 Software System Architecture Design

A management system for the upcoming Internet needs a monitoring system that can gather all the important data in a very effective way. The monitoring system required to have a very small runtime mark and not be interfering, so as not to badly affect the network performance itself or the running applications. To achieve this objective we proposed an application that will run on top of OpenFlow controller.

The main components of a controller-based Openflow network are:

Openflow enabled switches

Server(s) running the controller process

Database containing the network view, a «map» of the entire topology of the network.

The Openflow switch, consists of a flow table containing flow entries, used to perform packet lookup and forwarding and a secure channel to the controller, through which Openflow messages are exchanged between the switch and the controller. By maintaining a flow table the switch is able to make forwarding decisions for incoming packets by a simple lookup on its flow table entries. Openflow switches perform an exact match check on specific fields of the incoming packets. For every incoming packet, the switch goes through its flow-table to find a matching entry. If such entry exists, the switch then forwards the packet based on the action associated with this particular flow entry.

Every flow entry in the flow-table contains [13]:

header fields to match against packets : These fields are a ten-tuple that identifies the flow.

Figure 4. Fields used by OpenFlow to match packets against flow entries

counters to update for matching packet : These counters are used for statistics purposes, in order to keep track of the number of packets and bytes for each flow and the time that has elapsed since the flow initiation.

actions to apply to matching packets : The action specifies the way in which the packets of a flow will be processed. An action can be one of the following: 1) forward the packet to a given port or ports, after optionally rewriting some header fields, 2) drop the packet 3) forward the packet to the controller.

The controller is a core, central entity, gathering the control plane functionality of the Openflow

network. Currently there are several controller implementations available. However for our project we will be using Apache licensed Floodlight controller, which is an open-source Openflow controller, therefore this report will be mostly focused around its implementation.

Figure 4. Applications running on top of Floodlight OpenFlow Controller

The above figure describes the basic architecture of Floodlight OpenFlow controller which is similar to other OpenFlow controllers in the market. We prefer floodlight controller for our project development since its open-sourced and is very well documented.

Figure 4. Floodlight Implementation Overview

Floodlight is not just an OpenFlow controller.  Floodlight is an OpenFlow controller (the "Floodlight Controller") AND a collection of applications built on top the Floodlight Controller.

The Floodlight Controller realizes a set of common functionalities to control and inquire an OpenFlow network, while applications on top of it realize different features to solve different user needs over the network.  The figures above below show the relationship among the Floodlight Controller, the applications built as Java modules compiled with Floodlight, and the applications built over the Floodlight REST API.   

5.2 System Data and Database Design

OpenFlow Virtual Network Database

The OpenFlow Virtual Network database is a standard MySQL database that contains two tables: the OpenFlow Virtual Network and the Properties table. The tables format is shown below:

Figure 4. OpenFlow Virtual Network Entry table

Figure 4. Properties table

The OVNEntry table consists of the fields OVNname and OVNid. The OVNname field serves as a user-friendly identifier for the OVN. The OVNid field is a unique identifier for the OVN and is used as an index field, that is to provide a mapping between OVN entries in the OVNEntry table and their respective properties in the Properties table. The Properties table consists of the OVNid, the ConnectedPoints field which specifies which access points have been enabled for a specific OVN, as well as the 10-tuple fields which are used to describe the kind of traffic that belongs to a specific OVN.

The free software phpMyAdmin written in PHP has been used to handle the administration of the OVN database. PhpMyAdmin supports the majority of operations with MySQL and provides an easy to use web interface to manage and administer a MySQL database.

OpenFlow Virtual Network Database Handlers

The administrator entity is responsible for maintaining, editing and accessing the OVN database. Our administrator entity is written in Python. In order to extend its capabilities to support database operations, the DB-API Python module MySQLdb [37] was used, which provides a database application programming interface (API).

There are two classes for handling the OVN database, the DBHandler and the OVNdbHandler

class. The primitive class DBHandler provides basic database operations, including generic methods such as connect, disconnect, issue a query and access the results of a query. The OVNdbHandler extends the class DBHandler with the custom methods that make up the administrator API. The administrator creates a reference to an OVNdbHandler object in order to be able to access its functions both for editing and accessing the OVN database.

OpenFlow Virtual Network Lookup function

This is one of the most essential functions of the administrator entity. Through this function, the administrator matches a packet based on its ten-tuple values against all possible OVN entries in the OVN database. When a packet enters the administrtor entity the administrator checks the Access Point that the packet was received from. It first queries the OVN database to get the OVN entries for which this Access Point has been enabled. If no such OVN exists the match is unsuccessful as there is no OVN entry corresponding to this Access Point. The administrator then sends an OVN_MISS message to the OVN interface entity. In the case that there is one or more OVN entries with this Access Point enabled, these entries are further checked in order to determine which of those have a description that matches the incoming packet.

The fields of the packet are checked one by one against all the fields that have been set for each OVN entry. If all fields whose values have been set for a specific OVN entry match the respective field values of the packet, a successful match has been made. The next step is to check which Access Points have been enabled for the matching OVN. Unless a unique destination Access Point can be determined through some other way, the packet will have to be sent to all Access Points enabled for the matching OVN except for the ingress access point. The lookup function returns all these possible Access Points to the administrator which then issues path finding requests for each of these access points to the pathfinder entity.

5.3 System Interface and Connectivity Design

The system interface consists of a layered architecture to facilitate the development of new functions. A layered model decouples changes in different modules, breaks up a complex problem into smaller manageable pieces, allows the abstraction of implementation details, and allows that different upper layers share the same lower layer. Our software architecture decisions allow that many different user interfaces are developed to control the network without requiring changes in the control module. Firstly, in order to achieve the architecture goals, two basic modules were developed: the network control based on NOX applications and the web interface server. After, we developed a third module which also accesses the network control using the same web service provided to the web interface server. This third module accomplishes the autonomic network control using an agent platform. This design pattern allows us to reuse the proven techniques is order to meet the technical requirements related to system design. The following is the system interface showing the connectivity between different modules.

Figure 4. System Interface

There are some software interfaces, among which the most important is the one between the OpenFlow controller applications, being the OF controller this interface provider. Another software interface is between the OpenFlow controller and the web interface provider, which is a web service-based interface. The functions are called as URL requests and the function returns are XML messages. The agents also access this web interface.

5.4 System User Interface

The user interface is a web-based. The main goal of the web interface is to provide a friendly and intuitive mans for accessing switch information and using management tools. The web interface provides a fast and friendly interface for the network administrator to the set of NOX applications that were developed. The web interface for network control was designed as a client of the Web Server application provided by NOX. The application that implements the web interface runs both a client and an HTTP server.

The data flow work as follows. Upon entering the site provided by the web interface, the network administrator can select any of the available functionalities. When the administrator accesses an option that depends on the network data, such as the flow statistics, the application performs an HTTP request to the web server in NOX, which, in turn, handles the request and returns an XML. The XML is received by the web interface application, which processes the received data to generate a suitable view in a web page.

As the administrator interacts with the page and performs control functions on the network, these commands are converted into URLs that are sent to the network controller. The controller dispatches the URLs for the relevant application and returns the confirmation or the error message to the web interface.

Figure 4. Web User Interface

The web user interface figure is a prototype of how the web user interface giving the topology might look like.

5.5 System Component API and Logic design

Over the last year, there has been some discussion within the OpenFlow and broader SDN community about designing and standardizing a controller API in addition to the switch interface.

To be honest, standardizing a controller API sounds like a poor idea. The controller is software, not a protocol. To our knowledge there are 9 controllers in the wild today, and more than half of them are open source. If the community wants an open software platform, it should divert resources from arguing over standards to building open source software.

A number of controllers provide a high-level interface to OpenFlow (specifically) and some infrastructure for hosting one or more control "applications". These are general purpose platforms meant for extension. However, the interface is built around the OpenFlow protocol itself, meaning the interface is a thin wrapper around each message, without offering higher-level abstractions. Therefore, as the protocol changes (e.g., a new message is added), the API necessarily reflects this change.

In an Openlow Controller, the physical network is represented as a graph for the control application. Elements in the graph may represent physical objects such as switches, or their subparts, such as physical ports, or lookup tables.  And it may contain logical entities such as logical ports, tunnels, BFD configuration, etc.

Control applications operate on the graph to find elements of interest and read and write to them. They can register for notifications about state changes in the elements, and they can even extend the existing elements to hold network state specific to a particular control logic.

5.6 Software Design Problems, Solutions, and Patterns

Since we will be using Floodlight OpenFlow controller and taking into consideration hardware limitations, our application will be limited to run over OpenFlow-enabled systems, such as OpenFlow switches or personal computers running OpenFlow switching software. It is important to remark that Floodlight was designed to work with OpenFlow 1.0. Older versions of OpenFlow software have different data structures for exchanging information with controller, thus needing another version of the OpenFlow controller.

Figure 5. Probes taking information from the data source

Another issue is to get real time information about the devices, rather than analyzing the flow entries first. To achieve this a probing technique can also be employed that will take all the relevant information from the device and forward it to the proposed Application on top of floodlight OpenFlow Controller.

Figure 6. Hypervisor adding or deleting the probe

However since we are still in designing stage it is unknown which approach will be more effective and less resource consuming till we do an in depth analysis of the technologies proposed.

Design Patterns

The design patterns allow the reuse of proven techniques in order to meet technical requirements related to system design. For our system, we analyzed some design patterns and selected those that could be satisfactorily applied.

1. Singleton

The Singleton design pattern ensures that a class will have only one instance and will provide a global access point to the object of that class. In the OMNI tool, this design pattern is used in development of NOX applications. Each application is a class derived from a standard class that is instantiated at the time the application is started. Each application has access to other applications through a single point, provided by the NOX platform itself. This pattern is also used in the development of the web interface.

2. Facade

The Facade design pattern provides a unified interface to a set of interfaces in a given subsystem. The Facade defines standard interfaces in a higher level than the subsystems to ease the development of upper layers. In OMNI, this design pattern was adopted in the Web Server application that runs on NOX. Thus, the web interface and the agents can access the control functions of the network through a unified interface. This design pattern allows you to maintain the cohesion of the subsystems, while it also decouples the control interface, such as the web interface and the agents, of the control functions, implemented as NOX applications.