ABSTRACT

Internet service providers and networking companies are apprehensive about implementing a software-defined network (SDN) as a universal solution, because of the lack of quality research done in the field. An application prone to latency and jitter can severely impact its performance leading to the dismal customer experience. Most service providers’ today need a network with fast provisioning and quick support. SDN aims to provide this capability to the service provider with a valid proposition of QoS. The proposed prototype of the SDN would demonstrate QoS and suggest ways to improve it. This document aims at finding ways to mitigate latency and suggest improvements in QoS in a SDN using the Floodlight OpenFlow controller. The performance testing to measure QoS would be done using the networking tool iPerf.

Keywords — software-defined network, Quality of Service Floodlight, OpenFlow, Mininet, Open vSwitch, jitter

NETWORK TOPOLOGY

TOOLS USED

• Custom built OpenFlow Controller based on Floodlight
• Mininet Network Simulator
• Raspberry Pi running Open vSwitch
• Cisco Catalyst Switch
• Macintosh Machines as RTP/Data server & client

COST OF IMPLEMENTATION

INSTALLATION

CONTROLLER NODE

Host OS

• Download Ubuntu 14.04.X or later from Canonical's site
  
  
• Install Ubuntu on a standard x86 hardware & run
  
  # sudo apt-get update
  
  
• Assign a static IP on one of the interfaces

Custom OpenFlow Controller (Ralphie)

• Install the required packages for running the custom controller
  
  # sudo apt-get install build-essential default-jdk ant python-dev python-simplejson
  
  
• Download the controller package by cloning it in the local environment
  
  # git clone https://github.com/savithruml/qos-capstone
  
  
• Make the package
  
  # cd qos-capstone
# sudo ./run.sh
  
  
• Verify the installation. Open a web-browser & enter the following,
  
  http://ralphie.com/ui/index.html
  
  
  
  This confirms that the installation is complete.

SWITCH NODE

• Download & Install Raspbian OS on the TWO Raspberry Pis
  
  
• Assign static IP's in the same subnet as the controller
  
  
• Install dependencies on the Raspberry Pi by issuing the following commands,
  
  # sudo apt-get update
# sudo apt-get -y upgrade
# sudo apt-cache search linux-source
# sudo apt-get install -y linux-source-3.18
# sudo apt-get install -y python-simplejson automake autoconf gcc uml-utilities libtool build-essential git
# sudo apt-get install pkg-config tcpdump iperf
# sudo reboot
  
  Download & Install Open vSwitch
  
  # wget http://openvswitch.org/releases/openvswitch-2.3.1.tar.gz
# tar zxvf openvswitch-2.3.1.tar.gz
# cd openvswitch-2.3.1
# sudo sh ./boot.sh
# sudo ./configure
# sudo make
# sudo rpi-update
# sudo make install
# sudo modprobe openvswitch
  
  Run the script install-ovs.sh to complete the installation
  
  # sudo ./install-ovs.sh
  

CONFIGURE QOS

• Differentiate traffic through Class-Maps. In our example, we have TWO class of services (Video & Data)
  
  # ./addClassMap.py --add -t service -O '{"name":"Video","tos":"101000"}' -c 127.0.0.1 -p 8080
  
  This can be verfied by entering,
  
  # ./qosManager.py -L -t services
  

• Create a QoS policy for the traffic & assign the Class-Maps to it. The policy can be assigned based on various parameters such as source/destination address, protocol, Type of Service (ToS) bits, etc.
  
  # ./addQoSPolicy.py -a -S 10.0.0.1 -D 10.0.0.2 -N Test-QoS-Capstone /
  -J '{"eth-type":"0x0800","protocol":"17","queue":"2","tos":"101000"}'
  
  This can be verified by entering,
  
  # ./qosManager.py -L -t policy
  
  

• Measure the bandwidth between the stream server (10.0.0.1) & the client (10.0.0.2) using iperf bandwidth measurement tool.
  
  On Server (UDP)
  # iperf -s -u
  
  On Client (UDP)
  # iperf -c <server-ip-address> -u
  

RESULTS

COMPARISON OF QoS PERFORMANCE CHARACTERISTICS

As depicted in the graph below, we achieved ideal latency figures when using a SDN model with Mininet. These low figures of latency are not practically achievable in a physical network because of the latency introduced through routing and switching overhead. The traditional network model using Cisco routers represented by the red line on the graph initially had a low latency figure of about 75ms when compared to the SDN model. When the RTP burst traffic was introduced, as seen at around 25-40 second mark, the SDN model outperforms the traditional model by about 2-3 ms. This difference is attributed to the OVS performance of looking up flows. As time passes, the traditional network offers a better QoS performance characteristics than a SDN model. This difference can be attributed to the performance limitations of the hardware that is being used (Raspberry Pi) to run the OVS daemon.

SAMPLE OUTPUT

Below are the screenshots of a video streaming on the client without and with QoS enabled in a SDN model. Figure 5.a depicts the distorted video output that is caused due to no prioritization of video traffic over data. After enabling the QoS module on our custom built controller, we were able to see a significant difference in the output of the video stream and this is seen in Figure 5.b.