SDN Based Load Balancing

Shaheer Pervaiz
Masters of Networking and Telecommunication Engineering

School of engineering, Macquarie University

Supervisor: Robert Abbas

 ACKNOWLEDGMENTS

I am greatly indebted to our project supervisor Robert Abbas. Without his personal
supervision, advice and valuable guidance, completion of this project would have
been doubtful. We are deeply indebted to them for their encouragement and continual
help during this work.
And we are also thankful to our parents and family who have been a constant source
of encouragement for us and brought us the values of honesty & hard work.
 Statement of candidate

I, Shaheer Pervaiz, declare that this report, submitted as part of the requirement for
the award of Bachelor of Engineering in the School of Engineering,
Macquarie University is entirely my own work unless otherwise referenced or
acknowledged. This document has not been submitted for qualification or assessment
an any academic institution

Student’s name:
Shaheer Pervaiz

Student’s Signature:

Date: November 20, 2019

Contents

ACKNOWLEDGMENTS 1

Contents 3

Chapter 1 Introduction 5

1.1 Project Goal 5

1.2 Structure of Thesis 6

Chapter 2 Background and Literature Review 7

2.1 SDN 7

2.2 SDN Architecture and Components 8

2.2.1 SDN Application Layer 10
2.2.2 SDN Control Plane 10
2.2.3 SDN Data Plane 11

2.3 SDN & Edge computing, IoT and Remote access 11

2.4 SDN & Intent-based Networking 12

2.5 SDN & Security 12

2.6 SDN & Cloud Computing 13

2.7 SDN & OPENFLOW 13

2.7.1 Match Fields 14
2.7.2 Actions 14
2.7.3 Counters 14
2.7.4 Openflow Working 14
2.7.4.1 OpenFlow Flow Table Memory Management 16

2.8 SDN Performance Challenges 16

2.8.1 Communication Overhead 17
2.8.2 Flow Rule Update Operation 18
2.8.3 SDN Security Threat and Vulnerabilities 19

2.9 SDN Benefits 19

Chapter 3 System Design and Architecture 21

3.1 System Architecture 21

3.1.1 Open Flow 21
3.1.1.1 Openflow VS Conventional Switch 23
3.1.2 POX SDN Controller 23
3.1.3 Ryu Controller 24
 3.1.4 Mininet 24

3.2 Input and Output Parameters 24

3.2.1 Round Robin based server selection 25
3.2.2 Random selection of server 25
3.2.3 Selection of server based on current workload 25

3.3 Methodology for this Project 25

3.4 Load Balancing Simulation 25

Chapter 4 Result 28

Chapter 5 Conclusion 32

References 33
 5

Chapter 1 Introduction

The main purpose of load balancing is to prevent any single server from getting
overloaded and possibly breaking down. In other words, load balancing improves
service availability and helps prevent downtimes. A load balancer is typically used to
distribute network or application traffic to multiple servers. The purpose of using a
load balancer is to enhance the performance of a network significantly by increasing
the throughput, minimizing the response time and delay and efficient utilization of
available resources.

Software defined networking (SDN) is a basically a technique used in networking

which provides the administrators of the network with access to initialize, control,
manage, and dynamically change how the network behaves through open interfaces
and by the lower-level functioning abstraction

The main purpose of this document is to clearly define functional, non-functional

requirements, use cases and models.

1.1 Project Goal

In the previous decade, there has been significant advancement in the field of
networking. It focuses on solving network congestion by using the solution of load
balancing. To understand how to prevent almost anything, it is often critical to first
understand some of the causes of the thing we want to avoid. For congested networks,
the method used to fix the issue can often be directly related to the reason. Probably
the most common cause of network congestion is plain old bandwidth. In this project
a load balancer will be implemented based on software defined networking. Software
defined networking appr-oaches are particularly productive and more cost effective
than the traditional approach due to many reasons. Traditional load balancers are
expensive hardware which are usually vendor specific. They are non-programmable
and hence non-flexible and non-scalable. An SDN-based load balancer allows for the
control of multiple devices. This is how networks can become more agile. The
network control can be programmed directly for more responsive and efficient
application services.

However, the software defined networking-based approach in contrast does not

require separate and dedicated hardware. It allows flexibility of network topology. It
is programmable and scalable as well as easy to configure. Furthermore, there are
many algorithms designed to achieve SDN based load balancing but for this project
the focus will be on Random Server Technique.
 6

1.2 Structure of Thesis

This article is divided into five chapters, the chapters are organized as follows:
Chapter 1 briefly describes the research background and significance of the research,
the main research content, the research purpose and the structure of the article;
Chapter 2 the second chapter is the background and literature review. Firstly, the
origin, research background and research significance of Software defined networking
and its uses in load balancing are put forward. Then it introduces the research
progress of the current load balancing methods and summarizes the advantages and
disadvantages of each method.
Chapter 3 is the system design and architecture section. That design section starts
from the concept design that introduces our load balancing algorithm and
programming software.
Chapter 4 is the result section that is corresponding to chapter 3. Based on the
experimental data, the feasibility and effectiveness of the framework and algorithm of
the system are proved.
Finally, we have summarized the work of this project.
 7

Chapter 2 Background and Literature

Review

The idea of programmability is the basis for the most precise definition of what SDN
is: technology that separates the control plane management of network devices from
the underlying data plane that forwards network traffic.

IDC broadens that definition of SDN by stating: “Datacenter SDN architectures

feature software-defined overlays or controllers that are abstracted from the
underlying network hardware, offering intent-or policy-based management of the
network as a whole. This results in a datacenter network that is better aligned with the
needs of application workloads through automated (thereby faster) provisioning,
programmatic network management, pervasive application-oriented visibility, and
where needed, direct integration with cloud orchestration platforms.”

The driving ideas behind the development of SDN are myriad. For example, it
promises to reduce the complexity of statically defined networks; make automating
network functions much easier; and allow for simpler provisioning and management
of networked resources, everywhere from the data center to the campus or wide area
network. Separating the control and data planes is the most common way to think of
what SDN is, but it is much more than that, said Mike Capuano, chief marketing
officer for Pluribus. “At its heart SDN has a centralized or distributed intelligent
entity that has an entire view of the network, that can make routing and switching
decisions based on that view,” Capuano said. “Typically, network routers and switches
only know about their neighboring network gear. But with a properly configured SDN
environment, that central entity can control everything, from easily changing policies
to simplifying configuration and automation across the enterprise.”

2.1 SDN
Traditionally, both the SDN control plane and data plane elements of a networking
architecture were packaged in proprietary, integrated code distributed by one or more
proprietary vendors. The OpenFlow open-source standard, created in 2008, was
 8

recognized as the first SDN architecture that defined how the control and data plane
elements would be separated and communicate with each other using the OpenFlow
protocol. The Open Network Foundation (ONF) is the body in charge of managing
OpenFlow standards. There are other standards and open-source organizations with
SDN resources, so OpenFlow is not the only protocol that makes up SDN.

2.2 SDN Architecture and Components

SDN is a software layer, it provides advantages such as reduced manual efforts,

dynamic scalability, and central management of network devices. To understand
better, consider the following: In traditional networks, each network device in an
enterprise or data centre is configured manually, something which is not only
error-prone, but also requires manual reconfiguration (a highly tedious and
time-consuming task) whenever there’s a change in network. SDN, on the other hand,
aims to have a holistic view of the network - you can configure/monitor/troubleshoot
network devices with ease from the central point, avoiding a lot of manual effort,
hence saving time and money in the process. As the software layer is virtual, it would
 9

help in virtualizing the networks that will be created on top. These virtual networks
are mapped to existing physical networks. Network Virtualization was very much
needed since server virtualization brought revolution in the IT industry to virtualize
storage and computing entities, something which played a key role in efficiently
utilizing resources. Similarly, network elements in traditional networks are highly
expensive with endless features, but those features were not getting completely
utilized, and that’s the problem SDN aims to solve.SDN at its core and as a one-liner,
is nothing but separation of control plane from data plane (or forwarding plane) in
traditional network elements (switches, routers). For the uninitiated, a control plane is
the intelligent logic in network equipment that controls how the data traffic (that’s
hitting the equipment) is managed and handled. On the other hand, a data plane is the
forwarding plane which manages forwarding/manipulating/dropping of the network
data traffic. You can also understand about control planes and data planes here.With
this separation, core intelligence of network elements (i.e. control plane) can be
moved to a central place which usually carries any of the following monikers: ‘control
system’, ‘controller,’ or ‘network operating system’.
 10

2.2.1 SDN Application Layer

Application layer is an open area to develop as many innovative applications as

possible by leveraging all the network information about network topology, network
state, network statistics, etc. There can be several types of applications which can be
developed like those related to network automation, network configuration and
management, network monitoring, network troubleshooting, network policies and
security. Such SDN applications can provide various end-to-end solutions for real
world enterprise and datacenter networks. Network vendors are coming up with their
set of SDN applications.

2.2.2 SDN Control Plane

SDN Controller is the Center of the SDN Architecture and the most important one of
SDN Architecture Components. In other words, the SDN Controller is the brain of the
system. The control of all the data plane devices are done via SDN Controller. It also
controls the Applications at Application Layer. SDN Controllers communicate and
control these upper and lower layers with APIs through Interfaces.
 11

2.2.3 SDN Data Plane

Data Plane consists of various Network devices both physical and Virtual. The main
duty of a data plane is Forwarding. In the previous traditional networks, both control
and data plane were in the same device. But with SDN, network devices only have
data planes. So, the main role of these network devices is only Forwarding the data.
This provides a very efficient Forwarding mechanism.

2.3 SDN & Edge computing, IoT and

Remote access
A variety of networking trends have played into the central idea of SDN. Distributing
computing power to remote sites, moving data center functions to the edge, adopting
cloud computing, and supporting Internet of Things environments – each of these
efforts can be made easier and more cost efficient via a properly configured SDN
environment. Typically in an SDN environment, customers can see all of their devices
and TCP flows, which means they can slice up the network from the data or
management plane to support a variety of applications and configurations, Capuano
said. So users can more easily segment an IoT application from the production world
if they want, for example. Some SDN controllers have the smarts to see that the
network is getting congested and, in response, pump up bandwidth or processing to
make sure remote and edge components don’t suffer latency. SDN technologies also
help in distributed locations that have few IT personnel on site, such as an enterprise
 12

branch office or service provider central office, said Michael Bushong, vice president
of enterprise and cloud marketing at Juniper Networks. “Naturally these places
require remote and centralized delivery of connectivity, visibility and security. SDN
solutions that centralize and abstract control and automate workflows across many
places in the network, and their devices, improve operational reliability, speed and
experience,” Bushong said.

2.4 SDN & Intent-based Networking

Intent-based networking (IBN) has a variety of components, but basically is about

giving network administrators the ability to define what they want the network to do,
and having an automated network management platform create the desired state and
enforce policies to ensure what the business wants happens. “If a key tenet of SDN is
abstracted control over a fleet of infrastructure, then the provisioning paradigm and
dynamic control to regulate infrastructure state is necessarily higher level,” Bushong
said. “Policy is closer to declarative intent, moving away from the minutiae of
individual device details and imperative and reactive commands.” IDC says that
intent-based networking “represents an evolution of SDN to achieve even greater
degrees of operational simplicity, automated intelligence, and closed-loop
functionality.” For that reason, IBN represents a notable milestone on the journey
toward autonomous infrastructure that includes a self-driving network, which will
function much like the self-driving car, producing desired outcomes based on what
network operators and their organizations wish to accomplish, Casemore stated.
“While the self-driving car has been designed to deliver passengers safely to their
destination with minimal human intervention, the self-driving network, as part of
autonomous datacenter infrastructure, eventually will achieve similar outcomes in
areas such as network provisioning, management, and troubleshooting — delivering
applications and data, dynamically creating and altering network paths, and providing
security enforcement with minimal need for operator intervention,” Casemore stated.
While IBN technologies are relatively young, Gartner says by 2020, more than 1,000
large enterprises will use intent-based networking systems in production, up from less
than 15 in the second quarter of 2018.

2.5 SDN & Security

SDN enables a variety of security benefits. A customer can split up a network
connection between an end user and the data center and have different security
settings for the various types of network traffic. A network could have one
public-facing, low security network that does not touch any sensitive information.
Another segment could have much more fine-grained remote access control with
software-based firewall and encryption policies on it, which allow sensitive data to
traverse over it. “For example, if a customer has an IoT group it doesn’t feel is all that
mature with regards to security, via the SDN controller you can segment that group
off away from the critical high-value corporate traffic,” Capuano stated. “SDN users
can roll out security policies across the network from the data center to the edge and if
 13

you do all of this on top of white boxes, deployments can be 30 – 60 percent cheaper
than traditional gear.” The ability to look at a set of workloads and see if they match a
given security policy is a key benefit of SDN, especially as data is distributed, said
Thomas Scheibe, vice president of product management for Cisco’s Nexus and ACI
product lines. "The ability to deploy a whitelist security model like we do with ACI
[Application Centric Infrastructure] that lets only specific entities access explicit
resources across your network fabric is another key security element SDN enables,".
A growing number of SDN platforms now support microsegmentation, according to
Casemore. “In fact, micro-segmentation has developed as a notable use case for SDN.
As SDN platforms are extended to support multicloud environments, they will be
used to mitigate the inherent complexity of establishing and maintaining consistent
network and security policies across hybrid IT landscapes,” Casemore said.

2.6 SDN & Cloud Computing

SDN’s role in the move toward private cloud and hybrid cloud adoption seems
natural. In fact, big SDN players such as Cisco, Juniper and VMware have all made
moves to tie together enterprise data center and cloud worlds. Cisco's ACI Anywhere
package would, for example, let policies configured through Cisco's SDN APIC
(Application Policy Infrastructure Controller) use native APIs offered by a
public-cloud provider to orchestrate changes within both the private and public cloud
environments, Cisco said. “As organizations look to scale their hybrid cloud
environments, it will be critical to leverage solutions that help improve productivity
and processes,” said Bob Laliberte, a senior analyst with Enterprise Strategy Group,
in a recent Network World article. “The ability to leverage the same solution, like
Cisco’s ACI, in your own private-cloud environment as well as across multiple public
clouds will enable organizations to successfully scale their cloud environments.”
Growth of public and private clouds and enterprises' embrace of distributed
multicloud application environments will have an ongoing and significant impact on
data center SDN, representing both a challenge and an opportunity for vendors, said
IDC’s Casemore. “Agility is a key attribute of digital transformation, and enterprises
will adopt architectures, infrastructures, and technologies that provide for agile
deployment, provisioning, and ongoing operational management. In a datacenter
networking context, the imperative of digital transformation drives adoption of
extensive network automation, including SDN,” Casemore said.

2.7 SDN & OPENFLOW

Openflow has been instrumental in the revolution of SDN in the sense that it has been
key to show-case separation of control plane from data plane. Openflow is the
standard specification provided by Open Networking Foundation (ONF), and is
evolving over the time with support for various requirements of current world
networking. Current version of the Openflow protocol is 1.5.1. Openflow is a protocol
which gives standard specification for communication between SDN controller and
network equipment (typically switches). It allows routing decisions to be taken by
SDN controllers and lets forwarding rules, security rules being pushed on switches in
the underlying network. SDN controllers and switches need to implement Openflow
 14

specifications so that they can understand the common language of Openflow

messages. To control network switches, SDN controllers will push rules into switches
so that they can take decisions when network traffic hits them. Switches need to
maintain such rules in the Openflow table. As per Openflow, such rules are called
‘flows’ and they are stored in ‘flow tables’.

2.7.1 Match Fields

Match fields will define criteria to match packets based on their header fields – L2
(source destination ethernet addresses, VLAN ID, VLAN priority, etc.), L3
(IPv4/IPv6 source destination address, protocol type, DSCP, etc.), L4 fields
(TCP/UDP/SCTP source destination port), ARP fields, ICMP fields, MPLS fields,
etc.

2.7.2 Actions

Actions will define what to do with a packet if it matches the criteria. Actions would
be like drop, forward on some port of switch, modify packet (push/pop VLAN ID,
push/pop MPLS label, increment/decrement IP TTL), forward to specific queue of
port, etc.

2.7.3 Counters

Counters are to keep track how many packets matched the flow .Openflow channel or
connection is a setup between switch and controller so that controller can
communicate with switch to configure, manage, and monitor it. As per Openflow
spec, Openflow runs on TCP or TLS connection and controller listens for connection
on 6653 port. Switch is expected to initiate the connection and should send connection
requests to the controller. Optionally, connection can be initiated from the controller
side as well, and for this case, switch will be in passive mode to listen for connection.
Be it from any side, it would be normal TCP or TLS connection setup, once it is
established, Openflow messages are exchanged over TCP or TLS connection. For
example, below is command of open source Openflow virtual switch (OpenVswitch)
to initiate TCP connection with controller

2.7.4 Openflow Working

​Openflow defines various messages to enable communication between switch and

controller, including connection setup messages, configuration messages, get switch
statistics messages, keep-alive messages, asynchronous events messages, error
messages, experimenter messages, and more.
 15

Let us understand briefly about Openflow messages:

Once a TCP connection is made, an Openflow HELLO message is exchanged

between both entities to negotiate an Openflow version on which further
communication will take place. It is needed as it may be possible that the switch and
controller are running on different Openflow versions. Both will agree on the highest
version supported. After version negotiation is done, the controller first sends
Openflow Feature request messages to mainly get the datapath ID of switch in
response message and to determine what features switch supports. To configure the
switch to handle network traffic, Openflow messages like flow entries can be sent
from the controller. These are maintained in flow tables inside switches. To group
flow entries, groups can be configured by controller through group messages that can
be stored into group tables inside switches. To get statistics details from the switch,
Openflow messages like flow stats, port stats, queue stats, group stats, table stats, etc.
can be sent from the controller. To check connection aliveness, echo request and reply
Openflow messages can be sent from either controller or switch. Asynchronous
Openflow messages like flow rule removal from switch, configuration apply fail error
from switch, port up/down status from switch, etc. can be sent from switch to update
controller. SDN core principle to separate control plane from data plane. Now we
need to see how controllers would be able to use Openflow to configure and manage
underlying networks.

Basically, the controller would need to implement some plugin code of Openflow by
which it can send, receive and understand Openflow messages to and from Openflow
switches in the underlying network. To configure Openflow switches, controllers need
to push flow rules into Openflow tables of switches based on which the latter can
handle network traffic hitting them. Openflow message for flow entries has large set
of tuple fields for matching criteria (L2, L3, L4 fields, etc.) of packets coming from
network, which altogether would help in configuring ACL rules, security policy rules,
QoS rate limiting bandwidth rules, routing rules, port mirroring rules, and packet
modification rules. To monitor Openflow switches, Openflow provides various
request and response messages to fetch switch and network statistics information and
 16

events messages to update controllers about manual changes or failures occurring at

switch side, including flow removed event, port status UP/DOWN changes, and more.
To perform some vendor specific tasks on Openflow switches, Openflow provides
experimental messages wherein vendors have freedom to define message body and
exchange custom information between controller and switches. That is how Openflow
is being used by many SDN applications to provide solutions for easy network control
and management.

2.7.4.1 OpenFlow Flow Table Memory Management

The switch flow table is limited and cannot accommodate all required forwarding
entries. Several proposals were made to improve the efficiency of the limited flow
table as illustrated in Figure below. Some works proceed to manage flow table rules
by setting an adaptive timeout mechanism. Other solutions consider reducing the size
of the table based on the concept of aggregation. Some work focuses on splitting rules
and distributes over the network in a way that satisfies policies according to the
device capacity. Rule caching is another method to limit the number of concurrent
forwarding rules in switch and reduce overhead switch to the controller. Machine
learning techniques are quite effective to predict the traffic flow pattern and select the
right flow to be installed in the switch flow table. These proposals are detailed in the
following sections.

2.8 SDN Performance Challenges

Below Figure presents the SDN performance challenges. This was derived from
several combinations of search key terms for SDN, OpenFlow, flowtable, update, and
security threats from various scientific academic research libraries, which include
ACM Digital Library, IEEE Xplore, ScienceDirect, MDPI, Springer. Different
 17

flexible search key terms were used in these websites to retrieve papers related to
SDN performance challenges. The year of publication was filtered from 2015 to 2020,
papers were chosen within the specified period as summarized in Table 1. After
scanning, the selected papers totaling to 3905 are shown. It was further shortlisted and
categorized into controller overhead, security vulnerabilities, switch flow table update
operation, and flow entries management.

2.8.1 Communication Overhead

DevoFlow and DIFANE are the state-of-the-art works to reduce the overhead of the
controller by reducing the high volume of messages exchanged between the switch to
the controller. DEVOFLOW aimed to reduce the communication overhead,
switch—controller using fine-grained wildcards to improve the network-wide
visibility of the controller. The mechanism leverages on rule cloning, thereby
delegating some of the control function to switches to act locally in a way that the
controller preserves the central network intelligence. DEVOFLOW modified the
action field with CLONE flag, flag clear value signifies normal forwarding otherwise
locally clone wildcard rule. The cloning helps to process short live flows such as mice
flow without the need to consult controllers, hence, reducing the controller overhead.
DIFANE presents a new architectural scalability solution built on the OpenFlow
switch. The scheme maintains all traffic in the data plane by selectively distributing
packets through intermediary switches called authority switches. These intermediary
switches handle entry table-misses at edge switches, hence, reduce the need to invoke
messages to controllers. However, DIFANE and DEVOFLOW may require more
complex software and hardware than conventional OpenFlow switches, which
increases the cost of the device. Moreover, the fundamental principle of OpenFlow is
to delegate all intelligence functions and control to the OpenFlow controller,
therefore, such schemes violate this principle. Conversely, Favaro et al. introduced a
blackhole mechanism to reduce switch to controller overhead while maintaining the
benefit of the visibility for every new flow. Packet processing architecture is modified
where only the first packet is forwarded to the controller while subsequent table-miss
will be handled locally. In this way, the number of events sent to the controller is
reduced. Although the use of blackhole has reduced controller consultation, it inherits
weakness by its architectural design to drop notified packets, which may significantly
result in a large number of packet losses.
 18

2.8.2 Flow Rule Update Operation

TCAM is designed for high-speed packet lookup matching instead of fast flow entry
updating time in the switch flow table. Rule updates are often required to adapt to the
dynamic nature of network traffic patterns, especially in large-scale networks. During
the update process, the controller instructs switches to add, modify, or delete some of
the flow rules used to forward packets. For example, in Figure below, the arrival of
new flow in the switch flow table will require the firmware to examine whether it is
the first entry in the flow table or not. The first entry will be installed straight away
without further processing and priority order is maintained. For the case of subsequent
entries, the switch firmware will get an appropriate position in the flow table,
afterward, it will compare the priority with the existing entries, if the priority is
higher, entry will be installed or entries will be moved down and comparison
continued. In this way, the higher usage of TCAM, the greater the number of entry
movements. This method is referred to as priority base solution, which is the naïve
solution to handle update operation and is widely used to implement OpenFlow
switches. The process should be carried out safely and efficiently without service
disruptions and network resources consumption (bandwidth and switch memory).
However, in dynamic and large-scale network traffic conditions, flow rule updates
become more complex because of the need to re-order the existing flow entries. These
operations take some time to complete depending on the current memory status and
are computationally difficult, regardless of the controller entries configuration mode
being in either reactive or proactive mode. An experiment shows the time to install a
single rule after the occurrence of table miss, update cost from 5 milliseconds (ms) to
100 ms. The time required to update TCAM is a non-linear function of the current
number of rules. Adding 500 rules takes about 6 s, however, the next 1500 rules take
almost 2 min to install.
 19

2.8.3 SDN Security Threat and Vulnerabilities

The noble idea of placing the network control logic at the central controller provides
flexibility, optimizes network management, and flow monitoring, which is very
important in the practical usage of SDN. Considering the SDN flexibility, it is
expected that the potentialities of SDN could mitigate some security threats and
vulnerabilities that were inherited in the traditional network. Unfortunately, SDN
introduces another security threat and vulnerabilities due to its novel architecture. At
least five threat vectors were identified with SDN. This includes attacks on
vulnerabilities on SDN protocol, the central controller, underlying switches, forged
legitimate traffic flows, and trust mechanism. Trust mechanism is very important in
deploying applications, overlooking it may easily cause malicious applications to be
developed and deployed on the controller. It may further affect the detection of an
event such as link failure in order to ensure fast recovery. In general, the most
important threat vector is denial of service attack against the switch flow table and
central controller. For example, the central controller must have full control of the
network state at a regular time interval to verify the network functionality and state. In
this case, the controller is required to receive an update from the switch more
frequently. An attacker can leverage on the central entity to perform the DoS attack by
forcing the switches to continuously update the controller with a fake update, which in
turn consumes a lot of resources that the switch may use to process legitimate flows.
Similarly, because of the limited memory resources (TCAM), an attacker aggressively
creates a large number of new traffic flows that might overwhelm the precious flow
table of the switches. In such a situation, the switches will be forced to continually
add and delete flow entries, which may generate excessive packet-in message events
to the controller. Consequently, the packet-in event will be stuck in the controller
queue as there would be no more routing decisions taking place for every new
incoming flow. In this case, flow with no corresponding entries will be stuck in the
switches. Concerning the protocol vulnerability, the widely used OpenFlow suffers
from unexpected shortcomings during its design and evolution. Discarding the
transport layer security during the message exchange between controller and switches
at the feature’s verification stage was the greatest flaw. Man-in-the-middle attacks
may leverage on such an operation to compromise the network. Similarly, exchanges
of messages between switches lack the authentication/encryption mechanism in the
SDN data plane. Toward addressing the aforementioned security challenges, efforts
were made lately to address several SDN security attacks.

2.9 SDN Benefits

It’s also important to clarify when a network might be using too many devices. Given
that every network has a precise level of support it can provide, issues may arise if
this capacity is being too strained with an excessive volume of devices. Too many
devices can easily lead to a network that is receiving a surplus of requests for data.
Traditional techniques of load balancing have limitations in flexibility and
adaptability. The increase in cloud usage requires more rapid allocation of resources
that an SDN-based load balancer is best equipped to handle. It can manage massive
 20

traffic flows by using virtual switching technology instead of traditional hardware

switching technology. SDN controller load balancing monitors the data throughput of
each port using variance analysis and then redirects traffic accordingly. This serves
users with greater scalability, higher reliability and lower cost.

The technique chosen will depend on the type of service or application being served
and the status of the network and servers at the time of the request. This is possible by
the methods of decoupling or disassociation of the system that helps in making
decisions about where the traffic is being delivered from the systems which then
forwards this traffic to the required destination. Load balancing is the method in a
computer network that is used to divide the amount of work between a collaboration
of two or more computers in such a way that work can be completed in the same time
limit. Hardware, software, or a combination of both can be used to implement load
balancing.

Software-Defined Networking (SDN) plays an important role in paving the way for
effectively virtualizing and managing the network resources in an on demand manner.
Still, many research challenges remain. To utilize resources effectively, this project
focuses on the server-side load-balancing issue and increases the performance for a
cluster of servers with different processing capabilities. Software-defined networking
(SDN) load balancing includes the following benefits:

● Lower cost
● Greater scalability
● Higher reliability
● Flexibility in configuration
● Reduced time to deploy
● Automation
● Ability to build a network without any vendor-specific software/hardware.
 21

Chapter 3 System Design and Architecture

3.1 System Architecture

The network architecture will consist of an OpenFlow switch with an SDN

controller, three servers and six hosts connected to the ports of the OpenFlow switch.
Static IP addresses will be assigned to each server. A list of live servers connected to
the switch will be maintained by the controller. OpenFlow switch addresses
bottlenecks to high performance and scalability in SDN environments. MININET
will be used to simulate the network environment. VM VirtualBox will be used to run
the virtual machine on a Macbook Pro host machine with 2.5GHz processor and 4 GB
RAM running macOS Mojave operating system. POX and Ryu controllers will be
used as SDN controllers. Openload will be used as a tool to test the performance of
the load balancer. VMWare will be used to run the virtual environment.

3.1.1 Open Flow

At the core of the SDN technology is the OpenFlow protocol, and SDN with
OpenFlow switch promises flexibility and fast configuration of communication
networks. OpenFlow is a programmable network protocol for SDN environments,
which is used for communication between OpenFlow switches and controllers.
OpenFlow separates the programming of network devices from underlying hardware,
and offers a standardized way of delivering a centralized, programmable network that
can quickly adapt to changing network requirements. The OpenFlow switch
communicates with the controller and the controller manages the switch via the
OpenFlow switch protocol. They are based on the OpenFlow protocol. This Openflow
switch will be connected to three servers, and also six of the ports will be assigned to
different hosts. The host count that was set for this project was six, as this ideal for
simulating an envrionment to achieve load balancing. OpenFlow is a programmable
network protocol for SDN environments, which is used for communication between
OpenFlow switches and controllers. OpenFlow separates the programming of network
devices from underlying hardware, and offers a standardized way of delivering a
centralized, programmable network that can quickly adapt to changing network
requirements. As shown in the below figure.
 22

An OpenFlow switch is an OpenFlow-enabled data switch that communicates over

OpenFlow channel to an external controller. It performs packet lookup and forwarding
according to one or more flow tables and a group table. The OpenFlow switch
communicates with the controller and the controller manages the switch via the
OpenFlow switch protocol. OpenFlow switches are either based on the OpenFlow
protocol or compatible with it.
 23

3.1.1.1 Openflow VS Conventional Switch

In a conventional switch, packet forwarding (the data plane) and high-level routing
(the control plane) occur on the same device. While for an OpenFlow switch, the data
plane is decoupled from the control plane: with the data plane implemented in the
switch itself but the control plane in software and a separate SDN controller makes
high-level routing decisions. The switch and controller communicate by means of the
OpenFlow protocol. OpenFlow switch hence boosts the following advantages:

● With OpenFlow switch, the SDN controller could route non critical/bulk
traffic on longer routes that are not fully utilized.
● The SDN controller can easily implement load-balancing at high data
rates by just directing different flows to different hosts, only doing the
set-up of the initial flow’s.
● Traffic can be isolated without the need for vlan’s, the SDN controller of
OpenFlow switch can just refuse certain connections.
● Setup a network TAP/Sniffer easily for any port or even specific traffic by
programming the network to send a duplicate stream to a network
monitoring device.
● OpenFlow switch allows for the development of new services and ideas
all in software on the SDN controller, as well to accelerate new features
and services.

3.1.2 POX SDN Controller

POX provides a framework for communicating with SDN switches using
OpenFlow. POX started life as an OpenFlow controller, but can now also function as
an OpenFlow switch, and can be useful for writing networking software in general. It
currently supports OpenFlow 1.0 and includes special support for the Open
vSwitch/Nicira extensions. POX controller is also used for faster development. POX
controller comes pre-installed with mininet virtual machine. In this design, the
controller has a global view of the network and controls the flow through the
network. Initially, the flow table of the switches is empty. When a packet arrives at a
switch, it does not know how this packet is to be handled. Then it sends a
packet-in message to the controller. To handle the packet, the controller inserts
flow entries in the flow table of the switch.
 24

3.1.3 Ryu Controller

Ryu Controller is an open, software-defined networking (SDN) Controller
designed to increase the agility of the network by making it easy to manage and adapt
how traffic is handled. For simulation purposes, both Pox and Ryu controllers will be
used. The Ryu Controller provides software components, with well-defined
application program interfaces (APIs), that make it easy for developers to create new
network management and control applications. This component approach helps
organizations customize deployments to meet their specific needs; developers can
quickly and easily modify existing components or implement their own to ensure the
underlying network can meet the changing demands of their applications.

3.1.4 Mininet
Mininet provides an extension for Python developers. Mininet enables SDN
development on almost any machine. Mininet networks run real code including
standard Unix/Linux network applications as well as the real Linux kernel and
network stack. Mininet provides an extensible Python API for network creation and
experimentations. Many developers these days opt for mininet due to its various
advantages over other utilities. It supports system-level regression tests, which are
repeatable and easily packaged and is based on plug n play method without the need
of programming, and hence making it a great tool for network creation and
experimentation. Compared to other simulators, it easily connects to real networks.

3.2 Input and Output Parameters

The objective of this project is to compare the performance of an SDN based

load balancer implemented based on two main factors, i.e. method of selecting the
server to direct traffic and the type of SDN controller. Three methods of selecting the
server to direct traffic will be tested. They are round robin based server selection,
random selection of server and selection of a server based on the current server load.
Two types of SDN controllers will be tested. They are POX controller and the Ryu
controller, both of which are Python based. Transactions per second and average
response time will be measured as output parameters using the Openload tool.
 25

3.2.1 Round Robin based server selection

A round robin is an arrangement of choosing all elements in a group equally in
some rational order, usually from the top to the bottom of a list and then starting again
at the top of the list and so on.

3.2.2 Random selection of server

Random selection is a precise, scientific procedure whereby each unit in a
population has an equal chance of selection for inclusion in a sample

3.2.3 Selection of server based on current workload

In this specific selection method, underlying conditions will be examined, and
priority will be given to overloaded servers.

3.3 Methodology for this Project

Incremental methodology was selected for our project. The basic idea behind
this method is to develop a system through iterative repeated cycles and in
incremental smaller portions at a time), allowing to take advantage of what was
learned during development of earlier parts or versions of the system.

1. Incremental methodology will be used for the project because of the following
reasons:
2. Working software is obtained quickly and early during the software lifecycle.
3. Risk management becomes easier because erroneous parts of the software are
identified at each iteration.
4. Smaller iterations enable easy testing and debugging.
5. Flexibility of the model provides low cost if scope and requirements are to be
changed.

3.4 Load Balancing Simulation

The load balancing simulation starts off with loading the defined set of servers
into memory. For each server there is, it is assigned a unique IP address. When the IP
addresses have been assigned, the load balancer simulation is set for execution. The
 26

network is created, the controller is connected. Also, hosts, switches, links are added.
During this time, all of the servers are up and running and listening to incoming
requests.

The number of servers that can be assigned to test simulation is variable, so

this constant can be altered as per requirements. Our network includes 8 hosts and a
switch with an OpenFlow controller (POX). Using POX library, core is the main
package being used. Furthermore, addresses and arp packages are also used. A
dictionary maintains the hit counts for each of the servers. This helps to maintain load
balancer mapping.

The first 4 hosts h1 to h4 act as clients for a service offered by the hosts and
h5 to h8, which act as servers. The switch acts as a load balancer, and balances the
flows from the clients towards the servers.The clients are addressing the Virtual IP of
the service, and the switch acts as a transparent proxy between the clients and the
actual server.

The load balancer is served as a simple class object which is capable of

handling multiple connections opened up with the servers. It also sends out proxied
arp replies and proxied arp requests. ARP is an Address Resolution Protocol which is
used for communication at the link layer. Furthermore, the count of requests is also
maintained. Flow rules are defined for bi-directional communication between client
and server i.e. flow rule from client to server and flow rule from server to client. At
the very start, load balancer is assigned an IP known as service IP.

Mininet will be used to simulate the test environment. Mininet hosts run
standard Linux network software, and its switches support OpenFlow for highly
flexible custom routing and Software-Defined Networking. It provides a testbed for
network applications. We used the mininet as a CLI tool for our testing, and the code
was executed within. This mininet will be run within a virtual machine (VMware).

The load balancer keeps track of requests from servers and the ports. It
handles two types of requests i.e. ARP type and IP type. Based on these requests, it
further categorizes them into Request type and Reply type. In order to efficiently
distribute the load among servers, random technique is used. Whenever a request is
processed, the count is also updated in the load balancing mapper so that when the
next request comes in, a decision can be made on the basis of server load. For the
calculation of random allocation of servers, python package numpy has been used. If
any live servers are up, return the live server as the next server on random server
technique. It will also calculate the mappings from load balancer to make a decision.
Apart from this Python’s built in package random and matplotlib is used as well.
Plotting function was also added to summarize the results of the program.

All the samping is carried out using this simple formula. Divide the servers into
 27

non-overlapping groups (i.e., strata) N1, N2, N3, …, Ni, such that N1 + N2 + N3 + …
+ Ni = N. Then do a simple random sample of f = n/N in each strata.

In the diagram below, it can be seen that the openflow switch is connected to the
servers and clients whereas the POX controller acts as a load balancer. The openflow
switch is the medium between load balancing and clients/servers. The following IPs
will be assigned to the hosts and servers in this order:
h1 10.0.1.2
h2 10.0.1.3
h3 10.0.1.4
where h1, h2 and h3 are servers.
h4 10.0.1.5
h5 10.0.1.6
h6 10.0.1.7
h7 10.0.1.8
h8 10.0.1.9
h9 10.0.1.10

and h4, h5, h6, h7, h8, h9 are clients. The requests are generated from HTTP clients,
and then the algorithm that is fed to POX controllers comes into action. For random
server technique, any random server is chosen to execute the request and then respond
to the client accordingly. This is to avoid traffic congestion and choking of network
traffic and to ensure high availability of servers.
 28

Chapter 4 Result

A basic load balancer was simulated in MININET to test the basic functionality. It
consisted of three HTTP servers, six HTTP clients (hosts), OpenFlow switch and a
POX controller as explained in details in previous chapters. VMware had been used to
run the virtual environment in this project, along with a mininet emulator which was
used to simulate the network environment.

The screenshots given below demonstrate the running network simulation. We have
used random techniques to manage the traffic on the servers, and for testing purposes,
we have sent 1000 packets to the load balancers and it manage the traffic among four
servers.
29
30
31
 32

Chapter 5 Conclusion

After obtaining the output parameters, the most efficient method of server selection
that yields the highest performance of the load balancer can be determined. The
suitability of the Ryu controller can be assessed. Based on the results of the
simulation, the most suited controller that yields the best performance of the load
balancer from POX and Ryu controller can be determined. An overall idea of the
complexity of the controllers can also be obtained.

Software-Defined Networking (SDN) plays an important role in paving the

way for effectively virtualizing and managing the network resources in an on demand
manner. Still, many research challenges remain. To utilize resources effectively, this
project focuses on the server-side load-balancing issue and increases the performance
for a cluster of servers with different processing capabilities.
 33

References

[1] Steve Mann. Humanistic Computing: “WearComp” as a New Framework and Application
for Intelligent Signal. Proceeding of the IEEE, 1998[C]. USA.IEEE, 86(11): 2123-2151
[2] Len Bass, Chris Kasabach, Richard Martin, Dan Siewiorek, Asim Smailagic, John
Stivoric. The Design of a Wearable Computer. Proceedings of the 1997 Conference on
Human Factors in Computing Systems, 1997[C].Atlanta,GA,USA. ACM: 140-146