Round Robin Load Balancer using Software Defined
Networking (SDN)
Capstone Team Research Project
April 22, 2016
Deep Gajjar
Harsh Kotak
Hardik Joshi
Dharmesh Mithbavkar
Interdisciplinary Telecom Program
University of Colorado Boulder
AbstractIn a data center environment, the load balancer is
an integral part of the networking ecosystem. The primary
function of a load balancer is to distribute traffic among a cluster
of servers such that a single server does not become over-utilized
and ensure that critical services keep running. The algorithm,
embedded functions, and network equipment vendor used to
implement and manage a load balancer has an impact on its cost.
Additional costs are imposed when hiring professionals who are
skilled in the vendor-specific configuration. Software Defined
Networking (SDN) offers a cost-effective and flexible approach in
implementing a load balancer. Moving away from traditional
hardware-based networking approach, this project implements
load balancing with the help of software. The new SDN approach
reduces the cost, offers flexibility in configuration, reduces time
to deploy, provides automation and facilitates building a network
without requiring the knowledge of any vendor-specific
software/hardware.
KeywordsApplication Programmable Interface (API), Load
Balancer, Mininet, Network Functions Virtualization (NFV),
OpenFlow, POX, Python, Round Robin, Software Defined
Networking (SDN), White-box switching.
I. INTRODUCTION
Software Defined Networking (SDN) is a new approach to
facilitate network management that has been gaining
widespread attention. Traditional networking involves buying
the hardware and software together from a vendor and
configuring them as per the requirements. In traditional
networking, it is not possible to separate the data plane from
the control plane. Therefore, the customer had to rely on the
vendor for software bug fixes, additional features, and licenses.
It is not possible for the customer to modify the vendor
software code as per needs of the network. The proprietary
nature of most vendor software leads to slowed innovation and
increased delay in deployment of new services. SDN tries to
eliminate this vendor dependence and is a paradigm shift from
closed vendor-specific networking to an open networking
system. In SDN, a centralized controller deploys network flows
in the bare-metal network switches. Therefore, the hardware
1
Dr. Levi Perigo
University of Colorado Boulder
Jason Schnitzer
Applied Broadband
for networking devices is available at a lower price and the
software configuration can be modified as per needs of the
customers. This generic piece of hardware can be programmed
using an Application Programmable Interface (API) or
installation of any Network Operating System (NOS). Some of
the protocols used to network configuration are OpenFlow and
NETCONF. OpenFlow enables the SDN controller to
communicate with networking devices. Similarly, NETCONF
protocol enables network configuration and automation using
Yet Another Next Generation (YANG) as a data modeling
language. The unbundling of hardware and software
considerably reduces costs as networks grow. Through the use
of unbundling, the customer can program the flows as per
requirements of the network. The project aims to implement a
round robin load balancer to install flows in a white-box
network device from the controller. By using SDN, the cost of
having a dedicated vendor specific load balancer is reduced,
vendor dependence is eliminated, and flexibility in terms of
modification of the code is achieved.
II. RESEARCH QUESTION AND SETTING
Web browsing utilizes a client-server model where a client
requests data from a server and the server responds. Depending
upon the type of service delivered, there can be millions of
connections to the server at any time. In this case, it is
necessary to ensure that the critical services like money
transfer, online examinations, and business transactions are
reliably delivered. A load balancer is a device which serves a
key role in delivering these services and keeping the network
infrastructure running. As shown in figure 1, the load balancer
is installed between the client and the server. The load balancer
attempts to distribute client requests among the cluster of web
servers efficiently [1]. This allocation helps improve
performance and reduce the possibility of a server being
overloaded. Certain load balancers also provide failover
capabilities. If a server fails, the load balancer provides fault
tolerance by directing the requests to the remaining servers [2].
Several companies manufacture dedicated load balancers like
F5 Networks, A10 Networks, Kemp technologies, and
Barracuda Networks [3]. Different load balancing algorithms
are available such as round robin, weighted round robin, server
CPU utilization based, and IP-based hashing. A round robin
load balancer distributes the client requests among the servers
one-by-one. For example, the 1st client request is forwarded to
server 1, 2nd request to server 2 and so on.
Fig. 1: Round Robin Load Balancer
In a large network, the load balancer has advantages
such as delivery and reliability of critical services.
Unfortunately, the cost of buying a dedicated load balancer
could be as high as $30,000 per device [4]. These costs can be
a financial constraint for companies in managing the network.
In a large network, a greater number of load balancers are
required and hence the cost for this network grows. Additional
expenses are imposed in terms of receiving support and hiring
trained professionals for the vendor specific equipment.
Network administrators have to rely on the vendor for
software bug fixes, release of new features, and
standardization of protocols. These constraints result in a
delay in deploying new services. Another problem in buying
dedicated service networking equipment is that it does not
offer flexibility in terms of configuration. Open source
controller, such as POX is used to deploy network flows. For
example, the POX controller platform could be used to
migrate the load balancing algorithm from round robin to an
IP-based hashing method. In contrast, the attaining flexibility
could be difficult in vendor specific equipment and usually
depends on the configuration options available and associated
licenses.
The research question aims to identify whether an SDN-
based load balancer can reduce the costs of traditional
networking and provide flexibility in configuring load
balancers in order to achieve higher efficiency and to
determine whether automation provided by SDN can be
utilized in current data center environments.
III. RESEARCH SUB-PROBLEMS
The following sub-problems were identified to answer the
research question:
2
A. Are there any sections in our research project where we
could save the costs of implementations for end
customers?
As networks grow in size, the cost to manage them
increases accordingly. The price for a state-of-the-art
hardware-based load balancer can be as high as $80,000 [4].
For example, F5 networks LTM-4200v is an enterprise grade
load balancer used widely in the industry whose cost is
$60,990 [5]. For a company with limited resources, this cost
can be prohibitive. In this scenario, SDN offers a cost-effective
alternative. Through the use of SDN, any company can invest
in white-box equipment and deploy flows from an SDN
controller to configure the white-box to behave as a load
balancer. White-box equipment is off-the-shelf hardware that is
based on generic merchant silicon chipsets and is available to
buy as opposed to the proprietary silicon chipsets designed and
sold by a single networking vendor [6]. Examples of
companies selling white-box equipment are Accton, Pica8, and
Quanta Computer. Broadcoms Trident 2 switching silicon is
the Application-Specific Integrated Circuit (ASIC), which is
used in many vendor-specific hardware. Accton's AS white-
box is also built on Trident 2 ASIC [7]. The price for the ASIC
starts at $8,898 and includes a one-year subscription to a
Network Operating System (NOS) known as Cumulus Linux
[7]. The price for the NOS is $999 for an additional year of
licensing and 24/7 support. As described earlier, the price of
hardware-based load balancer can be as high as $80,000. Thus,
SDN can help realize savings in Capital Expenses (CapEx) and
Operational Expenses (OpEx). These savings can increase as
the SDN industry matures and standardization of protocols is
achieved. Research carried out by Deloitte on use cases of
Software Defined Data Center (SDDC) for Fortune 50 clients
revealed that moving existing systems to SDDC can reduce
costs up to 20% [8]. Therefore, the cost of implementation of
the network could be reduced if the sub-problem of cost is
solved.
B. Could vendor-independence add the required flexibility to
the research project approach?
When an enterprise invests in any vendor specific
equipment, it has to incur an additional cost for hiring trained
professionals who can configure and operate that equipment.
The company may also have to pay the vendor to provide the
required training to their engineers to integrate the equipment
with the existing network. The enterprise has to incur
expenses for a service level agreement to the vendor for timely
support for providing technical assistance during downtime
and dealing with equipment failures. Apart from the warranty
or liabilities, the company has to pay the vendor for software
updates to get new features for their network. Moreover, the
company has to ensure that the current devices and the
networking equipment it may purchase in the future are
interoperable with the vendor proprietary solution. In contrast,
SDN offers a robust approach to programming the network
equipment the way the network demands in any programming
language. Vendors such as Arista Networks, Big Switch
Networks and F5 Networks support OpenFlow, a protocol
used to configure flows, flow tables, and Ternary Content
Addressable Memory (TCAM). Thus, SDN-based open source
solutions that adhere to the open standards would be
interoperable with other devices and eliminate the need for
vendor-specific training. There are controllers available in
different platforms like Java, C, and Python for an enterprise
to choose based on its current resources without the need for
additional training. Consequently, finding an answer for
vendor independence will play a vital role in completing the
research question.
C. Will the SDN approach reduce the time to deploy round-
robin load balancer as compared to traditional networking
approach?
The enterprise has to depend on the vendor not only for the
initial equipment delivery, but also for additional releases of
new features and software bug fixes. An enterprise has to
make its business decisions based on the timeline provided by
the vendor. It would not have any flexibility to adjust any of
the solutions and features offered by the vendor. Companies
that want to implement new algorithms, protocols, and
features in their network are reliant on the vendor timeline
which could delay the deployment of new services. Moreover,
security vulnerabilities and flaws may arise in the vendor
solution which might need a quick patch. Through the use of
SDN, the customer does not have to rely on the vendor and
can even customize or develop their own protocols using any
programming platform. The company can also fix security
vulnerabilities quickly to ensure the expedited resolution. As
SDN supports an open networking system and since SDN has
a growing online support community, new features could be
easily added.
There are many ways to implement a load balancer in SDN
using various programming languages. The code can be
implemented in any programming language such as Python,
Java, and Perl which supports different libraries. By using
different libraries, the goal can be achieved quickly by the
network administrator. Thus, the realization of the time saved
will be crucial in the deployment of the research project.
D. Will the SDN-based load balancer offer flexibility in
deployment?
Several algorithms or techniques of load balancing are
available. Some of the examples are round robin, weighted
round robin, the fastest node selection, IP-based hashing, and
multi-tier round robin. SDN allows flexibility to install the
company defined software on a white-box switch. By using
SDN, the existing equipment can be programmed to suit the
needs of the network and thus reduce deployment and
management costs. In the data centers, different end customers
may implement different load balancing algorithms depending
on the number of servers available, the availability of
resources on the servers, and peak hour for traffic.
Consequently, flexibility to tailor the implementation is a
crucial part of the research problem.
3
IV. LITERATURE REVIEW
SDN is programming the network. As shown in figure 2,
the data plane and the control plane are separated [9]. A
centralized controller manages the networking elements and
deploys network flows in them. Higher level applications such
as firewalls, Content Delivery Networks (CDNs), Carrier
Grade Network Address Translation (NAT), load balancers,
and WAN accelerators can be built on the top of the control
plane. As shown in figure 2, the OpenFlow protocol is used for
communication between the controller and the switches.
Fig. 2: A central SDN control layer manages the underlying networking
devices and higher layer applications can be built on top of it.
SDN has several advantages over traditional networking. It
reduces expenses by investing in relatively inexpensive generic
hardware rather than vendor-specific ASICs. SDN reduces the
time-to-market by eliminating vendor dependence and by using
APIs. It provides the tools for automating a number of trivial
tasks and reduces the time to service and sustain the network
[9]. SDN helps create a network infrastructure that is agile and
quick to adapt to changes, which makes troubleshooting easy.
SDN also provides the flexibility to add new features to the
existing infrastructure whenever required. Through the use of
SDN, the customer does not have to rely on the vendor and can
develop their own protocols using any platform. As SDN
supports an open networking system, modifications of new or
existing services can be easily done because of community
support.
To manage flow control in an SDN network, an application
would be needed that installs the flows on the SDN controller.
The SDN controller acts like an operating system or the brain
for the entire network. It manages the communication between
applications and network devices [10]. Thus, an SDN
controller is a program which manages the control plane and
facilitates network automation. It does this by using protocols
like OpenFlow and NETCONF/YANG to configure and
manage the network devices and relay the information back to
the applications [11].
 Different networking vendors provide their own SDN software running on a machine or using dedicated hardware-
solutions which work with their networking devices. Vendors based devices. As mentioned by [14], Windows NT/2000,
like Cisco, Juniper, HP, IBM, Big Switch Networks, and Resonate, and Red Hats high efficiency server provides
VMware have custom SDN controllers built for networking software-based load balancing. Cisco, F5, Juniper, and Big
devices. Apart from that, there are a few open source Switch provides switching-based hardware devices which
controllers which can be used by administrators [11]. perform load balancing functionality. Currently, all service
providers use hardware-based load balancer in consideration of
SDN controllers have evolved since the onset. Commercial
higher efficiency and better performance over software-based
solutions are usually hardware-based and would not be helpful
load balancers [14]. Based on the above information, it is quite
for the purpose of the project as the proposed solution aims to
obvious that service providers rely more on hardware than
minimize the cost by using open source solutions. Some of the
software, but the SDN-based approach will revolutionize the
popular open source SDN controllers are NOX, POX,
market of load balancers and change the way providers
OpenDaylight, and Floodlight [12].
perceive software-based load balancers. Load balancing, in
NOX was one of the first SDN controllers which was addition to efficient utilization of links, provides benefits of
developed for OpenFlow. NOX is not widely used because it is resiliency [14]. Failover is crucial for maintaining the system
difficult to implement as it needs to be programmed in C++ availability.
and it does not have sufficient documentation and community
Figure 3 shows a pool of servers attached to a load
support [12].
balancing device. Each server has the same content and it is
POX, a successor to NOX, was designed to be easier to part of the server cluster. When a request is received on a
implement by network engineers. Unlike NOX, POX is widely virtual IP address of the load balancer, it accepts the connection
used and is easier to work with as it uses Python whose code is and changes the destination IP to the IP address of one of the
often 3-5 times shorter than Java and 5-10 times shorter than
C++ [12]. It has good documentation on its API and also
provides a web-based Graphical User Interface (GUI). So,
using POX greatly helps in making our proposed load balancer
easier to configure and flexible enough to modify it according
to the requirements of the customers [12].
Another popular SDN controller being considered for the
project was OpenDaylight. OpenDaylight is a Linux
Foundation project and is supported by large companies like
Cisco, Juniper, and Big Switch Networks. It has pluggable
modules to configure the controller according to ones
requirements. However, the main disadvantage is that it is
written in Java and thus would require a comprehensive
understanding of Java to configure and deploy [12].
It is also important to understand that the SDN controller
communicates with the network nodes using standard protocols
like OpenFlow and NETCONF which are called Southbound
APIs, while the controller communicates with the high-level
applications using Northbound APIs. Northbound and
Southbound are not necessarily SDN terms and can be used
with any network system, but they are widely used in SDN Fig. 3: An example of a load balancer with server clusters. (Source: F5
industry because while drawing the SDN architecture or even Networks)
an enterprise data center, the applications are usually drawn at
the top (north), while the different network devices are at the servers [15]. After receiving a request from the load balancer, a
bottom (south) [13]. server sends a reply with the destination IP address as the IP
address of the load balancer. Then, the load balancer intercepts
Traffic surges in the network can result in congestion of a the return packet from the server and changes the source IP
link, which in turn jeopardizes applications and services address to match the virtual IP address and sends to the host
offered by providers from the web servers. The problem [15]. This is the basic process of how a load balancer works in
continues to persist even if they have redundant links to reach a real time network. Now, the question arises regarding how
the servers. Load balancing algorithms address this issue of the load balancer decides which server is to be used for sending
underutilization and overutilization of the links. Load a query. It depends on the load balancing algorithm.
balancing techniques allow a network administrator to
maneuver algorithms to distribute traffic equally among all There are several load balancing algorithms available for
available links. Load balancing can be performed using a the load balancer to distribute traffic among the servers. Some

4
of the different types of load balancing algorithms are round-
robin, weighted round-robin, hashing based, and URL based.
The round-robin load balancing algorithm is popular and
simpler than the other algorithms.
The round robin load balancing algorithm does not consider
any state of the traffic and is classified as the static algorithm.
Traditional round robin uses a circular register and pointer to
the last selected server to make dispatching decisions, that is, if
Si was the last chosen node, a new request is assigned to Si+1,
where i = (i+1) mod N and N is the number of server nodes
[16]. The advantages of the round robin algorithm are the ease
of management and its efficient operation. In addition to this,
load balancing devices do not need significant memory and
CPU resources to perform load balancing compared to other
algorithms.
Rather than using a simple round robin algorithm, Xu
Zongyu and Wang Xingxuan have provided some suggestions
which include maintaining stateful information of traffic flow
and modifying the circular pointer mechanism [16]. Hash-
based load balancing is the most popular stateful algorithm
being used. The hash value for a particular traffic flow is
calculated based on the source IP address, destination IP
address, source port number, destination port number, and
URL. The hash value can be a combination of two or more
parameters to identify a particular flow. The load balancer
forwards the request to the server with the highest hash value,
created using a combination of different parameters of packets
[17]. Any further requests with the same hash value are sent to
the same server and hash values are usually cached for a certain
amount of time. This algorithm creates unique hash values for
the same type of traffic i.e. requested by the same host. But,
when only one host is requesting a lot of contents and
congesting the link, the hash-based algorithm fails to distribute
the load across multiple links. The reason for the failure is the
inability of the load balancer to generate different hash values
for traffic generated from the same host and destination. In this
case, the round robin algorithm provides efficient load
balancing mechanism.
Shie-Yuan Wang compares Estinet and Mininet virtual
network environments in his paper which was imperative in the
researchers decision making process [18]. The paper defined
the differences between the two and why one should use
Mininet over Estinet. The popular Floodlight OpenFlow
controller was used by researchers in that paper. The
experiments were performed over a grid of NxN networks
where N ranges from 5 to 31. They also found that Mininet
demonstrated some strange results that cannot be explained
over large network sizes. These large network sizes are beyond
the scope of the project. Mininet was found to be easier to
work with as compared to Estinet. The paper also had
experiments which dealt with performance evaluation. The
performance evaluation included factors such as program
launch, network setup and resource releasing when network
size is large. Thus, Mininet is the ideal option considering the
network scale of the project.
5
R. de Oliveira et al describes the use of Mininet for
emulation and prototyping SDN [19]. This research paper
properly introduced Mininet. According to the authors, some
factors which give Mininet the advantage are the flexibility in
adding new configurations and maintaining the network using
software programming languages. The paper also discusses the
capability of Mininet to imitate the virtual environment into the
physical implementations. Mininet assists in sharing the
prototypes with other engineers and designers working on
similar research projects.
Oliveira also describes a method to test the virtual network
components and its associated protocols. The authors also
provide the details of the time spent by Mininet in creating and
destroying different network topologies. For example, the
research states that Mininet took approximately 64 seconds to
create a tree topology with 255 nodes [19].
Advanced implementation in Mininet was understood
through the research paper by Chandan Pal et al [20]. It
describes the type of topologies supported by Mininet in a
single IP network. The paper also provides a topology
framework for creating custom network designs based on the
project requirement. The section in the paper which describes
the creation of different broadcast domains is written for
amateur engineers to understand. The research makes use of
the experiments and results obtained in this research paper and
extends the final custom topology creation framework. The aim
is to use the framework to achieve the project topology faster
and troubleshoot the network with less amount of jitter and
latency. Using this established framework, the new topology is
created to be used in the research project.
The project is implemented using Mininet, a network
emulation tool, which can be installed on any OS such as
Windows and Linux. Networking command line interface
(CLI) can be configured in Mininet for devices such as routers,
switches, and intermediate links. Currently, significant research
work has been made in the development of Mininet. The
project aims at using the present knowledge of Mininet to
implement the topology. The network topology includes three
servers, three hosts, and an Open vSwitch. On this topology,
the project is based using a round robin method to create a load
balancer in the network. The topology also consists of a
controller which acts like the brain of the topology.
V. RESEARCH METHODOLOGY
To research the solutions for the sub-problems which are
discussed in the paper, the following methodology has been
implemented:
Primarily, the cost of deploying hardware-based load
balancers was determined. The cost of deployment included
licensing costs, the price of hardware, customer support, and
maintenance. The current knowledge base of implementation
of load balancer networks was used to determine the network
design of the research project. As a result of the removal of
hardware requirements and vendor dependence, the CapEx
and OpEx were reduced.
The research topology is implemented in the Mininet
virtual environment. In Mininet, the diagram is created and
presented in CLI and therefore, may prove difficult to
understand only by reading the commands. Since Mininet uses
a CLI to configure nodes and hosts, creating topologies is a
time consuming task.
Fig. 4: Topology implemented in MiniEdit
Using Mininet, the configuration which was pushed on the
virtual switch by the controller became simple and
independent of the vendor and operating system. Using the
Python program running on the controller, the configuration
could be changed to match Cisco IOS, Juniper Networks
Junos, and Arista EOS. The program could also cater to
switches with different hardware capabilities such as 16-port
switch, 40-port switch, or any highly resourceful switch. The
research was focused on understanding the requirement for the
flexibility which is absent when a company chooses one
vendor over the other. Data was collected from the current
knowledge base of the engineers who are working in the
industry. The use of standard protocols replacing vendor
proprietary protocols, interoperability between access,
distribution and core layers that consists of different vendors,
the price factor in purchasing the devices and support are
some of the points that enhance flexibility when developing a
network. Therefore, using a program which is flexible enough
to deploy devices from different vendors was a criterion in the
research for this problem.
In continuing the research, information was needed to
assess the time required to implement a hardware-based load
balancer and software-based load balancer. Since the time
required to deploy an orthodox hardware load balancer varies
depending on a number of factors such as efficiency of the
engineer, the availability of the site, and the urgency of the
requirement, there is no concrete answer for the question. The
topology which is being used for research in Mininet was used
to implement a hardware-based network topology in the lab. It
took seventy hours to implement the same load balancer
network which was installed in Mininet in two hours. The
6
methodology used is completely based on the lab experience
of graduate students instead of industry experts.
After collecting the data using the above research
methodology, the software-based load balancer was
implemented using POX as follows. First, the virtual network
topology was implemented using the CLI version of Mininet.
The test topology was configured to have a total of six hosts
connected to the Open vSwitch. The hosts were made to start
with a dynamically assigned but easily readable IP and MAC
addresses by using -mac flag while creating the topology.
The Open vSwitch was configured to connect to the remote
POX controller on TCP port 6633 and communicate using the
OpenFlow protocol. When the POX controller is started at the
command line, it invokes the load balancer program. The
controller thereby implements the round robin functionality in
the SDN. The controller installs flow table entries in the Open
vSwitch according to the criteria defined in the load balancer
algorithm.
Second, the three hosts were configured as Web Servers
and port 80 was opened to listen to HTTP GET Requests.
While the remaining three hosts were populated with the static
ARP entry of the virtual IP address of the load balancer. This
virtual IP address is used by the clients to request web pages
from the server. For every subsequent request made by the
client to the virtual IP address, a different server would reply
with the webpage.
The load balancer algorithm works as follows - the Open
vSwitch listens to all incoming packets, but accepts only IPv4
packets with a destination IP address as the virtual IP address
and drops all other packets. The packet processing is flow-
based and thus, the system matches the packet information
with that of an existing session. If not, it creates a new session
and selects a server. The server is selected in a round robin
fashion for every session. The destination IP and the MAC
address of every packet in a session would be replaced with
the IP and MAC address of the selected server before being
sent out from the switch. While forwarding the reply from the
server to the client, the load balancer would modify the source
IP and MAC address of the reply packet to that of virtual IP
and MAC address. Thus, the load balancer effectively acts as a
reverse proxy keeping the process transparent for the end user.
The algorithm uses the OpenFlow libraries to listen and
forward the packets while POX controller libraries are used to
read and modify the packet.
VI. RESEARCH RESULTS
The results showed that the software-based load balancer
implemented using POX offered comparable performance to
the standard hardware-based load balancer.
A. Flow based load balancing and equal participation among
servers
The load balancer works on a per-flow basis rather than
per-packet. The observations of the POX controller debug logs
help in understanding the flow-mapping between the client
and the server. However, the flow-based load balancing may
also result in one server being used more as compared to
others if that server is catering to an overwhelming client. The
flow-based end result helps prevent the formation of
congested links.
In the results, the load balancer is able to distribute flows
equally among all the servers which ensure equal utilization of
all the servers, provided that the client requests are of the same
volume. The faster scaling of networks is enabled as the
servers have the same compute and storage capacity.
B. Performance with UDP and TCP
Iperf, an open source network performance measuring tool
was used to perform network throughput tests. Iperf can be
used to calculate different metrics like bandwidth, jitter and
packet loss in the case of UDP packets. In TCP, no packet loss
or jitter was observed, which implied an efficient response
time of the load balancer. The metrics measured for UDP,
under different bandwidths, are shown in the Table 1. As seen
in the table, the average jitter was calculated to be around
0.0705 ms. Different metrics are calculated with increasing
amounts of data transferred and the bandwidth which is set by
the client (target bandwidth). The actual bandwidth is the
bandwidth the server is sending the data back to the client.
The proficient networks are those which have a low difference
between target bandwidth and actual bandwidth. Evident from
the table below, the difference between the target and actual
bandwidth observed in six cases is very low with a minimal
percentage of datagrams lost. As UDP is an unreliable
protocol, datagrams are lost with the minimum rate at 0.23%
and maximum loss reported at 7.1%. On the contrary, since
TCP is a connection-oriented protocol, the software-based
load-balancer offered similar bandwidth performance as UDP
without any packet loss or jitter.
C. Cost Analysis
A comparison of the cost involved in the load balancer
versus the cost of the enterprise-based load balancer is shown
in the Table 2. The cost for hardware-based load balancers F5
and Citrix come out to be approximately $49,000 and $21,000
respectively. In contrast, the cost of implementing the load
balancer using a white-box switch lowers cost by 40-90%
based on research results.
VII. CONCLUSION AND FUTURE SCOPE
The round robin load balancer was successfully
implemented in a POX SDN controller, and the software-
based nature of a load balancer helped reduce the cost of
implementation for users. The project is vendor independent
because it relies on open standards. This provides flexibility in
configuration and deployment by allowing the company to
install the software on any white-box or OpenFlow supported
device. Thus, significantly reducing the period of time
required to deploy new services when compared to a
traditional hardware-based approach.
Future research can encompass the current limitations of
the product. IPv6 capabilities can further be incorporated into
the algorithm to enhance the productivity of the SDN-based
load balancer. In addition, the program can be modified to
implement different load balancing algorithms like weighted
round robin or IP-based Hashing.

TABLE 1: Load balancer UDP performance under different bandwidths

Interval (sec) Data transferred (MB) Target Bandwidth Actual Bandwidth Datagrams lost Jitter (ms)
(Mbps) (Mbps) (%)
0 10 1.19 1 0.999 0.23 0.066
0 10 11.8 10 10 1.1 0.206
0 10 113 100 94.7 7.1 0.1
0 10 279 250 234 0.51 0.004
0 10 461 500 386 2.6 0.023
0 10 594 1000 499 2.6 0.024

TABLE 2: Load balancer cost comparison

Hardware Hardware Cost ($) Operating System Support Cost (1 year) Total Cost ($)
cost ($) ($)
F5 BigIP 4000 (8-port) 48,995 [25] Pre-installed N/A 48,995+
Citrix VPX-3000 21,000 [26] Pre-installed N/A 21,000+
White-box: Pica8 P-5101 13,200 [27] 1,000 2,500 16,700
White-box: Edge-Core 5,441 [28] 1,000 2,500 8,941
Networks 5712-54X

7
 ACKNOWLEDGEMENT Conference (CCC), 2014 33rd Chinese , vol., no., pp.3580-3584, 28-
30 July 2014. DOI: 10.1109/ChiCC.2014.6895534
We would like to thank our advisors, Dr. Levi Perigo [17] Load-Balancing : Hash Methods, Calix, 2010. [Online]. Available:
and Jason Schnitzer for their insightful comments and for www.citrix.com/blogs/2010/09/04/load-balancing-hash-methods
supporting us throughout the course of this project. We [18] Shie-Yuan Wang, "Comparison of SDN OpenFlow network simulator
and emulators: EstiNet vs. Mininet," in Computers and
would also like to extend our sincere gratitude to Dr. David Communication (ISCC), 2014 IEEE Symposium on , vol., no., pp.1-6,
Reed for his guidance and supervision which helped us in 23-26 June 2014
successfully completing this research project. [19] R. de Oliveira, A. Shinoda, C. Schweitzer, and L. Rodrigues Prete,
Using mininet for emulation and prototyping software-defined
networks, in Communications and Computing (COLCOM), 2014
IEEE Colombian Conference on, June 2014, pp. 16
REFERENCES [20] Pal, C.; Veena, S.; Rustagi, R.P.; Murthy, K.N.B., "Implementation of
[1] Blogs.citrix.com, Load Balancing Round Robin | Citrix Blogs, simplified custom topology framework in Mininet," in Computer
2015 [Online]. Available: http://blogs.citrix.com/2010/09/03/load- Aided System Engineering (APCASE), 2014 Asia-Pacific Conference
balancing-round-robin/. [Accessed: 25- Sep- 2015] on , vol., no., pp.48-53, 10-12 Feb. 2014
[2] NGINX, What Is Load Balancing? How Load Balancers Work, [21] Stackoverflow.com, About Mininet, 2015.
2015 [Online]. Available: [Online].Available:http://stackoverflow.com/tags/mininet/info.
https://www.nginx.com/resources/glossary/load-balancing/ [Accessed: 01- Oct- 2015]
[Accessed: 28- Sep- 2015] [22] Openflow.stanford.edu, POX Wiki - Open Networking Lab
Confluence, 2015. [Online].
[3] Serverwatch.com, 5 Load Balancers You Need to Know, 2015.
Available:https://openflow.stanford.edu/display/ONL/POX+Wiki.
[Online].Available:
[Accessed: 02- Oct- 2015]
http://www.serverwatch.com/article.php/3937981/5-Load-Balancers-
[23] A. Sandler, tcpdumps for dummies, 2008. [Online]. Available:
You-Need-to-Know.htm. [Accessed: 27- Sep- 2015]
http://www.alexonlinux.com/tcpdump-for-dummies
[4] R. Poddar, A. Vishnoi, and V. Mann, HAVEN: Holistic Load
[24] Price-to-Performance Comparison of Load Balancers, KEMP
Balancing and Auto Scaling in the Cloud, in 7th International
Technologies. Available:
Conference on Communication Systems and Networks (COMSNETS),
http://www.sintel.com/bibli/telechargement/425/document_EN.pdf
IEEE, pp. 1-8, Jan. 2015. DOI: 10.1109/COMSNETS.2015.7098681
[25] 8-port F5 BIG-IP 4000s Better Bundle security appliance F5
[5] Price-to-Performance Comparison of Load Balancers, Kemp
Vault Security Program, Available:
technologies, Available: http://accessories.us.dell.com/sna/productdetail.aspx?c=us&l=en&s=
http://www.sintel.com/bibli/telechargement/425/document_EN.pdf &cs=19&sku=A7397260&ST=pla&dgc=ST&cid=298726&lid=5704
[6] What are White-box Switches?', SDxCentral, 2015. [Online]. 714&acd=123098073120560&ven1=A7397260:51918710868:901pd
Available: https://www.sdxcentral.com/resources/white-box/what-is- b6671:c&ven2=:&ven3=262503312761794609#Overview
white-box-networking/. [Accessed: 25- Sep- 2015] [26] Load Balancer, Comparison of the KEMP LoadMaster with F5 Big-
[7] IDG Knowledge Hub, Review: Is white-box switching the future of IP LTM and Citrix Netscaler MPX Hardware Load Balancers and
networking?, 2015. ADCs, 2015. [Online]. Available:
[Online].Available:http://idgknowledgehub.com/2015/10/12/review- https://kemptechnologies.com/compare-kemp-f5-big-ip-citrix-
is-white-box-switching-the-future-of-networking/. [Accessed: 03- netscaler-hardware-load-balancers/
Dec- 2015] [27] Pica8 P-5101 72-Port 10GbE Switch, NetGate. Available:
[8] Software Defined Everything, 1st ed. Deloitte University Press, 2015, http://store.netgate.com/Pica8-P-5101-72-Port-10GbE-Switch-
pp. 2-6. P2154.aspx
[9] Opennetworking.org, Software-Defined Networking (SDN) [28] Edgecore Network 5712-54X-O-48V-B 48Port 10GbE SFP+ with
Definition - Open Networking Foundation, 2015. [Online]. 6x40GbE QSFP Uplinks with Atom C2538 Retail, Neobits.
Available: https://www.opennetworking.org/sdn-resources/sdn- Available:
definition http://www.neobits.com/edge_core_networks_5712_54x_o_48v_b_e
[10] SDN controller (software-defined networking controller) definition, dgecore_p8066071.html?atc=gbp&gclid=CJOs48SZkswCFQ-
TechTarget, November 2012. Available: raQodZecJpw
http://searchsdn.techtarget.com/definition/SDN-controller-software-
defined-networking-controller
[11] What are SDN Controllers?, SDxCentral. Available:
https://www.sdxcentral.com/resources/sdn/sdn-controllers/
[12] S. Wilkins, A Guide To Software Defined Networking (SDN)
Solutions, Toms IT Pro, November 2014. Available:
http://www.tomsitpro.com/articles/software-defined-networking-
solutions,2-835-2.html
[13] M. Rouse, northbound interface / southbound interface,
TechTarget, November 2012. Available:
http://whatis.techtarget.com/definition/northbound-interface-
southbound-interface
[14] D. Shinder, Understanding Server Load Balancing, TechRepublic.
2010. [Online]. Available:
https://www.techrepublic.com/article/understanding-server-load-
balancing/
[15] K. Salchow, Load Balancing 101: Nuts and Bolts, 2012. [Online].
Available: www.f5.com/resources/white-papers/load-balancing-101-
nuts-and-bolts
[16] Xu Zongyu; Wang Xingxuan, "A modified round-robin load-
balancing algorithm for cluster-based web servers," in Control

8
 Appendix 1 Resources used UDP User Datagram Protocol

Component Name URL Uniform Resource Locator

Linux Virtual Machine Xubuntu Xfce v4.10 WAN Wide Area Network

Virtual Network Emulator Mininet v2.2.1

Programming Platform Python 2.7

SDN Controller POX

Appendix 2: List of Acronyms

API Application Programming

Interface
ARP Address Resolution Protocol

ASIC Application-Specific
Integrated Circuit
CLI Command Line Interface

CDN Content Delivery Network

GUI Graphical User Interface

HTTP Hyper Text Transport

Protocol
NAT Network Address
Translation
NOS Network Operating System

OS Operating System

SDN Software Defined

Networking
SDDC Software Defined Data
Center
TCAM Tertiary Content
Addressable Memory
TCP Transmission Control
Protocol