Abstract.

Network usage and demands are growing at a very fast rate and to
meet the current requirements, there is a need for automatic infrastructure
scaling.

Traditional networks are difficult to automate because of the

distributed nature of their decision making process for switching or
routing which are collocated on the same device. Managing complex
environments using traditional networks is time-consuming and
expensive, especially in the case of generating virtual machines,
migration and network configuration. To mitigate the challenges, network
operations require efficient, flexible and scalable software defmed
networks (SDN). We have discussed various issues in SDN and suggests
how to mitigate the network management related issues. This project
deals with developing Software Defined Networking framework by using
the OpenDaylight controller. This runs over a SDN controller based on
Openflow to program the application which can be built on the software,
without any dedicated hardware.

1
 Table of Contents
1 ...................... ................................ ................................ ................................ Abstract.
3 .................................. ................................ ................................ 1. Chapter 1: Overview
3 ........................................ ................................ ................................ 1.1 Introduction
4 ......................................... ................................ ................................ 1.2 Background
5 ....................................... ................................ 1.3 Problem Statement and Motivation
6 ......................................... ................................ ................................ 1.4 Project Aim
6 ............................... ................................ ................................ ject Objectivesٍ1.5 Pr
7 ...................................... ................................ ................................ 1.6 Project Scope
7 ...................... ................................ ................................ 2. Chapter 2: Literature Review
7 ............ ................................ ................................ ................................ 2.1 Introduction
7 ........................................ ................................ 2.2 SDN Architecture and Components
28 .................... ................................ ................................ Methodology 3.
28 .............................. ................................ 3.1 SDN Setup with OpenDaylight Controller
28 .............. ................................ ................................ 3.1.1 Environment Requirements
29 .................... ................................ ................................ 3.1.2 Virtual Machines Setup
29 ................... ................................ 3.1.2.1 Configuring guest OS in Virtual Machines ej:.
33 ...................... ................................ 3.1.2.2 Virtual Machines’ Interface Configurations
31 .............................. ................................ 3.2 Installing and Configuring Open Daylight
35 ............ ................................ ................................ Installing and Configuring Mininet
37 .................. ................................ ................................ 3.3.1 Connect Niininet to ODL
38 ........................................ ................................ ................................ 3.3.2 Topology
39 ............. ................................ ................................ ................................ 4.1 Metrics
39 .................................. ................................ ................................ 4.1.1 Performance
39 .................................. ................................ 4.2 SDN Network vs. Traditional Network
39 .......................................... ................................ ................................ 4.2.1 Latency
41 ............. ................................ ................................ ................................ 4.3 Results
42 .................. ................................ ................................ ................................ Chapter 5
42 ............. ................................ ................................ ................................ Conclusion
44 ............. ................................ ................................ ................................ References

2
1. Chapter 1: Overview
1.1 Introduction
Computer networks are a complex technology that enables end-
devices to communicate with each other. A typical network infrastructure
includes routers, switches, servers, web servers, fïrewalls, load balancers,
intrusion prevention systems and other devices. Efficiency, reliability,
flexibility and robustness are the requirements for processing and
managing the tremendous amount of data sent over the network. That has
made the manufacturing companies of networking devices to implement
complex and resource intensive protocols that enable routers and switches
to communicate with each other by packet switching and creating a
networking topology for routing purposes [3].

Generally, the routing and switching solutions can be split into a

data and control plane. The data plane is used for packet forwarding
between ingress and egress ports according to lookup tables, whereas the
local control plane processes a topology and collects a data set to create
lookup tables. The high demands on network performance and scalability
have made the control plane to be inflexible, over complicated and hard
to operate and manage [4].

The solution for this dilemma is taken from the virtualization

technology used in data centers for server applications: multiple virtual
machines run on a hypervisor are abstracted from physical machine

3
hardware and share the same resources. This paradigm is adopted by
Software-Defined Networking (SDN), one of the most

revolutionizing technologies being a substitution for traditional

networks, and an abstraction layer in networking has been introduced.
Thus, data and control plane are separated [3].

The data plane is located in switch hardware, which serves packets

according to a forwarding table, whereas the centralized control plane or
controller is separately located in other hardware for a centralized device
orchestration. This technology enables IT departments, data centers,
Network Service Providers (NSP) or Internet Service Providers (ISP)to
efficiently use their resources in a more centralized and automated
way.[1]

Other driving forces for SDN were that the academic community
needed a large scale “sandbox” and data centers required the provisioning
to be fast to meet today‟s requirements. First, the separated data and
control planes enabled the researchers to conduct experiments vo1atng
other layers and traffic — this was a reason why OpenFlow protocol was
developed. Secondly, as long as current data centers are moving to cloud
technologies, the underlying networking infrastructure should be able to
change quickly. Thus, SDN has been an excellent solution for everything
mentioned above. [4]

1.2 Background
The demand for more effective networking environment is required
in today‟s immutable infrastructure to handle with rapidly changing
requirements of the users. Therefore (SDN) Software Defined
Networking was brought in around 2005 to reconstruct current network to
have accelerated innovation, consolidate administration and

4
programmability by separating the data plane and control planes.
Traditionally, the network admin has to control from the network
management plane in order to configure each network‟s devices
separately. This static setup of current • network devices does not permit
control-plane configuration. The Software-defined networking
(SDN)approach allows for open, user-controlled, management of the
forwarding hardware in network elements. SDN implements centralized
control- plane intelligence while keeping the data plane separate, which
in turn enables the administrator to configure network hardware directly
from the controller. This approach of centralizing control of the entire
network makes the network highly flexible. To meet growing demand
and cater for network instability, many researches proposed Software
Defined Networking (SDN) combined with network function
virtualization (NFV). SDN isolates the network control logic from the
hardware which in turn enables the network administrator to have more
control over network. functions and a global view of networks . [ 1]

1.3 Problem Statement and Motivation

If we look at traditional networking (layer 2 and layer 3 with routing
protocols such as BGP and OSPF), we are completely dominated by what
is called protocols.

These protocols in fact have been very helpful to the industry. They
are mostly standard. Different vendors and products can communicate
using standard protocols with each other. A Cisco router can establish a
BGP session with a Huawei switch or an open source Quagga router can
exchange OSPF routes with a Juniper firewall.

Furthermore the legacy networking and switching gears are based on

a tied control plane and forwarding plane on a single box. Each switch or
router runs a control software (operating system) which includes

5
components such as spanning tree, BGP, OSPF, link aggregation, and so
on. Each device uses these protocols to build a network from its own
perspective.

This tide integration between software and hardware, or control and

data plane limits the scalability of the network because of a lack of
having a single, know all, network brain.

One of the main objectives of SDN is to dis.-aggregate the control

and data plane. That means to have a single control plane software (the
SDN controller) and multiple bare metal SDN-enabled data plane gears
(such as pure Open flow switches).

SDN can help us to come out of the routing protocol cage, look at
different ways to forward traffic. SDN can directly program each switch
or even override a route that is installed by routing protocols.

1.4 Project Aim

The aim of this project is to gain experience with the SDN
technology, that the most revolutionizing technologies being a
substitution for traditional networks - and evaluate its status by building a
full SDN system using the Open Daylight controller being the control
plane and Mininet being the data plane, and give instructions how to
create SDN based network , and prove that SDN networks are better than
traditional networks so that migration to SDN is the solution.

ject Objectives
 . Define SDN architecture — future of networks — and its features
over traditional network.

 . Explain what Open flow and SDNs are.

 . Compare the SDN features with traditional networks

6
1.6 Project Scope
This project will focus on building SDN topology with mininet
emulator connected with Open daylight controller to show how SDN
network performance i‫ ڑ‬better than traditional network where the metric
is the latency.

2. Chapter 2: Literature Review

2.1 Introduction
Tri this chapter we will describes the SDN architecture and its
components. In addition, data and control planes will be covered
separately for a better understanding. To understand how communication
between each layer works, northbound and southbound interfaces will be
described. In the end, we will provide an overview of the existing SDN
controllers and give an introduction to the Open Daylight (ODL)
controller that has been chosen in our project to be the SDN controller.

2.2 SDN Architecture and Components

SDN architecture (Figure 2.1) is based on a principle of separation
of the control plane or the network plane from the forwarding plan and a
logical centralization of a control program or a controller that makes
forwarding decisions and installs rules on switches or routers. These rules
make the forwarding hardware to switch packets between ports.
According to this architecture, the SDN can logically be represented as a
three-layered architecture

 Infrastructure layer: This layer is often referred to as a data

plane. It involves forwarding hardware, for example,

7
 switches and routers, including forwarding components, and
Application Programming Interfaces (API).

 Control layer: The other name is a control plane. Network

intelligence in a form of logically centralized and software-
based SDN controller installed on any UNIX based
Operating System (OS) run on any hardware. The control
layer manages forwarding hardware and installs forwarding
rules via APIs.

 Application over control state transfer developers

networking deployed to layer: Applications(REST) APIs.
to easily develop function tasks. and services take control via
Representational concept enables applications that perform
Applications are usually [4].

Figure 2. 1 SDN Architecture.

The APIs southbound in the SDN architecture interfaces. Those are

used are often called northbound for the communication and hardware,
controllers and applications.

8
 A southbound interface is defined as the connection between
networking devices and controllers, whereas the northbound interface is
the connection between applications and the controllers [5].

2.3 Data Plane

The data plane infrastructure consists of networking devices. A

network device is an entity that receives packets on its ports and performs
one or more network functions on them. For example, a received packet
can be forwarded, or dropped, or its header can be altered. The packet
forwarding function is based on a Forwarding Information Base (FIB)
table or tables, which are located on a forwarding hardware and contain
MAC addresses mapped to ports, preprogrammed by the control plane.[6]

In contrast, the SDN technology uses flow tables, which are not the
same. as FIB tables. The FIB table is a simple set of instructions based on
destination-based switching, whereas the flow table includes a sequential
set of in tructions and actions.

Sometimes, the data plane is referred to as the fast path for packet
management because it requires no further investigation other than an
address extraction of the packet destination relying on preprogramed FIB.
But one exception exists in the above mentioned process if the packet
destination is not found from the lookup tables. In order to proceed, the
detected packet with an unknown address is sent to the control plane
where the controller makes a forwarding decision using the Routing
Information Base (RIB) table, which contains topology, network
destinations and metrics associated with routes. In case of SDN, it resides
on a software-based controller. [1]

In addition to forwarding decisions, the data plane may include other

small features and services usually mentioned as forwarding features.

9
Depending on a system, a separate discrete tables may exist for these
features or they can act as extensions to the forward-in tables. [1]

For example, the following features can be used in SDN as well as

in traditional routing:

 Access Control List (ACL): Can specify drop, alter, pass and
b ther actions for a specific matching flow. Quality of
Service (Qos): Mapping a flow to a queue on an egress to
normalize and provide an uninterruptible service. It may
specify packets to be dropped regardless of the forwarding
policy.

One technology that provides networking functions in SDN, which

were removed from the data plane, is called Networking Functions
Virtualizatjon (NFV). It is a networking concept that allows to virtualize
entire classes of networking functions into building blocks.

Those can be connected or chained in order to create networking

services. Examples of the services are Network Address Translation
(NAT), Authentication, Authorization and Accounting (AAA) and Secure
Sockets Layer (SSL) protocol. A system example of SDN, NFV and
clouds can be Open Daylight controller with Open Stack cloud
technology.

This combination provides fast provisioning, advanced NFV

features and scalability.

Referring to hardware, there are white box switches which exist for
SDN purposes. They represent foundational elements of the networking
infrastructure that enable organizations to choose and use only those
features they need to realize as their SDN objectives.

13
 The white box switches can corne with pre-installed OS with
minimal software installed or be sold as a bare metal device. This allows
users and businesses to customize switches according to their needs. [3]

2.4 Southbound Interfaces

The APIs of the Southbound interface enable an SDN controller to

efficiently control a networking infrastructure and make dynamic changes
in accordance with real-time traffic, its demands and needs.

Several examples of southbound APIs exist:

 Open Flow: An SDN southbound protocol proposed to be a

standard protocol in industry and used to transport a control
logic function from a switch to a controller. Open v Switch
Database Protocol (OVSDB): Management protocol used by
Open v Switch open source software switch.
 Locator ID Separation Protocol (LISP): It provides a flexible
map-and-encap framework that can be used for overlay
network applications, such as data center network
virtualization, and Network Function Virtualization (NFV).
 Network Configuration Protocol (NETCONF): The protocol
is used for networking devices configuration. Other
examples are shown in illustrating APIs supported by the
Open Daylight controller.
 The Open Daylight controller supports many protocols to be
used by different users, businesses and vendors.

11
ODEN Source SDN Platfoini Littitum:

Figure 2. 2 OpenDaylight Architecture and Supported Southbound APIs.

Open Flow Protocol Communication between an SDN controller

and networking devices is handled through the southbound APIs. One of
the most popular protocols It was experiments in production networks.
flexible routing of network flows without was achieved where a
controller orchestrates rules in networking devices. its advantages led to
the protocol provides a interrupting other traffic. This the data and control
plane, traffic and makes.

Open Flow known switches firmware does not require any

interfaces have to be open some extension for the changes support it as
long as only a few well plane. changes that can be provided The Open
Daytight APIs (REST)S is Open Flow. first proposed as a way for
researchers to conduct being used beyond research. Due to its flexibility,
How-ever, possibility it by separating network or changes not have to
open their systems to hardware just and vendors need do for the control
software The Ethernet existing hardware. reason asa it is why possible is
the fact that all the modern switches and routers contain flow tables that
are used for firewalls, Quality of Service (QoS), NAT, and for statistics

12
collection. Although, the implementation of the flow tables may vary
from one vendor to another, that run on many exploits them. there is a
common set of functions routers.

The Open Flow As mentioned above, using the Open Flow protocol,
a controller is able to not only set forwarding statistics, by de-tails, ports,
connectivity but learn the status and the Controller the switch to a remote
control process (called the controller), allowing flow network topology of
Ethernet switches. entries, Scope of Open Flow Switch

Figure 2. 3 Open Flow switch specs.

As shown in figure 4, an OpenFlow Switch consists of at least three

parts:

(1)a Flow Table, with an action associated with each flow entry, to
tell the switch how to process the flows, (2) a Secure Channel that
connects commands and packets to be sent between a controller and the
switch usmg (3) the Open Flow Protocol, which provides an open and
standard way for a controller to communicate with a switch [11].

13
Flow flow tables and group tables and virtual from in table consist of
flow entries a traffic flow coming

The tables of an incoming packets a flow entry is found, that define

how from/to different the instructions included in that entry will be
executed against the packet. repeating the the packet forward, numbering
of the tables. packet will this packet. [ 12].

the packet to another and again. A flow entry can backwards (see
figure When the packet processing pipeline stops, the Packet In — o
Packet Out -p- Figure 2. 4 Packets match against tables table for a packet
is missing, several instructions that can be set for this dropping the
packet, passing it to a not her Options flow-table or sending controller
over the control channel as shown in figure 2.5.

Figure 2. 5 Packets Flowchart.

14
 OpenFlow Channel is the interface that is used for a connection
between each Open-Flow switch controller can receive switch generated
events, send packets out of the last but not least, configure connection
between the switch and the controller Transport Layer Security (TLS)
protocol. However, it may be run directly over Transmission Control
Protocol (TCP). [12].

2.6ControlPlane

of the data plane devices over southbound interfaces devices how to

handle packets.

is to configure and manage the and instruct the networking It is

usually same time, distributed and is called clustering.[1] controllers at
the Examples of the controllers that reside on the control plane are

OpenDaylight, Floodlight, Open Contrail and Flow-Visor.

The main functionalities of the control plane are

 Maintenance and discovery of topology

 Jnstantiation and selection of a packet route
 Mechanisms for path failover.
Moreover, the plane also provides services for applications to use
the data plane and data gathered by the control plane to provide other
functions within the network. [1] Examples of the applications include
network provisioning, advanced network topology discovery, path
reservation and firewall. Communication between the control plae and the
applications is established through Northbound APIs.

15
2.7 Northbound Interfaces
The role of the northbound interface is to provide a high-level API
between the controller and applications that can compute network
operations based on the events collected by the control plane. Figure 2.6
represents the existing APIs in the SDN system.

The main goal of the APIs is to abstract the underlying network

infrastructure and enable application developers to have their attention on
the application development instead of understanding how their changes
can affect the interworking of the network.

The main architectural style for northbound API is Representational

State Transfer (REST). The REST functions at the same functions
without mechanism called hypertext driven navigation of the connected
resources.

In particular, a REST API consists of the connected REST resources

that provide different services through uniform interfaces. In the case of
SDN, it includes services from both data and control planes, such as
switches, routers, subnets, networks, NAT devices, and controllers. [1]

2.8 Overview of the Existing SDN Controllers

16
 DN cotrollers reside on the control plane. They are the “brains” of
the network and Perform management functions over switches or routers
via southbound APIs. There are several open source controllers available
for usage, for example, Open Daylight, Flood-light, Open Contrail and
Flow Vis or.

In this project, the Open Daylight controller was used to create an

SDN system. The reason why we chose this controller was that it is
supported by Linux Foundation and the project is always evolving.
Secondly, there are platinum contributors such as Cisco, Ericsson,
Brocade, Intel and others which support and develop the project which
makes it reliable for usage. Furthermore, it allows other non Open Flow
protocols to be used and provides such functions as clustering, multilayer
network optimization, load balancing and others. Last, but not least is that
the Open Daylight controller has well-structured documentation pages,
which helps in the case of using such a complex system. Thus, the Open
Daylight will be covered in sections 2.9.

2.9 Introduction to Open Daylight Controller

The Open flay light controller is an open-source controller under the
Linux Foundation collaborative projects. It is a software application and
as a Java Virtual Machine (JVM) it can be run on any OS that supports
Java. As shown in figure (2.7), it consists of several blocks: NorTh bound
REST APIs, Network Service Functions, Network Orchestration
Functions, Service Abstraction Layer and Southbound APIs.

17
 Figure 2. 7 Structure of the OpenDaylight Controller. Copied from(3).
As a southbound protocol, the OpenDaylight can use, for example,
OpenFlow 1 .0- 1 .3 and BGP-LS protocols. [2]

using Model-Driven Management Group consistent relationships

mappings and patterns code/API generation from specific moderning
Unified Modelling modeling language Gateway Interface (Osage) MDSE
between models. framework is of writing) a framework (different)
models, 0MG focus their YANG has emerged domain. There also
available is designed Object based on standardized on as the data are
open Service This framework is used for running the applications in the
same address space as the controller, whereas the REST APIs are used by
web applications that do not reside in the same address space (or
hardware) as the controller.

Service. Abstraction Layer (SAL) was chosen as the modular design

of the Open Daylight controller (figure 10). It enables the software to
support multiple protocols on the south-bound and provides coherent
services for modules and applications.

While the OSGi framework allows a dynamic linking for different

southbound protocols, services such as Device Discovery being used by

18
modules like Topology Manager are provided by the SAL. As long as
services are constructed using the features exposed by the plugins, the
SAL can map to the appropriate plugin and use the most appropriate
southbound protocol for networkig device interaction based on the
service request. Figure 11 represents the previous mentioned plugin
linking.

Figure 2. 8 Service Abstraction Layer.

Figure 2. 9 OpenDaylight Controller architecture.

The above mentioned architecture enables the controller to be:
 Flexible: It is able to serve a vast diversity of applications
using the same frame-work and programming model and
provide reliable APIs.

19
  Scalable in the development process: There is no common
infrastructure subsist-tern, Instead, plugins are developed
idependently of each other. Thus, the controller has short
integration times.
 Run-time extensible: The controller can easily adapt to new
data models and dynamically load other plugins.

As regards scalability, the OpenDaylight controller has over 1 7 proj

ects being developed at the same time, including, for example, L2 Switch,
OpenDaylight User experience (DLUX), and Virtual Tenant Network
(VTN). In addition, the OpenDaylight controller sup-ports the High
Availability model (HA). There can be several instances of the controller
run that act as one logical controller. Thus, reliability and redundancy can
be achieved.

2.10 SDN Benefits

There are high-level benefits of using SDN, a few of which we have
explained in the following list:

 An integrated network: We used to have a standalone concept in

traditional networks. Each switch was managed separately; each
switch was running its own routing protocol instance and was
processing routing information messages from other neighbors. In
SDN, we are migrating to a centralized model, where the SDN
controller becomes the single point of configuration of the
network, where you will apply the policies and configuration.
 Scalable layer 2 across layer 3: Having a layer 2 network across
multiple la‎er 3 networks is something that all network architects
are interested in and until now we have been using proprietary
methods such as OTV or by using a service provider VPLS service.
With SDN, we can create layer 2 networks across multiple
23
 switches or layer 3 domains (using VXLAN) and expand the layer
2 networks. In many cloud environments, where the virtual
machines are distributed across different hosts in different data
centers, this is a major requirement.
 Third-party application programmability: This is a very generic
term, isn‟t it? But what I‟m referring to is to let other applications
communicate with your network. For example, in many new
distributed IP storage systems, the IP storage controller has the
ability to talk to networks to provide the best, shortest path to the
storage node. With SDN we are letting other applications control
the network. of course this control has limitations and DN doesn‟t
allow an application to scrap the whole network.
 Flexible application based network: In SDN, everything is an
application. L2/L3, BGP, VMware Integration, and so on all are
applications running in the SDN controller.
 Service chaining: On the fly you add a firewall in the path or a load
balancer. This is service insertion.
 Unified wired and wireless: This is an ideal benefit, to have a
controller that supports both wired and wireless network. Open
Daylight is the only controller that supports CAP WAP protocols
that allows integration with wireless access points.
mponents of an SDN
A software-defined network infrastructure has two main key
components:

1. The SDN controller (only one, could be deployed in a highly

available cluster).
2. The SDN-enabled switches (multiple switches, mostly in a Clos
topology in a data center) as shown in the following figure:

21
 An SDN controller is the single brain of the SDN domain. In fact, an
SDN domain is very similar to a chassis-based switch. You can imagine
the supervisor or management module of a chassis-based switch as an
SDN controller and the rest of the line card and I/O cards as SDN
switches. The main differençe between an SDN network and a chassis-
based switch is that you can scale out the SDN with multiple switches,
where in a chassis-based switch you are limited to the number of slots in
that chassis:

Figure 2. 10 SDN topology

Figure 2. 11 legacy based Switch vs. SDN world

2.10.2 Controlling the fabric

22
 It is very important that you understand the main technologies
involved in SDN. These methods are used by SDN controllers to manage
and control the SDN network.

In general, there are two methods available for controlling the fabric:

 . Direct fabric programming: In this method, the SDN controller

directly communicates with SDN-enabled switches via southbound
protocols such as OpenFlow, NETCONF, and OVSDB. The SDN
controller programs each switch member with related information
about fabric, and how to forward the traffic. Direct fabric,
programming is the method used by Open Daylight.
 . Overlay: In the overlay method, the DN controller doesn‟t rely
on programming the network switches and routers. Instead it builds
a virtual overlay network on top of the existing underlay network.
The underlay network can be an L2 or L3 network with traditional
network switches and router, just providing IP connectivity. The
SDN controller uses this platform to build the overlay using
encapsulation protocols such as VXLAN and NVGRE. VMware
NSX uses overlay technology to build and control the virtual
fabric.

2.1O.3Difference between direct fabric programming and overlay

 Let‟s look at how the standard switch or router performs a frame

forwarding. For our understanding we will look at a generic layer 3
switch (1 G or 1 0G) from any vendor:
 An Ethernet switch is a very simple device, it‟s just a silicon
chipset, which is from one of the large silicon manufacturers such
as Broadcom or Marvel, a CPU (which is either a x86 or a low
power ARM-based processor), which runs the vendor‟s software

23
 (vendor here is referring to switch vendor such as Cisco or Juniper
or Arista, and so on.):
 The switch silicon is like a comparison table. It maps the frames to
ports. When a switch receives a packet, it looks into its content-
addressable memory (CAM) table to find out what needs to be
done to this frame received on port X. The CAM table, which is
already programmed and filled by the switch software, will have an
entry to tell the switch silicon what needs to be done on that frame.
For example, send it out of port Y and change the destination MAC
to switch burned in MAC. Or any other decision such as sending it
to the switch CPU for processing (if it‟s a routing protocol packet,
for example an OSPF LSA).
 So in simple terms, in standard switches the CAM table of a switch
is filled by entries that are programmed and controlled by switch
CPU or switch software.
 In SDN, we have a slightly different scenario, you can imagine that
th DN• controller will control the CAM table of all switches. The
terms are changed slightly and it is called a flow table. A flow table
is nothing but the same CAM entries in the switch, but it‟s called a
flow table and each entry is called a flow entry.
 SDN controller programs each switch CAM table via a protocol
that is called southbound protocol. There are multiple southbound
protocols where the most famous and standard one is Open Flow;
however, the others such as NETCONF and OVSDB also exist in
standard protocol groups. Cisco‟s OpFlex (https ://tools. i etf.
org/html/draftsrnithopflexo3) is also an open source protocol which
is a southbound protocol between Cisco APIC controller and Cisco
Nexus switches. OpFlex is also supported on Open Daylight.

24
 Open Flow is a protocol that allows SDN controller to program
each switch in the SDN network. Please remember that the Open
Flow is a piece of software, it‟s a protocol. The Open Flow agent
runs on each switch and starts communicating with the OpenFlow
server piece on SDN controller
 You may have heard about overlays. about the SD-WAN,
networking. An overlay is a Especially if you have heard based on
overlay on top of an underlay network. Seems complex? Let me
provide a more familiar example. An SSL VPN tunnel is an
overlay on top of a IP network. InSSL VPN, the underlay is IP, and
an overlay is an SSL.
 The real packets are encapsulated as new payload inside the
packets. You can make more examples of overlays, and also the
new overlays such as VXLAN and NVGRE:

Figure 2. 12 Overlay Topology

 Overlays are also considered as part of the SDN family. are
software defined. They are created and managed by software.
Overlays are not dependent on the underlay IP network; therefore
deploying an overlay network is much easier than deploying a full
SDN with SDN controller and switches. In data center overlay

25
 networks there are two main protocols used for encapsulation:
VXLAN and NVGRE.
 VXLAN is a UDP packet, which encapsulates the whole W packet
as a T.JDP payload and sends over the other end. VXLAN
endpoints are called Virtual Tunnel End Points (VTEP). VTEPs
create virtual tunnels between each other and transmit the UDP
packets that are all having the packets encapsulated inside the UDP
payload.
 VXLAN uses an identification number for networks called virtual
network ID (VNID), which identifies which packet belongs to
which virtual network.
 VXLAN is very common between most of the vendors and are
very well supported.
 Network Virtualizatjon using GRE (NVGRE) is another protocol
similar to VXLAN, but it is not very popular. Microsoft is one of
the promoters of NVGRE on their SONIC switch operating system.
 The most important overlay solution on the market is VMware
NSX.
 Now we have learned very briefly about DN and overlays, let‟s
have a comparison between these two technologies:
Table 2. 1 comparison between DFP and Overlay

26
 In summary, SDN and overlays are somehow completing each
other, but they are different. ome people don‟t consider overlays
as SDN, and some do.

 Open Daylight is an SDN controller, it is not an overlay.

27
Chapter 3:

3. Methodology

3.1 SDN Setup with OpenDaylight Controller

In this section we will describe in detail how to set up virtual
machines in a virtual environment, configure virtual network between the
virtual machines and install the OpenDaylight controller along with
Mininet for testing purposes

3.1.1 Environment Requirements

The SDN system will be built in the virtual environment with
several Virtual Machines (VM).

The requirements are as follow:

1. We will use a Lenovo laptop with Oracle Virtual Box installed. It

runs with 4 core 2.60 GHz CPU and 12 GB of RAM. Of course,
the system may require more than the available computing power.
2. Ubuntu Server 14.04.3 LTS 64-bit was chosen as a guest OS.
3. And for the project, we used 2 VMs: one for the OpenDaylight
controller, one for Mininet, a virtualized network.

The OpenDaylight controllers will have the following configuration:

1. Two Core.
2. Four GB RAMI.
3. 32 GB HDD.
4. Tow virtual network adapters (1 adapter for Secure Shell (SSH)
connection to the VM and 1 for intercommunication between the
controllers and Mininet).

Another VM with Mininet will have another configuration:

28
 1. One Core.
2. Two GB RAM.
3. 12GBHDD.
4. VM, case 1 for intercommunication of connection with with the
controllers and other virtual the 1 spare in such as OpenvS witch).

Figure 3. 1 Network Topology

As soon as we made a decision about the networking topology, we started

to configure my VMs. t!4 „

3.1.2 Virtual Machines Setup

As long as the goal of the project has been to gain experience and
provide instructions, the configuration steps will be given without the
name and configured.

We created 2VMs — 1 for the Op end ay light Controller, and one

for Mini net.

3.1.2.1 Configuring guest OS in Virtual Machines ej:.

Each VM instance will run the same OS — Ubuntu Server 14.03.3
LTS 64-bit. Hence, installation and configuration steps are the same for
each VM.

To continue the guidance, start with supplying the machine with an

OS image to be installed. Once done, start the machine and configure the
OS. The step is straightforward and does not require any special
configurations except the “Open H server “ package that should be
installed for SSH connectivity. Of course, it is possible to connect to the

29
VMs through the console in the Virtual Box. host, but we wanted to have
a remote connectivity to connect from any remote place.

3 Vi tua Machines’ Inte face Configurations

 Controller

auto ethû
iface ethO met dhcp
auto ethi
iface ethi met static
address 192.16a.5E.1Q3
netmask 255.255.255.0
network 192.1L.5E.0
gateway 19E.16.56.1
dns—nameservers

 Mininet

33
 At this stage, the virtual machines setup is completed. Repeat
previous steps to configure other VMs in accordance to the system
requirements.

3.2 Installing and Configuring Open Daylight

are up and running, Open Daylight controller installation. running,
the Mini net network will be installed. Time verify the First, connect to
the first VM via SSH. To make other steps simpler, create a "Downloads"
and download a binary Helium version (the latest version at the time of
writing) of the controller from https://www.openday1jghtorg/dowfli0 to
the directory that was created. The simplest way to do that is by “wget
[OPTION]... [RL]..“. Extract the downloaded archive to “home “
directory and name it “ODL“.

3.2.1 Configuring the OpenDaylight Controller

Before the controller can be started, it is wise to change its IP

address. The controller will be accessible using that address and isolated
from the external network. By default, the controller listens to the
loopback address and is not accessible from other VMs.

To configure the EP address, proceed with the following steps:

In the “ODL/etc” folder open “custom.properties” file.

31
 1. Replace the IP address with the address configured to the second
interface of the O in the following fields: “netconf.tcp.address=”,“
netconf.tcp . client. address=” and “of. address=”2.
2. Next, start the controller by executing “./karaf”, which is a binary
file that starts the controller, in the “ODL/bin!” directory. The
controller will start and will be ready for work.
3. 2. 1 . 1 L2Switch Fea tu res In stczlla tb n Steps

At the moment, the controller is not capable to do any networking

related tasks. Thus, L2Switch features should be installed. The
Command Line Interface (CLI) command looks like the following:

karaf@root>feature:jnstall odl—l2swjtch—swjtch—uj
Verify that the components are properly installed:
karaf@root>feature:ljst —j I grep l2switch

Figure 3. 3 Installed L2Switch Components.

As shown in figure 3.3, along with the “odl-l2switch-switch-ui”

feature, the “od I- l2switch-hosttracker”. “odi- l2switch-addresstracker”,
“odl l2switch-arphandler”. “odi- l2switch- loopremover” and “odl-
l2switch- packethandler” should be automatically installed as well. The

32
following architectural components play different roles in the L2Switch
project:

 Packet handler: ،s responsible for packets decoding and dispatching

decoded packets notification.
 Loop remover: Removes loops in the network and updates
Spanning Tree Protocol (STP) status of the network ports.
 host tracker: Tracks the hosts and updates operational topology
tree.
 Arp handler: Handles the decoded Address Resolution Protocol
(ARP) packets, either by installing proactive flood flows or by
dispatching packets back to network, based on the configuration.

The above mentioned components provide Layer 2 switch

connectivity. What it means is when a packet comes from a networking
device, L2Switch will learn about the MAC address of a source device. If
the destination is unknown, it will send a broadcast message on all
external ports in the network and expect to receive a reply message from
the device the packet should be sent to. Otherwise, if it knows about the
destination, the packet will be forwarded to the destination.

L2switch Main: Is responsible for flows installation on each switch,

based on addresses learned and network traffic. „ 3.2.1.2 Installing
DLUXFecztures The DLUX is pronounced like “Deluxe “. It is
responsible for the Graphical User Interface (GUI) features in the
OpenDaylight controller. It can be installed with the following
commands:

1. Execute and install “feature: install odl-restconf” in the console.

2. Next, install “feature: install odl-mdsal-apidocs”.
3. Finally, execute “feature: install odi-diux-all” command.

33
 The “odi-restconf” provides RE T APIs for applications and
supports “Options “, “GET”, “PUT”, “DELETE “ HyperText Transfer
Protocol (HTTP) commands. The “odl-rndsal-- apidocs “ provides
apidocs explorer and lists all the available APIs on the controller. The
“odi-diux all “ installs the GUI features for the OpenDaylight controller.
In order to verify that the above mentioned features are installed,
Executeufeature: list -j I grep IIIIODULE_NA[IE]J”.

The controller is ready to provide basic services to networking

devices. In order to test them, the Mininet network will be installed on
another VM or it can be installed on the same VM.

Open the ODL web UI at the Host IP where ODL installed

(127.0.0.1) withport 8181.

http : //<ODL_Host_IP> : 181/index . html

Account: admin .
Password: admin

This URL would successfully access the web UI only if “./karaf “

has run long enough, by TAs‟ experience, 2-6 minutes.

Run Open Daylight successfully

34
 Figure 3. 4 Launch Open Daylight CLI

Installing and Configuring Mininet

In brief, the Mininet is a network emulator. It can create a network of
virtual switches, controllers, servers, hosts, links and other network
infrastructure devices to work with. It uses OpenFlow switches as well
as openvSwitches for the network configuration. We decided to use
the

Figure 3. 5 Opendaylight GUI

Mininet to test the OpenDaylight controller because it is powerful,

supports IP connectivity, and allows to create a huge network on the VM
without any special requirements.

Moreover, we could not find any real hardware that would support
Open Flow protocol. Thus, the Mininet was used.

To continue the installation process, it is wise to install the Mininet

emulator from source (github.comlMininet/Mininet) to get the newest
available version (Version 2.2.0 was available at the time of doing the
project). It is possible to download a ready-made Mininet VM from

35
http://mininet.org, but it has additional features that, for example, we
have not used and they would have just wasted computing resources. I !
order to install the Mininet, proceed with the following steps:

1. Clone the source code “git clone git://github.comlrn ininet/M

minet” to Mininet machine. In the “Mininet‟ folder list available
versions “git tag”.

2. Choose the version to be installed “git checkout —b [VER ION]”.

Once the code is fetched, install Mininet “Mininet/util/jnstalLsh -
a”. The “-a” option will install everything included in the Mininet:
dependencies to the openvSwitch, OpenFlow wireshark, POX and
other packages.

3. After the installation is completed, verify the basic functionality

“sudo mn -- test pingall”.This command will test IP connectivity
between the hosts in the network created in Mininet. The result
should be the same as shown in figure 3.6.

36
 Afler successful installation and testing, it is now possible to connect
to the OpenDaylight controller installed in the Installing and Configuring
OpenDaylight section.

3.3.1 Connect Niininet to ODL

For this purpose, execute “sudo controller=remote,ip=
192.168.56.103, port6633 --topo tree, 3 --switch ovsk, protocols=Open
Flow 13 --mac” command using an appropriate IP address.

 topo [single f linear f tree],<num> : Specify topology

 controller remote(,ip<ipaddres>,poi.<portnum>] : Use a remote
controller instead of default one. If ip and port not specified,
192.168.56.103: 6633 will be used by default.
 switch ovsk, protocols = OpenFlowl3: Choose Open-vSwitch
supporting OpenFlow 1.3
 mac : Make the virtual hosts‟ MAC address easy to read. Use
„ifconfig” to check.

This will create 6 switches and 3 hosts. ،f the controller is

configured right, the “Mininet>pingall” command should execute without
any failures as shown in figurc3.7.

The result will show that L2 switch features work properly and ،P
connectivity between hosts in the Mininet is successfully established.
Once the GUI has been installed in section 3.3, it is now possible to check
the networking topology created by the L2Switch features.

The access link is “http:/f 192.168.56.103:818 1/index.html”. The

default credentials are “admin” for both username and password. From
the left menu choose “Topology” and it will appear (seeError! Reference
source not found. Error! Reference source not found.). Some failures

37
exist because the project is still in the development process. That is why
the topology sometimes is not well structured as shown in Error!

Reference source not found..

At this stage, the basic configuration of the controller and the

network emulator is ready. In the next section, we will show how to
install a cluster of controllers and possible ways of testing.

Figure 3. 8 Topology in DLUX

3.3.2 Topology
You are able to specify different topology as mentioned earlier.

# mn —— topo topo single, 2: Single switch with 2 virtual hosts.

 topo linear, 4: 4 switches connected as a line, and each switch has a

virtual host attached to it.
 topo tree,3: There are 7 switches arranged as a binary tree with
depth=3. Each leaf switch has two virtual hosts.

38
Chapter 4: performance evaluation

In This chapter we will produce the results that allow a short

evaluation of the SDN behavior comparing with traditional networks,
aims to represent performance evaluation of the SDN behavior comparing
with traditional networks.

4.1 Metrics
This section presents a brief explanation of the evaluation metrics
used to test the project. The evaluation metrics used is performance
evaluation.

4.1.1 Performance
This metric evaluates the performance of an OpenFlow network and
is composed of latency and throughput measurements.

4.2 SDN Network vs. Traditional Network

This section evaluate the behavior of the SD‫ ر‬and the traditional
network. The metric test that permits to make this comparison is latency.

4.2.1 Latency
The main goal of this metric is to prove that SDN networks basically
have better or equal latency compared to traditional networks. To achieve
this goal a ping that measures the latency was necessary. These pings are
made in SDN.

We have chosen mininet emulator to test ping latency in SDN mode and
se • packet tracer to test in traditional network.

We have chosen Opendaylight controller and 3 openflow switches

and 4 virtual host as described in chapter3 the ping that tested is from hi
to h3 as shown in the figure 4. 1.

39
 Then we implement the same topology in traditional network using
Cisco Packet Tracer, the topology in Figure 4.3 below:

Figure 4. 3 Traditional Network topology

And the ping results are illustrated in Figure 4.4.

43
 Figure 4. 4 Ping statistics in traditional topology

And we notice that latency in SDN networks is better than

traditional network as shown in the table 4. 1 bellow.

Table 4. 1 RTT comparison between SDN and Traditional Network

4.3 Results
As shown latency of the packets what is going in traditional
networks is better than the The hosts do not know the network is being
managed, the results obtained show that there are no high latency values
in programmable networks.

41
Chapter 5
Conclusion
The goal of the project, to build an SDN system using OpenDaylight
controller in a virtualized environment, was met. Along with the
controller, an example application including virtual networking devices
was installed.

This project introduces SDN as a test platform. This document is

organized in 5 chapters. The first chapter consist of the motivations that
made us choose this project, as well as, aim, scope of the project, then in
chapter2 we described the SDN architecture and its components. In
addition, data and control planes have been covered separately for a better
understanding. To understand how communication between each layer
works, northbound and southbound interfaces have described. at the end
of that chapter, we provided an overview of the existing SDN controllers
and gave an introduction to the OpenDaylight (ODL) controller that has
been used in our project to be the SDN controller, leading to chapter 3
where implementation of the architecture is executed, we described how
to set up virtual machines in a virtual environment, configure virtual
network between the virtual machines and install the OpenDaylight
controller along with Mininet for testing purposes.

And finally to prove that SDN networks are better than traditional
network and migration to SDN is an important thing an evaluation was
performed in chapter 4. Tn chapter 2 we analyze the architecture to create
he testbed. This architecture will always have a controller that allows
transmission of instructions, management of the network, among others.

42
 This type of architecture is centralized, bringing with it bottleneck
problems. The implementation of this architecture involved the choice of
equipment and software, and justifying the choices made. We also

explain how we did it and what was learned from implementing

them. It is in the implementation chapter that problems start to arise and
things „. don‟t turn out as expected. Finally, to prove that migration to
SDN networks is so important and SDN is a valuable asset, several tests
were necessary. These tests consist of how the performance compared
against current networks.

After doing the network analysis, we found that SDNs are a valuable
asset to the new networking paradigm, because besides being easily
configured, a significant reduction in configuration time was observed as
well reduced frustration comparing to traditional networks, which have to
be configured device by device. Beyond these advantages the results
showed that, SDNs are better than a traditional network, even though the
first packet always has high latency values, because it has to be processed
by the controller, the remaining packets have lower latency comparing to
a traditional network. To close the conclusion, according to demand, the
impleméntation of this type of networks in big enterprises , the network‟s
performance level and reduction of CAPEX and OPEX, among others,
allow us to state that the networking paradigm will change in 10 years‟
time so migration to SDN is the best solution now a days.

As the final result, we gained experience with SDN technology and

documented the project with installation instructions. That can be a basis
for future Metropolia SDN offerings in terms of a practical learning
system if students want to test and play with modem SDN technology.

43
References
1. Nadeu TD, Gray K. SDN: Software Defined Networks.
ebastopol, CA: O‟Reilly; 2017.

2. Isolani PH, Wickboldt JA, Both CB, Rochol J, Granville LZ.

Interactive monitoring, visualization, and configuration of
OpenFlow-based SDN [online]. Porto Alegre, Brazil: IEEE; May
2015. URL: http://ieeexp1ore.ieee.org/xp1/aajc1eDe.. tails.j
sp?arnumber=7 1 402 Omoni - toring, %2 Ovisualization,
based%2OSDN.

3. SDX Central. Understanding the SDN Architecture [online].

Sunnyvale, CA: s DxCentral. URL: http s ://www . sdxc entrai.
comlresources/sdnJinsjde -sdn-archi tecture/.

4. Nishtha, Manu Sood. Software defined network — Architectures

[online]. Shimla,Ind ،a:IEEE;Decembe2ü 1 4.URL:
http://ieeexplore.ieee.org/xpl/artjcleDe... tails.j sp?arnumber=703
078 8

5. OpenDaylight Community. OpenDaylight Web Page [online].

URL: http://opendaylight.org/.

6. OpenDaylight community. OpenDaylight Lisp Flow

Mapping:User Guide foi‟ Heluim [online]. URL: http s : //wiki . op
end ayl i ght . org/vi ew/Op enD ayl ightLi sp_FlowMapp ing : Ar
- chitecture/. ‚

44
7. Open Networking Foundation. OpenFlow Switch Specification
[online]. 14 Octobei‟2 O 1 3 . URL:https ://www. opennetworking.
org/images/stories/downloads/sen..
resources/onfspecifications/openflow/openflowspecv1 .4.O.pdf.,

8. SDX Central. What are SDN Northbound APIs? [online].

Sunnyvale, CA: SDx Central. URL: https ://www . sdxcentral.
comlresources/sdn]noiihboundjnterfaces... api!.

9. OpenDaylight community. OpenDaylight DLUX:DLUX Karaf

Feature [online]. URL:http s ://wiki . opendaylight.
org!view/OpenDaylightDLux : DLUX Karaf Fea-ture/.

10. Li L, Wu Chou, Wei Zhou, Min Luo. Design Patterns and

Extensibility ofREST API forNetworking Applications [online].
IEEE; 1 1 January 2016. URL :http ://ieeexplore . ieee.
oi‟g/xpllarticleDetails.j sp?ar-num ber=73 78
522&newsearch=true&queiyText= 1 7. %O9Design%2 OPat
ing%20Applications%20/..

11. OpenDaylight community. L2 Switch:Helium:User Guide [online].

URL: https ://wiki . opendaylight. org/view/L2Switch: Helium
:User_Guide/.

12. OpenDaylight community. L2 Switch:Helium:Developer Guide

[online]. URL: https://wiki.opendayIiQht.org/vje/
Switch:HeIium:DeveloperGu، de/.

13. Mininet Team. Documentation [online]. 13 Novermber 2015.U

RL: Minjnet Team. Mininet Walkthrough [online].
URL:http://mininet.org/walkthrough/. 50f Page

45
46