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, today’s networks are forced to be application-aware. Software-

Defined 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

i

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.

ii

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

iii

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

iv

List of Tables

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

1

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 isn’t 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 BGP-

LS 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.

2

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. Google’s 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.

3

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

4

Figure 2: A2RS as a Plug-in to OpenDaylight

Figure 3: A2RS Detailed Architecture

5

Figure 4: Control Flow of A2RS

6

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 call-

back 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

7

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 Transport

Protocol

Source

Port

Destination

Port

Traffic Classification Flow Class

1 TCP X 80 Web Traffic Lean Pipe

2 TCP 80 X Web Traffic Lean Pipe

3 TCP X 21 FTP Traffic Fat Pipe

4 TCP 21 X FTP Traffic Fat Pipe

5 TCP X 20 FTP Traffic Fat Pipe

6 TCP 20 X FTP Traffic 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 "k-

shortest 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.

8

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.

9

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), it’s

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

10

Figure 6: Topology creation using Mininet

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

11

Figure 8: Starting OpenDaylight

Figure 9: Installing A2RS Plugin in ODL

12

Figure 10: GUI showing the test topology

Figure 11: Successful traffic between Web Server & Web Client

13

Figure 12: Successful traffic between FTP Server & FTP Client

14

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

Djikstra’s shortest path algorithm.

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

15

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 Yen’s 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.

16

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.

17

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-WG-

Use-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

18

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