Managing Network Virtualization Using Openflow

Published Date: 02 Nov 2017

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 ………………………………………………………….……...... 7

1.1 Project goals and objectives ....................................................................... 7

1.2 Problem and motivation .............................................................................. 8

1.3 Project application and impact .................................................................... 10

1.4 Project results and deliverables .................................................................. 11

1.5 Market research .......................................................................................... 12

1.6 Project report structure ................................................................................ 12

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

2.1 Background and used technologies …………………………………………. 13

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

2.3 Literature survey ……………………………………………………………….. 16

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

3.1 Project tasks and Schedule …………………………………………………... 17

3.2 Project resources, budget, and cost analysis ………………………. ........... 18

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

4.1 Domain and Business Requirements .......................................................... 21

4.2 Customer-oriented requirements ................................................................ 23

4.3 Software system function requirements ...................................................... 25

4.4 Performance and non-function requirements .............................................. 26

4.5 Technology and resource requirements ...................................................... 26

Chapter 5 Preliminary Software System Design ...................................................... 28

5.1 Software system architecture design ......................................................... 28

5.2 System data and database design .............................................................. 32

5.3 System interface and connectivity design ................................................... 34

5.4 System user interface design ...................................................................... 36

5.5 System component API and logic design .................................................... 37

5.6 Software design problems, solutions, and patterns .................................... 37

Chapter 6 Used Tools and Standards ....................................................................... 40

6.1. Used Tools .................................................................................................. 40

6.2. Adopted Standards ..................................................................................... 44

Chapter 7 Testing and Experiment Plan ................................................................... 45

7.1 Testing and Experiment Scope ................................................................... 45

7.2 Testing and Experiment Approaches .......................................................... 45

Chapter 8 Project Summary ....................................................................................... 47

References ……………………………….……………………………………………………... 48

List of Figures

Figure 1 Network Virtualization Framework ……………………….............. ........... 9

Figure 2 OpenStack Cloud Operating System ...................................................... 16

Figure 3A Project Schedule for Project Part A ........................................................ 17

Figure 3B Project Schedule for Project Part B ........................................................ 18

Figure 4 Domain Class and Activity Diagram ........................................................ 22

Figure 5 Device Discovery Flowchart .................................................................... 23

Figure 6 Use Case Diagram ..................................................................................... 24

Figure 7 Fields in OpenFlow to match packet against flow entries .................... 29

Figure 8 Applications running on top of Floodlight Controller ........................... 30

Figure 9 Floodlight implementation Overview ...................................................... 31

Figure 10 OpenFlow Virtual Network Entry Table ................................................... 32

Figure 11 Properties table ......................................................................................... 32

Figure 12 System Interface ....................................................................................... 35

Figure 13 Web User Interface ................................................................................... 36

Figure 14 Probes taking information from Data Source ........................................ 38

Figure 15 Hypervisor adding or deleting the probe ................................................ 38

Figure 16 OpenFlow Tutorial Flow ............................................................................ 41

List of Tables

Table 1 Domain Requirements ....................………………………........................ 21

Table 2 Business Requirements ........................................................................... 21

Table 3 Customer-Oriented Requirements .......................................................... 23

Table 4 Use Cases .................................................................................................. 24

Table 5 System Function Requirements .............................................................. 25

Table 6 System Performance Requirements........................................................ 26

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 configuration that achieves them. In this respect, we consider an infrastructure that manages both information flow 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

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.

(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.

Figure 1. Network Virtualization Framework

(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.

1.5 Market Research

In our market research, we focused our energies in finding more about the existing network discovery protocols. We found quite a lot of existing protocols which help in network discovery. NDP is Network Discovery protocol which is primarily used with IPv6. It works at the Internet layer and helps in discovery and auto configuration of other nodes. It also maintains reachable information and finds DNS server and available routers. Another important protocol that is used for Network discovery is LLDP - Link Layer Discovery Protocol (LLDP). It is a link layer protocol and is used by various network devices to advertise their identity, neighbors and capabilities. There are various other protocols that like LLTD - Link Layer Topology Discovery, CDP - Cisco Discovery Protocol etc. However these protocols become obsolete when we use OpenFlow switches or software switches that use OpenFlow in software defined network or virtual network. Also our research suggested that there is no method available yet that can analyze flow information in OpenFlow networks to perform device and network discovery.

1.6. Project Report and Structure

Our report starts with the Introduction which explains the project goals and objective, the motivation and what is expected out it. In the second chapter we discuss the background and th work that has been already done in this field. Next we specify our project plan and Schedule. In the next two chapters of the report we try our best to specify and analyze the system requirements and the software system design. After that we would list out the tools and standards that we expect to use. Finally we would mark our testing and experimentation approach.

2. Project background and related work

2.1. Background and used technologies

Network Virtualization Technologies have been around for quite in different forms. Network Virtualization divides network services and control of the operations from the network hardware. In network virtualization the networks are designed and programmed in such a way that they deliver and behave exactly like a physical network but they have the operative flexibility that virtualization offers. This is similar to server hypervisors that separate the amount of work from the core physical server.  The physical network still performs most of the physical work like, forwarding packets, while state of operations and state of the network are maintained and controlled in the virtual space.

There are seven key properties of network virtualization:

No dependence on networking hardware.

Workloads of virtual and physical networks are supported and the virtual space is available for physical network service's exact reproduction.

Compute model's operation model is followed.

Support for all hypervisor platforms.

Control plane, physical network & virtual network are completely delimited to each other.

Improvement in the performance of Scalability and Cloud.

Control and Network provisioning is easily managed by an open and programmatic approach

Technologies like VLAN and VPN have provided Network Virtualization capabilities and helps scale and manage the network much better.

VLAN - Virtual Local Area Network is a logical segmentation of Local Area Networks into different broadcast domains. It helps improves the security as it divides the sections of networks which cannot talk to each other.

VPN- It gives connectivity to users, from a remote location, to the private corporate network of an organization. It is implemented using tunneling to lower cost and have improve security.

Other notable technologies related to Network Virtualization are: -

VDC - Virtual Device Context - This is the logical segmentation of 1 physical switch to up to 4 virtual switches. Between the physical switch and the virtual switches there exists an abstraction layer. Also there is an administrative control layer, the primary purpose of that is to have the virtual switches share the hardware resources.

VPC - Virtual Port Channel is an Ethernet channel with bundled links that terminate to two different peer switches.

MPLS VPN - Multi Protocol Label Switching Virtual Private Network - This enables the use of the one physical infrastructure to transport many customers, while having a single isolated routing table for individual customer.

VRF - Virtual Routing and Forwarding - A single router manages various isolated instances of a routing table. Using VRF we can avoid using multiple devices and still have the segmentation of network paths.

2.2 State-of-the-art technologies

Nicira is the biggest name in the virtual network virtualization field right now. SDN data centers would need a complete overhaul of the how computing, networking and storage is handled. There are many issues in networking when we work on a distributed system and Nicira tries to solve that problem by defining distributed algorithm instead of managing the physical network using the traditional protocol.

Network Virtualization Platform (NVP) is the USP of Nicira. It is a collection of various components like the Controller cluster. Management software and RESTful APIs integrate various Cloud Management Systems (CMS). One can create a virtual network between the end hosts using NVP. It also helps in managing the network abstraction layer and all of this is independent of the underlying hardware. It works with a lot of software like VMWareESXi, Linux/KVM, Xen/ Xen Server and Microsoft’s HyperV.

Hundreds of virtual ports can be created using it.

No physical network restrictions (VLAN & MAC table scalability, VM mobility, multi-tenant isolation, overlapping IP addresses and more).

Network infrastructure can be programmatically controlled.

Supports and extends network security model.

Tenants can work in an isolated environment.

Accounting for granular usage is available.

Rapid services can be created by the provided APIs.

Integration and migration of physical to virtual can be done.

Broadcast and multicast network services are enabled.

2.3 Literature Survey

While studying and researching about our topic. We came across many technologies and others similar work that has been going on this field.

Openstack is one of the most closely associated technologies with the Network Virtualization and OpenFlow. OpenStack, just like OpenFlow is an opensource project which is being accomplished by the collaborative work of many experienced developers. This technology contains a series of interconnected projects which form the umbrella of projects defining the cloud infrastructure solution. It is commonly used for deployment of large scale public or private clouds. It leverages the support and resulting technology of the open source community globally. OpenStack is kind of a cloud OS which manages the pool of networking resources, storage and computing power. All of these are managed through a datacenter and accessed through a dashboard given to administrators.

http://www.openstack.org/themes/openstack/images/openstack-software-diagram.png

Figure 2.OpenStack Cloud Operating System

Chapter 3 Project Plan and Schedule

3.1 Project tasks and Schedule

Project tasks and Schedule for CMPE 295A and CMPE 295B are shown below with the help of Gantt chart:

C:\Users\Atinder\Desktop\Proposal\295A- gantt chart-updated.jpg

Figure 3A. Project Schedule for Project Part A

C:\Users\Atinder\Desktop\proposal b.jpg

Figure 3B. Project Schedule for Project Part B

3.2 Project Resources, Budget and Cost Analysis

In order to maximize our efficiency we need to utilize the amount of time and resources available very wisely. We have analyzed our project requirements and have planned our Project tasks, Schedule, Budget and required resources in advance. For the cost analysis we have considered labor cost on hourly basis, equipment and software cost. We have also maintained a small budget for miscellaneous expenditure.

Cost of Equipment

Equipment

#

Cost / Item

Semester 1

Semester 2

Laptops

4

$ 700

$2800

-

Desktops

2

$1000

$2000

-

Network Switches

3

$450

$900

$450

Network Routers

4

$100

$200

$200

Total Cost

$6550

Labor Resources

Resource Type

Name

Hourly Rate

Number of Hours

Total

Advisor

Dr. Chao Li-Tarng

$ 50/hr

70 Hours

$ 5000

Developer

Atinder pal Sohal

$ 30/hr

704 Hours

$ 21120

Developer

Jasdeep Singh

$ 35/hr

650 Hours

$ 22750

However this is a master’s project and we will be taking only labor hours in consideration instead of labor cost. Therefore the total number of labor hours comes out to be 2052 Hours. We have estimated about $2000 to be the miscellaneous cost of software, stationary, printouts and travel expenses.

Hence the total estimated cost to complete the project is:

Equipment cost + miscellaneous expenditure = $ 6550 + $ 2000

= $ 8550

The cost may increase according to the project needs and requirements.

Chapter 4 Software System Requirements and Analysis

4.1 Domain and business requirements

Domain Requirement ID

Domain Feature

DR_1

Switch shall follow OpenFlow specifications.

DR_2

Linux based Server with configurations that are dedicated for OpenFlow controller.

DR_3

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

DR_4

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

DR_5

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

Table 1. Domain Requirements

Business Requirement ID

Business Feature

BR_1

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

BR_2

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

BR_3

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

BR_4

Regression testing before product launch.

Table 2. Business Requirements

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

Figure 4. Domain Class and Activity Diagram

The discovery application can be broken down into the following:

Figure 5: Device Discovery Flowchart

4.2 Customer-Oriented requirements

The Customer-Oriented requirements are as follows:

Customer Requirements

Features

CR_1

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

CR_2

Application will be used on daily basis.

CR_3

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

CR_4

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

Table 3. Customer-Oriented Requirements

Following is the use case diagram for the system:

Figure 6. Use-case Diagram

Use Cases

Description

UC_1

Visualization of data and statistics of a switch in an OpenFlow network.

UC_2

Addition of a fresh flow in a flow table of one virtual switch.

UC_3

Flow removal from a flow table of one virtual switch.

UC_4

Visualization of data and statistics of a flow over the network.

UC_5

User visualizes data and statistics about a flow and decides to transfer it.

UC_6

User monitor the packet loss rate, and transfer the flow when the rate reaches the maximum point.

Table 4. Use-cases

4.3 System Function Requirements

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

Function Requirements

Description

FR_1

Visualization of network information.

FR_2

Addition of new flows in an OpenFlow netowork on demand.

FR_3

Removal of flows in an OpenFlow network on demand.

FR_4

Migration of flows in an OpenFlow network.

FR_5

Monitoring flows and to take action if there is a packet losses.

FR_6

Management of OpenFlow network.

Table 5. System Function requirements

4.4 Performance and Non-Function Requirements

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

Performance

Requirements

Description

PR_1

Shall offer reduced network control message overload.

PR_2

Switches shall recieve smallest amount of control messages to lower the control traffic over the network.

PR_3

If an action takes place in a network, it shall reflect into the web interface as fast as possible.

PR_4

A call for a web service shall be answered in no time.

PR_5

In case if administrator's commands are not delivered, it means that they are invalid.

Table 6. System Performance requirements

4.5 Technology and Resource Requirements

Hardware Requirements

Laptops

Desktops

Network Switches

Network Routers

LAN Cables

Software Requirements

Virtual Box or VMware Workstation

Floodlight OpenFlow Controller

Windows 7

Ubuntu 12.04

Cent OS

Mininet Network Simulator

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 three most important tools in an OpenFlow Network are:

OpenFlow enabled Virtual or Hardware switches.

OpenFlow controller running on a Linux based server.

Database consisting of network topology.

The OpenFlow switch, contains a flow table with flow entries, which helps in performing a packet check and forwarding via protected channel to the OpenFlow controller, by which there is an exchange of OpenFlow messages between the controller and the switch. Keeping a flow table helps the switch to make decisions in advance and checking flow table entries before incoming packets. OpenFlow enabled switches achieve an precise match check on particular fields of the incoming packets. For every packet that is incoming, the switch checks its flow-table to look for a similar entry. If a similar entry is available, the switch will then forward the packet according to its specific flow entry.

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

Header Fields: Header fields are used in matching the packets. The flow is identified by the following fields.

Figure 7. Fields in OpenFlow to match packets against flow entries

Counters: Counters are used in updating the flow entry of matching packets. Counters are used in information purposes, they keep track of the amount of packets and size for every flow and the elapsed time after the flow is initialized.

Actions: The action determines the manner in which the packets of a flow will be handled. An action may be one of the following: a) packets getting forwarded to a given port or ports, after some header fields are rewritten optionally. b) packet getting dropped 3) packet getting forwarded to the controller.

The OpenFlow controller is a central entity, core, collecting the control plane functionality in an Openflow network. Today there are plenty of controller implementations exist. 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 8. 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 9. Floodlight Implementation Overview

Floodlight unlike any other OpenFlow controller, it is also a collection of applications that are built on top the Floodlight Controller.

The Floodlight Controller gives a set of general features to control and query an OpenFlow network, while the applications that are running on top of it fulfill different needs required by users.  The figure above show the connection between 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 10. OpenFlow Virtual Network Entry table

Figure 11. Properties table

The OpenFlow Virtual Network Entry table contains the fields OVNname and OVNid. The OVNname field is a user friendly label for the OpenFlow Virtual Network. The OVNid field is a unique label for the OpenFlow Virtual Network and it is only used in index field, that is to provide a mapping between OpenFlow Virtual Network entries in the OVNEntry table and their own features 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 OpenFlow Virtual Network

The free software phpMyAdmin written in PHP is used to control the administration of the OpenFlow Virtual Network database. PhpMyAdmin supports most of the operations with MySQL and provides an easy to use web interface to manage and control a MySQL database.

OpenFlow Virtual Network Database Handlers

The OpenFlow network controller is responsible for accessing, maintaining and editing the OpenFlow Virtual Network database. Our controller is written in Java. And in order to broaden its capabilities to support database operations, the DB-JAVA API module HSQLdb [37] was used, which gives a database application programming interface (API).

The two classes responsible for handing the OpenFlow Virtual Network Database are:

DBHandler

OVNdbHandler

Where DBHandler class is little primitive and only provides basic operation like establishing connection, or disconnecting, issuing a query and accessing the results of a query. On the other hand OVNdbHandler extends its functions and is considered as administrative API>

OpenFlow Virtual Network Lookup function

This is the most important functions of the OpenFlow controller. Via this function, the administrator can match a packet with all the possible OpenFlow Virtual Network entries in the database. When a packet enters the application the controller looks for the Access Point from where the packet was received. It first checks the OpenFlow Virtual Network database to get its entries for which the Access Point was enabled. If there is no match then there is not entry corresponding to the Access point exists. The application can then transmit an OVN_MISS message to the OpenFlow controller. If there are more than one incoming connections associated with a particular access point then there will be a thorough check with the OpenFlow Virtual Network entries.

The packet fields are verified one by one with all the fields that are set for each OpenFlow Virtual Network entry. If the values of all the fields that is set for a particular OpenFlow Virtual Network entry matches its field values of the packet, it means that a good match exists. The following step is to check weather the Access Points are enabled for the matching OpenFlow Virtual Network. Except a distinctive target Access Point can be figured out by some other way, the packet will forwarded to all the Access Points enabled for the matching OpenFlow Virtual Network other than the ingress access point. The lookup function returns all these possible Access Points to the user which then initiates a path finding requests for all of these access points to the pathfinder unit.

5.3 System Interface and Connectivity Design

The system interface is composed of a multilayered architecture that facilitate the creation of new functions. The layered model separate changes in different parts, splits up a difficult problem into lesser convenient parts, enables the retrieval of implementation particulars, and enables different upper layers to be divided into same lower layer. Our application will allow many different user interfaces to manage the network without requiring to perform changes in the control element. Firstly, in order to attain the architecture goals, two basic components were developed: the network control based on Floodlight application and the web interface server. After, we design a third component which will also access the network control via same web service provided to the web interface server. This third component accomplish the autonomous network control by means of an agent platform. This plan will enable us to recycle the verified techniques so we can meet the technical specifications related to system architecture. The following is the system interface showing the connectivity between different modules.

Figure 12. System Interface

The interface between the OpenFlow controller applications is the most important one since the OpenFlow controller itself is the interface provide. The second interface is the one between web interface provide and OpenFlow controller. This web interface provide is a web service-based interface. The functions are known as URL requests and the function that returns are called XML messages. The user agents may also access the web interface.

5.4 System User Interface

The user Interface planned will be a web based User Interface. The reason why we prefer web interface over others is that it offer an easy to use and spontaneous way for collecting switch information and managing the network. The web UI offers a quick and friendly interface for the system administrator to deploy the Floodlight applications. The web interface for the OpenFlow controller will be created as a client of the Web Server application that will be provided by Floodlight. The application implementing the web interface will be able to run a client and an HTTP server at the same time.

Figure 13. 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

There has been a lot of talk going around about designing and regulating the controller API and also the switch interface within the whole SDN community and in particular the OpenFlow community. However it might not be a good idea to standardize the controller as it’s not a protocol but a general software. Many of the controllers available today are open source and we should concentrate our energies to making open source software rather debating over building a standard. There are many controllers that give a high-level interface to OpenFlow. Some of the control "applications" can also be hosted on the provided infrastructure. These are usually platforms available for extension.

The interface acts as a packaging around each message however it does not provide any higher-level abstractions. So it's like the interface is made over the OpenFlow protocol. As a result, when the protocol changes, like a message is added), the API automatically reflects this change.

5.6 Software Design Problems, Solutions, and Patterns

Since we will be using Floodlight OpenFlow controller and taking into consideration our hardware boundaries, our application will be able to run only on top of systems that have OpenFlow enabled, such as OpenFlow switches or computer systems running OpenFlow switching software like OpenvSwitch. Now since Floodlight was designed recently in 2011 it can only work with the OpenFlow version 1.0 and later versions. Previous versions of OpenFlow software contain different data structures for exchanging information with controller, thus we can only use the newer versions of OpenFlow for our project.

Figure 14. 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 15. 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 let us re-employ the use of proven methodologies in order to reach the technical necessities associated with system design. For our project, we went through some design patterns and chosen those that could be properly employed.

1. Singleton

The Singleton design pattern make sure that a class while providing a global access point to the object of that class, will have only one instance. In our project, this design pattern might be used in designing our OpenFlow controller applications. Each application will be a class originating from a standard class that will be starting at the same time as application. Each application will have access to the other applications via single point, provided by the Controller platform itself. This approach can also be used to design web-user interface.

2. Facade

The Facade design pattern provides a combined interface that is a set of interfaces in a subsystem. To ease the development of upper layers, facade design pattern offer standard interfaces in a level above the subsystems. We might adopt this design pattern in our Server application that will run over OpenFlow controller. The web interface and the agents will be able to access the control functions via single interface. This type of pattern will allow us to maintain the unity of the subsystems.

Chapter 6 Used Tools and Standards

6.1 Used Tools

This section of Used Tools lists all the tools which we have or would be using in our project further down the line. Starting from the OS being used to the tools used for documentation and drawing various diagrams.

We have already mentioned some of the hardware and software requirements in the previous sections. The other basic requirements are Windows OS and Linux based Ubuntu OS; we have used 2 Desktop systems with a Windows XP and Ubuntu 10.04. There are Laptops also with Windows 7 and Windows 8.

Other general utility tools such as MS Office for various documentation, Smart Draw for making Gantt charts to show our project schedule, Photoshop and MS paint for making diagrams.

Also used Google Drive and Dropbox to share and work simultaneously on the documents

Other important tools for the project that are used

VMware Workstation

OpenFlow

Mininet

Open vSwitch

Floodlight VM

VMware Workstation - It is a hypervisor running on specifically on 64 bit machines. This gives capability to all the users to use their actual physical machine while running multiple VMs (Virtual Machines) on it. Every VM has its own OS which can be a Windows or any Linux based OS. Overall a VM is nothing more than a set of files in a folder in the base physical machine. Like .vmdk is the main disk file and .nvram stores the state of the virtual machine's BIOS. Also .vmsn is the snapshot state file, it stores the running state of the VM when a snapshot is taken.

Snapshot is saving the state of the VM at a particular time. This helps us recover the VM to its saved state, minimizing any work that needs to redone..

Support for creating a bridged network is also given in VMware Workstation; it uses the existing host network adapters. Workstation also has the option sharing the physical drive and devices like optical disc media and USB. One can also mount ISO image as a disc on the virtual optical drive.

OpenFlow is an open interface. It primarily helps in controlling the forwarding tables in various networking devices such as routers, switches and also access points. OpenFlow is a low level protocol over which developers can build high-level applications. For example, OpenFlow allows us to deploy secure default-off networks, wireless networks with smooth handoffs, scalable data center networks, host mobility, more energy-efficient networks and new wide-area networks.

Tutorial flow hw.png

Figure 16.OpenFlow Tutorial flow

Mininet helps create a dummy but a realistic looking virtual network which can run a real kernel, switch and application code. All of this is accomplished on one machine, be it a vm, on cloud or native. It can be implementing in no time using a single command.

Mininet is also useful for academic purposes and research & development. Owing to the ease of interaction with the network by the use of mininet api and/or cli, we can deploy it on real hardware while customizing and then sharing it.

One can do some useful experiments by combing OpenFlow and SDNs with Mininet. As it developed and supported actively and has a permissive Open Source license, therefore participation in code buildup and bug reporting and fixing, documentation is highly encouraged.

Mininet has the capability of creating scalable SDN, like OpenFlow using Linux processes on a single PC. This gives an ability to create simulated network environment quickly and to interact with, while sharing and customizing it as a SDN prototype and eventually we can run our application on top of real environment.

OpenvSwitch uses two interfaces to perform the function which it is built for and that is programmatic state distribution. First one is the OpenFlow which has many extensions. It manages fast path's forwarding behavior. Second one is JSON-RPC which is based on the config protocol which is used for configurations like NetFlow, tunnels and Quality of Service and are not very time critical.

There is also a possibility to use a centralized system which would help in managing network policies and help in Virtual Machine migration. Citrix's Distributed vSwitch Controller has been able to achieve this in an environment setup by XenServer.

In large cloud deployments which might includea setups many hundreds of server it is very often used a vSwitch. The prime purpose of it being management of automated VLAN, policy, and tunnel management. Many a times it is used as a simple OpenFlow switch in many deployments or it might be even used as a more a sophisticated programmatic switch to control hardware environments.

Performance of the Open vSwitch is incredibly great. It is very fast, even at times when compared with the native Linux bridge. When running in software, Open vSwitch uses flow-caching to make sure the speed is not effected even in case of very complex configurations. Tunneling implementations also perform very well as Open vSwictch is hight optimized for this purpose.

Floodlight Open SDN Controller can define as an enterprise-class, Apache-licensed, Java-based OpenFlow Controller.As floodlight is written in Java language, it runs on a JVM. It works with virtual-switches and physical switches that would talk to the the OpenFlow protocol. It is being developed as an open source project and developers from the open community are helping out.

There are some prerequisites before one can use the Floodlight. To simulate a network we would need to have Floodlight running and attach to an OpenFlow network like Mininet, a network simulation tool. Floodlight is not just an OpenFlow controller rather it's a collection of application built over controller plus the Floodlight Controller itself.

Openflow network is controlled and inquired by the set of common functionalities which setup by the Floodlight Controller. The applications on top of it work on solving different user requirements on the network.

6.2 Adopted Standards

The topic we have selected is fairly recent and at times it becomes difficult to find research papers on it. We have tried our best to stick to the official websites of the companies which are heavily invested into technologies like OpenFlow and are trying to make virtual network easier to implement using open source tools. We have also used text and video blogs of various people who are pioneers of this technology to understand and develop our own ideas.

The project involves various phases like analysis, designing, coding and finally testing. As we go along all these stages we will keep reviewing our adopted standards to make sure we stick to the expectations of a top-notch product. For detailed design and coding stages, we will decide our strategy and standard as we move to that stage.

We plan to use the Waterfall model for our project which conforms to the IEEE specification. We also would be doing testing at every phase of our project to make sure the final product is as flawless as possible. We are also using IEEE Requirement Description for our requirement document and IEEE design specification document standard for the documentation.

Chapter 7 Testing Plan and Experiment

7.1 Testing Plan and Experiment Scope

A considerable part of the project will be involved in creating a suitable test bed to perform tests and experiments on our proposed architecture before we deploy our application. Also there is a possibility that we might not have enough resources or time in had for a real deployment it will be better to consider a good small scale controlled test environment where we can control our topology on demand. So far our experiments with mininet network simulator has been quiet successful and we hope to use it in our future test plans.

Setting up a testbed will not be an easy task in itself, mostly because the whole technology that we will be using for our development is still in early experimental stages and every day something new and better comes up. In a way it is very rewarding since we are working on new and emerging technologies. Both OpenFlow and Floodlight are still under major development and improvement phases, and thus creating a suitable up to date testbed becomes even more challenging.

7.2 Testing Plan and Experiment Scope

We will need to perform both black box and white box test methods since both external and internal perspective of the project have to be validated. Following are the test methods that we will be using for validation:

Functional Testing: Functional testing is essentially a black box test that checks whether the functionality of the application confirms to the product specification. In this testing the various elements and features of the application are tested.

Unit Testing: Unit testing is a way to test single software units or components of a source code. A unit can be an entire class or could be an independent function that is not dependent on any other part of the code.

Integration Testing: An extension of unit testing is integration testing. In unit testing each unit will be tested separately, while in integration testing two or more units that are already tested will be combined and tested. While integrating the units, it can identify the problems and the main goal of integration testing is to derive the consistencies between the components.

Model Testing: Using Model Based testing, test cases can be generated automatically, where a model of the system is used for test case generation.

Performance testing: In performance testing, the various responses of the application under test are measured under various workload conditions.

Chapter 8 Project Summary

This report completes our first part of the project, CmpE 295A. We have accomplished to finalize our project idea, did in-depth research, decided on project design and planed the implementation and testing strategies. Resource and budget requirements are mentioned in chapter 3 of this document which are necessary for the implementation of our project. The actual implementation of the project would start in the next semester when we start the part-B of our CmpE 295. Since we would be putting in every effort to even better understand our project idea and do further research into it; it may be possible that some of the requirements or specifications might change over the course of time.