Application Aware Routing System (A2RS)

for Software Defined Networks

BIRLA INSTITUTE OF TECHNOLOGY & SCIENCE, PILANI

Application Aware Routing System (A2RS)

for Software Defined Networks
ACADEMIC DISSERTATION

submitted for
the partial fulfillment of
requirements of
M.S. Software Engineering degree
of BITS
in the presence of
Evaluating Committee
of BITS WILP division
on June 15, 2015

by

Bakshi Gulam Mohammed Khan

Abstract: Traditional networks were designed to forward packets from source to

destination using the shortest route possible. Routers and switches were mostly
agnostic to applications being served by the network. In this kind of network, a
service provider may not be able to distinguish between a user watching video and
another browsing the web. In order to provide service differentiation and increase
user experience, todays networks are forced to be application-aware. SoftwareDefined Networking (SDN) which is an emerging concept in networking forefront
presents an opportunity to service providers to control their networks by means of a
programmable interface. This dissertation aims at developing an application-aware
routing system (A2RS) for SDN which does differential routing based on type of
application to which the traffic belongs to. Deploying such SDN application will help
service providers to dynamically provision the network switches based on application
characteristics and requirements, leading to a better overall user experience and
reduction in bandwidth wastage.
Broad Academic Area of Work: Computer Networks
Keywords: Networking, OpenDaylight, Routing, SDN
Supervisor: Saro Velrajan

Copyright 2015 by Bakshi Gulam Mohammed Khan

Acknowledgements
I thank the Almighty for having helped me take the right decision at every design decision
juncture of this dissertation.
I wish to express my sincere thanks to Mr.Saro Velrajan Director Technology, Aricent for
guiding me throughout this dissertation.
I am also grateful to Mr.Ravi Saripalli Senior Software Engineer, Aricent for helping me
change the Linux Virtual Ethernet Driver(veth)s code at a critical moment of this
dissertation.
I take this opportunity to express my gratitude to all my colleagues & members of Open
Source Community who supported me throughout this venture.
I also wish to thank Prof.Katheeja Parveen, Vignesh Raja K.R. (Research Student, University
of Twente, Netherlands), Arun K Kumar (Technical Leader, Aricent) and all others who have
spent their valuable time in reviewing this dissertation.

Table of Contents

Chapter 1: Introduction .................................................................................................................. 1

Chapter 2: Literature Survey ........................................................................................................... 2
Chapter 3: Methodology ................................................................................................................. 3
3.1 Objectives ............................................................................................................................. 3
3.2 Design ................................................................................................................................... 3
3.2.1 Software Architecture .................................................................................................... 3
3.2.2 Control Flow .................................................................................................................. 6
3.2.3 Traffic Classification ..................................................................................................... 6
3.2.4 Differential Routing Algorithm ..................................................................................... 7
3.2.5 FlowMod Construction .................................................................................................. 8
Chapter 4: Results ........................................................................................................................... 9
Chapter-5 Discussions & Recommendations for Future Work .................................................... 14
5.1 Traffic Classification .......................................................................................................... 14
5.1.1 File Transfer ................................................................................................................. 14
5.1.2 Everything on Port-80 .................................................................................................. 14
5.1.3 HTTPS the challenge with encrypted packets .......................................................... 14
5.2 Differential Routing ............................................................................................................ 14
Chapter-6: Conclusion .................................................................................................................. 16
References ..................................................................................................................................... 17
Appendix I ................................................................................................................................. 18
List of Abbreviations ................................................................................................................ 18

ii

List of Figures

Figure 1: A2RS as a Client Application to OpenDaylight .............................................................. 3

Figure 2: A2RS as a Plug-in to OpenDaylight................................................................................ 4
Figure 3: A2RS Detailed Architecture ............................................................................................ 4
Figure 4: Control Flow of A2RS .................................................................................................... 5
Figure 5: Test Topology.................................................................................................................. 9
Figure 6: Topology creation using Mininet .................................................................................. 10
Figure 7: Changing link speeds to simulate 10G and 1G links..................................................... 10
Figure 8: Starting OpenDaylight ................................................................................................... 11
Figure 9: Installing A2RS Plugin in ODL .................................................................................... 11
Figure 10: GUI showing the test topology.................................................................................... 12
Figure 11: Successful traffic between Web Server & Web Client ............................................... 12
Figure 12: Successful traffic between FTP Server & FTP Client ................................................. 13
Figure 13: Test Topology with two additional links S5-S2; S6-S3 ........................................... 14

iii

List of Tables

Table 1:Traffic Classification & Flow Class .................................................................................. 7

iv

Chapter 1: Introduction
Software defined networks (SDN) is an intriguing next-generation networking that has garnered a great
deal of research interest. By decoupling the control and data planes in network switches and routers, SDN
enables the rapid innovation and optimization of routing and switching equipment. SDN greatly
simplifies network management by offering administrators network-wide visibility and direct control over
the underlying switches from a centralized controller. SDN follows a tiered architecture with a
southbound interface defined by the OpenFlow protocol that enables the interaction between the control
and data planes, and a northbound API that presents a network abstraction interface to the applications
and management systems residing at the top. The decision making lies with the centralized controller.
SDN applications are built on top of the controller.
In a traditional network (non-SDN), routers and switches are mostly agnostic to the applications being
served by the network. Especially routing by conventional Interior Gateway Protocols (IGPs) like RIP,
OSPF, ISIS, etc. are purely based on source and destination IPs. In this kind of routing, there isnt a way
for differential treatment of applications to which the traffic belongs to. For example, these routing
protocols do nothing to help service providers distinguish between the bandwidth needs of a user
watching videos versus one browsing the Internet. Application-Aware routing is a concept of taking
application parameters into consideration in routing of packets in order to provide service differentiation
and to improve user experience.
In non-SDN network, this is achieved by a mechanism called Policy-Based Routing (PBR). In PBR,
explicit routing policies are defined in routers to forward specific application traffic to specific
destination. For example, routing policies are defined to redirect all HTTP requests (i.e. port 80 traffic) to
Over The Top (OTT) caches sitting in the service provider network that cache Web Traffic. Since all such
routing policies are configured manually, this approach is not scalable when handling traffic that belongs
to thousands of websites.
The tiered architecture of SDN paves a way for the implementation of intelligent applications and
services on top of the SDN controller. It also offers service providers the chance to build networks with
increased application awareness, or intelligence about L4-L7 protocol attributes and delivery
requirements. Using this opportunity, application awareness can be brought to network in much better and
intelligent way than manual configuration as in case of PBR. The network can be made to learn traffic
that belongs to different applications dynamically and use this heuristics to intelligently route traffic in
various available paths.
This dissertation aims at developing a scalable application-aware routing system (A2RS) which is
centralized in nature and does differential routing based on type of traffic to provide service
differentiation and to increase link utilization.
The scope of this research is limited only to performing routing inside an AS. In a Hybrid-SDN
environment, routing between ASs should be done using an additional plug-in for controller (like BGPLS plug-in for OpenDaylight[1]) or separate routing platform (like RouteFlow[2][3]).
The next chapter does a survey of similar works and discusses problems in those approaches. Chapter-3
discusses the objectives taken into consideration for this dissertation, the design of A2RS - architecture,
control flow, traffic classification & differential routing methodologies. Chapter-5 discusses results and
gives few recommendations for future work which is concluded by Chapter-6.

Chapter 2: Literature Survey

There have been works for EGP (BGP) support for SDN [1][2][3]. But works on Interior Gateway routing
support for SDN are very few. Moreover, existing implementations (see Google's B4 Case [4]) seek to
achieve Interior Routing using existing IGP protocols (like OSPF/ISIS) from stacks like Quagga/XORP.
The problem with that approach is resource (CPU/Memory) exhaustion since an entire stack
(Quagga/XORP) or a Virtual Machine (VM) is spawned for each switch in the network. This may not be
a concern for privately managed small-sized LAN/WAN. But this poses serious concern when scaling the
network with hundreds and thousands of switches (like AS-wide deployment for a service provider).
A2RS aims to address this issue by being a light-weight plugin to controller and still be able to handle a
cluster of switches.
In addition, these approaches cannot perform Traffic Engineered(TE) routing as they depend only upon
source IP and destination IP of the packet being routed. Googles B4 does a TE routing in order to
maximize link utilization. But B4 also depend upon source IP and destination IP and does not look into
transport layer ports. Hence packets having same SIP and DIP will be routed via the same path
irrespective of the application that generated those packets. Though this approach provides a way to
increase link utilization, it does not provide any mechanism for service differentiation.

Chapter 3: Methodology
This dissertation is an attempt of implementing the idea outlined in the White Paper titled "Application
Aware Routing in SDN" [5] as a proof of concept. A plug-in for OpenDaylight controller [6] named
"Application-Aware Routing System (A2RS)" has been developed for the same.

3.1 Objectives
The objectives of A2RS are as follows:
1) Single routing software for a cluster of switches as opposed to spawning a separate stack for each
switch.
2) Routing based on type of application served by the network as opposed to considering only destination
network.
3) Performing a better differential routing which increases the utilization of links in the network.

3.2 Design
3.2.1 Software Architecture
To achieve objective (1), two design approaches were considered. One of the major design decisions that
had to be taken was whether or not to design this application to be part of controller. Both approaches designing this to be part of controller (see Figure-1) and designing this to run on top of controller (see
Figure-2), have been taken into consideration. Many disadvantages like lack of infrastructure to lift
packets to ODL client applications, additional delay in formatting & parsing the packet in XML/JSON
and transit delay of packet on the path from controller to client application and vice versa, etc. have been
found in the latter approach. Since the former approach eliminates the above mentioned disadvantages,
it's been decided that this routing application will be designed to be a part of ODL SDN controller like
every other sub-system which involves packet processing (like L2Switch in ODL).

Figure 1: A2RS as a Client Application to OpenDaylight

Figure 2: A2RS as a Plug-in to OpenDaylight

Figure 3: A2RS Detailed Architecture

Figure 4: Control Flow of A2RS

3.2.2 Control Flow

A2RS is designed as a plug-in to OpenDaylight controller. Hence it cannot run in isolation. It depends on
other modules of ODL in order to perform successful routing. A2RS when started, registers itself with
TopologyManager, DataPacketService & FlowProgrammerService as shown in below snippet.
public void configureInstance(Component c, Object imp, String containerName)
{
log.trace("Configuring instance");
if (imp.equals(A2RS.class))
{
// Define exported and used services for A2RS component.
Dictionary<String, Object> props = new Hashtable<String, Object>();
props.put("salListenerName", "A2RS");
// Export IListenDataPacket interface to receive packet-in events.
c.setInterface(new String[]
{
IListenDataPacket.class.getName(),
ITopologyManagerClusterWideAware.class.getName()
}, props);
// Need the DataPacketService for encoding, decoding, sending data packets
c.add(createContainerServiceDependency(containerName)
.setService(IDataPacketService.class)
.setCallbacks("setDataPacketService", "unsetDataPacketService")
.setRequired(true));
c.add(createContainerServiceDependency(containerName)
.setService(ITopologyManager.class)
.setCallbacks("setTopologyManager", "unsetTopologyManager")
.setRequired(true));
// flow programmer service
c.add(createContainerServiceDependency(containerName)
.setService(IFlowProgrammerService.class)
.setCallbacks("setFlowProgrammerService", "unsetFlowProgrammerService")
.setRequired(true));
}
}

When ODL receives a OpenFlow Packet-In message, the DataPacketService calls the pre-registered callback function receiveDataPacket() where all necessary parameters of the flow Source IP (SIP),
Destination IP (DIP), Transport Protocol, Source Port & Destination Port are extracted from the packet
and stored in flowInfo object.

3.2.3 Traffic Classification

Transport Layer uses ports to multiplex packets among different applications. Since various applications
like Web Server, FTP Server (Active FTP) runs on standard ports, transport layer port numbers can be
used to identify the type of application to which the packet belongs to. The flowInfo object obtained in

the previous step is sent to FlowClassifier and the flow is classified as shown in Table-1. (Note: Transport
Protocol, Source Port & Destination Port will be used to classify the traffic while SIP and DIP will be
used to find routes in the network.)
S.No
1
2
3
4
5
6

Transport
Protocol
TCP
TCP
TCP
TCP
TCP
TCP

Source
Port
X
80
X
21
X
20

Destination
Port
80
X
21
X
20
X

Traffic Classification

Flow Class

Web Traffic
Web Traffic
FTP Traffic
FTP Traffic
FTP Traffic
FTP Traffic

Lean Pipe
Lean Pipe
Fat Pipe
Fat Pipe
Fat Pipe
Fat Pipe

Table 1:Traffic Classification & Flow Class

When classifying FTP traffic, initially it was thought that only the data traffic (over port 20) will be
routed through Fat Pipe and the control traffic (port 21) will be routed via Lean Pipe. But in this
differential routing, there is a possibility of FTP connection not happening when the Lean Pipe is
congested. Hence later it is decided to route both FTP control traffic and data traffic over the Fat Pipe.

3.2.4 Differential Routing Algorithm

To achieve objective (3), a better algorithm other than Djikstra's Shortest Path algorithm was sought. First
it was thought that A2RS would find all possible routes from source to destination and then select an apt
route for particular type of application. But later it was found that finding all possible routes from a
source to a destination on a network can be NP-hard and sometimes even NP-complete.
Hence instead of finding all possible paths between a source and a destination, it is decided that "kshortest path algorithm" will be used to find more than a route. There are various "k-shortest path
algorithms" proposed by different people[7]. Among those Yen's K-Shortest path algorithm[8] is chosen
because of the loop-less nature of paths it yields. Choosing a lesser value of 'k' (2, 3, etc.) greatly reduces
the complexity of the algorithm.
The entire graph of the network is obtained from TopologyManager and Yen Top-K shortest path
algorithm is run on that graph. When there is only one route, irrespective of type of traffic, it will be
routed via that path. When there is two possible routes, traffic belonging to Audio, Video, Live
Streaming, Games & File Transfer will be routed via the route with lesser cost (Fat Pipe) and rest of the
traffic will be routed via the other link (Lean Pipe) as shown in the below snippet.

Path selectBestRoute(List<Path> shortest_paths_list, int flowClass)

{
Path route = null;
if(shortest_paths_list.size() == 1)
{
route = shortest_paths_list.get(0);
}
else if(shortest_paths_list.size() == 2)
{
if(flowClass == FlowInfo.FLOW_CLASS_AUDIO ||
flowClass == FlowInfo.FLOW_CLASS_VIDEO ||
flowClass == FlowInfo.FLOW_CLASS_LIVE_STREAM ||
flowClass == FlowInfo.FLOW_CLASS_GAMES ||
flowClass == FlowInfo.FLOW_CLASS_FILE_TRANSFER)
{
route = (shortest_paths_list.get(0).get_weight() <
shortest_paths_list.get(1).get_weight())?
shortest_paths_list.get(0):shortest_paths_list.get(1);
}
else
{
route = (shortest_paths_list.get(0).get_weight() >
shortest_paths_list.get(1).get_weight())?
shortest_paths_list.get(0):shortest_paths_list.get(1);
}
}
return route;
}

3.2.5 FlowMod Construction

Finally, the Source IP, the Destination IP, the Transport Protocol, the Source Port & the Destination Port
are filled as Match Fields and the output <port> calculated by routing algorithm is filled as
Action:Output to <port> of OpenFlow FlowMod message and installed in the switch with the help of
FlowProgrammerService.
In case of traffic like FTP, it is observed that the source port is randomized for each transaction and
inclusion of Source Port in Flow increases both control traffic and number of flows in switches. Hence it
is decided to wildcard source port in flows installed from A2RS.

Chapter 4: Results
Mininet is used to create the test topology. OpenVSwitch (OVS) is used as OpenFlow switch. Figure 5
shows the test topology used and Figure 6 through Figure 12 captures various stages of execution.
As shown in Figure 5, a Web Server and a FTP Server are started in hosts H1 and H2 respectively.
Similarly, a Web Client and a FTP Client are started at hosts H3 and H4 respectively. A HTTP request
has been made from H3 to H1 and a HTTP response is received. Using DLUX (OpenDaylight GUI), its
been verified that the flows corresponding to Web Traffic (with TCP port 80) are installed on switches
S1, S5, S6 and S4. Hence the Web Traffic has taken the Lean Pipe as per the traffic classification
mentioned in Table 1.
Similarly, a FTP connection is established to H2 from H4. The FTP connection is successful and a sample
file has been downloaded successfully. Again using DLUX it is verified that the FTP flows (with TCP
port as 21 & 20) are installed on switches S1, S2, S3 and S4. Hence the FTP Traffic has taken the Fat
Pipe as per the traffic classification mentioned in Table 1.
Thus A2RS has successfully routed traffic that belongs to two different applications over two different
available paths in a SDN network.

Figure 5: Test Topology

Figure 6: Topology creation using Mininet

Figure 7: Changing link speeds to simulate 10G and 1G links

10

Figure 8: Starting OpenDaylight

Figure 9: Installing A2RS Plugin in ODL

11

Figure 10: GUI showing the test topology

Figure 11: Successful traffic between Web Server & Web Client

12

Figure 12: Successful traffic between FTP Server & FTP Client

13

Chapter-5 Discussions & Recommendations for Future Work

5.1 Traffic Classification
5.1.1 File Transfer
In case of (PASV)FTP (bulk transfer), only control messages are transferred on port-21 and the actual
data transfer happens over an arbitrary port number making FTP traffic classification nearly impossible.
In case of P2P file transfer, unless the P2P client uses fixed port number, it is also impossible to identify
P2P traffic with single packet belonging to that traffic.

5.1.2 Everything on Port-80

When testing with real-world traffic, it is felt that initial Port based traffic classification is not sufficient to
identify various applications as most of web traffic including audio, video & streaming content runs on
port-80. One solution to overcome this problem is to parse the HTTP header and using <Content-Type>
to classify the traffic. A HTTP parser was developed for the same but because of a bug in OVS, it couldn't
be tested.

5.1.3 HTTPS the challenge with encrypted packets

Another observation with real-world traffic is that most of website/services are using secure protocols like
HTTPS/SSL/TLS, etc. The encryption used by these protocols again dismisses the possibility of looking
into HTTP headers for more precise traffic classification. In addition, the port numbers used in this case
will be the port numbers of secure protocols but not the port numbers of the application. This totally
devastates the idea of classifying traffic based on the information present in the packet headers.
Instead of port number based classification, some other traffic classification technique like "signature
based traffic classification" can be considered to classify the traffic with more precision.

5.2 Differential Routing

When test topology is changed from as shown in Figure 5 to as shown in Figure 13, the Web Traffic
which was taking the path S1-S5-S6-S4 earlier, took a different route S1-S5-S2-S3-S4 as a result of
Djikstras shortest path algorithm.

Figure 13: Test Topology with two additional links S5-S2; S6-S3

14

Though this may be the next shortest path, in operators' perspective, this may not be desirable. The
operator may want all the web traffic to traverse only the 1G path from source to destination. In this case
a better algorithm may be used or getting the operators input (like Policy Based Routing) may be
considered.
Also, in Yens K-Shortest Path Algorithm used, only cases where K <= 2 are handled so far. An
algorithm to select the best route when K > 2 can be developed.

15

Chapter-6: Conclusion
This dissertation presents the motivation, design and results of A2RS an Application-Aware Routing
System for OpenDaylight controller. Among the objectives discussed in Chapter-3, objective (1) has been
met in its entirety. A2RS is able to manage more than one switch. So far a topology with six switches has
been tested and there are no issues in this aspect. Regarding traffic classification (Objective 2) there has
been some glitches. There are certain limitations with the traffic classifying capability of A2RS as
discussed in Chapter-5. Objective (3) has partially been met by differentiating Web and FTP traffic. This
aspect can also made better as discussed in the Chapter-5.
Although A2RS is not readily deployable, I believe there are a number of important lessons that can be
taken into consideration during the design of any SDN routing system that wants to provide service
differentiation and increase link utilization.

16

References
[1] OpenDaylight BGP LS Wiki [https://wiki.opendaylight.org/view/BGP_LS_PCEP:Main]
[2] RouteFlow project page [https://sites.google.com/site/routeflow/home]
[3] Christian E. Rothenberg, Marcelo R. Nascimento, Marcos R. Salvador. Revisiting Routing Control
Platforms with the Eyes and Muscles of Software-Defined Networking. HotSDN 12; Helsinki; ACM;
2012.
[4] SDN/OpenFlow Migration Use Cases.
[https://www.opennetworking.org/images/stories/downloads/sdn-resources/use-cases/Migration-WGUse-Cases.pdf]
[5] Saro Velrajan. Application-Aware Routing in Software Defined Networks. Whitepaper; Aricent;
2013.
[6] OpenDaylight project page. [http://www.opendaylight.org/]
[7] K-Shortest Path Algorithm Wiki [http://en.wikipedia.org/wiki/K_shortest_path_routing]
[8] Jin Y. Yen. Finding the K Shortest Loopless Paths in a Network. Management Science
Vol. 17, No. 11, Theory Series (Jul., 1971): 712-716

17

Appendix I
List of Abbreviations
A2RS - Application-Aware Routing System
API - Application Programming Interface
AS - Autonomous System
BGP - Border Gateway Protocol
DIP - Destination IP address
DLUX - openDayLight User eXperience
EGP - Exterior Gateway Protocol
FTP - File Transfer Protocol
HTTP - Hyper Text Transfer Protocol
IGP - Interior Gateway Protocol
IP - Internet Protocol
ISIS - Intermediate System to Intermediate System
JSON - JavaScript Object Notation
OSPF - Open Shortest Path First
OTT - Over The Top
OVS - Open Virtual Switch
P2P - Peer-to-Peer
PBR - Policy Based Routing
RIP - Routing Information Protocol
SDN - Software Defined Network
SIP - Source IP address
TE - Traffic Engineering
VM - Virtual Machine
XML - eXtensible Markup Language
XORP - eXtensible Open-source Routing Platform

18