Bandwidth-Delay Constrained Application Aware

Routing In Software Defined Networks

A Report Submitted
in Partial Fulfillment of the Requirements
for the Degree of
Bachelor of Technology
in
Computer Science & Engineering

by Group CS08
Abhyudaya Anand, Adarsh Pandey, Kunal Sharma, Amish Kumar,
Krishna Murari, Sudhir Kumar Jayaswal

to the
COMPUTER SCIENCE AND ENGINEERING DEPARTMENT
MOTILAL NEHRU NATIONAL INSTITUTE OF TECHNOLOGY
ALLAHABAD
May, 2017
 UNDERTAKING

I declare that the work presented in this report titled “Bandwidth-Delay Con-
strained Application Aware Routing In Software Defined Networks”, submit-
ted to the Computer Science and Engineering Department, Motilal Nehru
National Institute of Technology, Allahabad, for the award of the Bache-
lor of Technology degree in Computer Science & Engineering , is my
original work. I have not plagiarized or submitted the same work for the award
of any other degree. In case this undertaking is found incorrect, I accept that
my degree may be unconditionally withdrawn.

May, 2017
Allahabad
(Abhyudaya Anand)

(Adarsh Pandey) (Kunal Sharma)

(Amish Kumar) (Krishna Murari)

(Sudhir Kumar Jayaswal)

ii
 CERTIFICATE

Certified that the work contained in the report titled

“Bandwidth-Delay Constrained Application Aware Routing In
Software Defined Networks”, by (group CS08) Abhyudaya
Anand, Adarsh Pandey, Kunal Sharma, Amish Kumar, Krishna
Murari, Sudhir Kumar Jayaswal , has been carried out under my
supervision and that this work has not been submitted elsewhere
for a degree.

(Dr Shashank Srivastava)

Computer Science and Engineering Dept.
M.N.N.I.T, Allahabad

May, 2017

iii
Preface

The basis of our thesis is to explore the potential of Software Defined Networks(SDN)
in efficent traffic engineering. It is written to provide a fast routing algorithm for
today’s application centric dynamic networks. Since the evolution of SDN, it’s
implementation in real networks has been a major issue.Algorithms used for traffic
engineering in real time are a major research issue.We used floodlight controller to
study current algorithms used for the task and our thesis aims to provide a more
diverse solution which can later be integrated into the controller.
The idea for the project was conceived under the guidance of our mentor Dr.
Shashank Srivastava. Our project work was decided together by our group and
mentor as he was already working on congestion controlled path assignment in SDN
networks by modifying the routing algorithms used by the controller. We have
worked on one of the use cases(Application Aware Routing(A2R)) for our algorithm.
The results of thesis can be implemented by anyone who has a basic idea of
how routing algorithms are implemented and how link metrics are used in floodlight
controller.

iv
Acknowledgments

We would like to express our sincere gratitude to Dr.Shashank Srivastava for provid-
ing us the golden opportunity to do this wonderful project on the topic Bandwidth-
Delay Constrained Application Aware Routing In Software Defined Networks which
also helped us to learn and explore more about networking and networking devices.
We would also like to thank all the PhD. Scholars working under Dr. Shashank
Srivastava for their proper guidance and encouragement in carrying out this project
work in limited time frame.

v
Contents

Preface iv

Acknowledgments v

1 Introduction 2
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background & System Model 4

2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Network Performance Measures . . . . . . . . . . . . . . . . . 4
2.1.2 Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Traffic Engineering in Floodlight . . . . . . . . . . . . . . . . 8
2.2 Single Source Shortest Path Algorithms . . . . . . . . . . . . . . . . . 10
2.2.1 Single Shortest Path . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 K-Shortest Path . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Application Aware Routing(A2R) In SDN 12

3.1 Why Application specific Routing ? . . . . . . . . . . . . . . . . . . . 12
3.2 What is Application aware Routing ? . . . . . . . . . . . . . . . . . . 13
3.3 Implementation of A2R with SDN . . . . . . . . . . . . . . . . . . . . 14

4 Model Implementation & Network Simulation 16

4.1 Model Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 16

vi
 4.1.1 Application Aware Routing . . . . . . . . . . . . . . . . . . . 16
4.1.2 Path Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3 Shortest Path Algorithms . . . . . . . . . . . . . . . . . . . . 21
4.2 Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.1 Tools Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.2 Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Results 27

6 Future Works 34
6.1 Shortest Path Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Application Aware Routing . . . . . . . . . . . . . . . . . . . . . . . 34

7 Conclusion 36

References 37

References 38

vii
List of Figures

1 Scope of Traffic Engineering in SDN [3] . . . . . . . . . . . . . . . . . 6

2 Sample Network [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Application Aware Routing over network [8] . . . . . . . . . . . . . . 14

4 Path cache algorithm flowchart . . . . . . . . . . . . . . . . . . . . . 19

5 PathMetric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6 Bellman Ford Algorithm flowchart . . . . . . . . . . . . . . . . . . . . 22
7 A star algorithm flowchart . . . . . . . . . . . . . . . . . . . . . . . . 23
8 Hershberger Algorithm Flowchart . . . . . . . . . . . . . . . . . . . . 24

9 Network Topology for simulation . . . . . . . . . . . . . . . . . . . . 27

10 Network Topology for simulation . . . . . . . . . . . . . . . . . . . . 28
11 Re-computation time of different shortest path algorithms . . . . . . 29
12 Network state with Hopcount as metric . . . . . . . . . . . . . . . . . 30
13 Network state with Utilization as metric . . . . . . . . . . . . . . . . 31
14 Network state with Latency & Utilization as metric . . . . . . . . . . 32
15 Network state with Latency as metric . . . . . . . . . . . . . . . . . . 33

1
Chapter 1

Introduction

1.1 Problem Statement

The problem addressed in this work is to provide latency and utilization efficient
paths in real networks. Different types of applications send different types of data
and their demand from networks are different. Some applications need to transfer
data in low latency and some need a minimum bandwidth. Current algorithms used
in SDN cannot handle different types of path metric demands. Only one metric at
a time can be implemented. Our work was to analyze the current algorithm and
it’s performance. Implementation of Application Aware Routing to provide paths
according to application running is also addressed.
Our work aims to replace the current algorithm with a better one and after that
tries to limit number of re-computations. Analysis of path metrics available and
their alternatives is also addressed.

1.2 Motivation
In Software Defined Networking, [1] the network intelligence is separated from the
data plane and logically centralized in a programmable controller.This concept opens
the potential of network to provide efficient traffic engineering(TE) and better Qual-
ity of Service(QoS) due to centralized system and a global view of network.SDN

2
network devices could be dynamically handled by the control software in order to
ensure optimal allocation of the network resources and avoid congestion.
TE algorithms proposed so far works on setting up bandwidth guaranteed traffic
tunnels in the network.[2] With wide emergence of real time internet application
these algorithms can’t work properly because they create bottlenecks in the network.
Algorithm implemented in current floodlight controller uses yen’s algorithm and
some path metrics(utilization,latency etc.) to provide better resource utilization.[4]
But it can’t handle multiple path metrics.
This motivated us to consider a model of control plane which provide application
specific paths in the network and do so without being affected by future traffic.

1.3 Approach
In analysis of current routing algorithm we aim to implement different path met-
rics at same time and plot relevant graphs. We also aim to implement different
routing algorithms for single, single source shortest path calculation and k-shortest
path calculation.For options we are aiming to implement Bellman Ford and A-star
algorithms in place of Dijkstra and Hershberger algorithm in place of yen. To use
different path metrics we aim to implement packet dissection for Application Aware
Routing(A2R).
To implement traffic engineering(TE) in real time we aim to reduce number of
re-computations by implementing a path cache. This path cache stores time of hit,
path metric and path assigned between a (ingress-egress) pair. By this PACKET IN
packets of continuous traffic flow do not need re-computation of topology even if path
metric of network has changed.

3
Chapter 2

Background & System Model

2.1 Background

2.1.1 Network Performance Measures

Network performance may be defined as the analysis and review of collective net-
work statistics, to define the quality of services offered by the underlying computer
network. It is a qualitative and quantitative process that measures and defines the
performance level of a given network. It guides a network administrator in the
review, measure and improvement of network services. Network performance is pri-
marily measured from an end-user perspective i.e. the quality of network services
being delivered to the user. Broadly, network performance may be measured by
reviewing the statistics and metrics from the following network components:

• Network bandwidth - This refers to the data-carrying capacity of a network

or data transmission medium. It indicates the maximum amount of data that
can pass from one point to another in a unit of time. It emerges from study of
electromagnetic radiation, where it refers to the width of a band of frequencies
used to carry data.

• Network throughput - Amount of data that is actually being transferred

over the network in a given unit of time.

4
 • Network delay, latency - The term latency is used to refer to delay in data
communication that happens over a network.This may prevent the data from
taking full advantage of the network and effectively decreases the communica-
tion bandwidth.

• Data loss and network errors - Data loss refers to packets that may get
dropped while transmission over the network, it also encompasses packets that
may be lost or re-transmitted due to errors in transmission an subsequent
corrupt information.

The necessary information required for computation of the metrics is obtained

by real time monitoring of the network and analysing transmission parameters of
the open flow switches.

2.1.2 Traffic Engineering

Traffic engineering (TE) is an important mechanism to optimize the performance
of a data network by dynamically analyzing, predicting, and regulating the behav-
ior of the transmitted data. It has been widely exploited in the past and current
data networks. However, the past and current networking paradigms and their
corresponding Traffic Engineering solutions are unfavorable for the next generation
networking paradigms and their network management due to following reasons[3].

• Internet applications today require the underlying network architecture to re-

act in real time and to be scalable for a large amount of traffic. The ar-
chitecture should be able to classify a variety of traffic types from different
applications, and to provide a suitable and specific service for each traffic type
in a very short time period.

• With rapid growth in cloud computing and the demand of massive-scale data
centers, network management should be able to improve resource utilization
for better system performance.

Traffic engineering mechanisms in SDN can be much more efficiently and intel-
ligently implemented as a centralized Traffic Engineering system compared to the

5
conventional approaches because of the major advantages of the SDN architecture.
More specifically,SDN provides

1. Centralized visibility including global network information (e.g., network re-

source limitations or dynamically changing the network status) and global
application information (e.g., QoS requirements);

2. The programmability without having to handle individual infrastructure el-

ements, i.e., OF switches at the data plane can be proactively programmed
and dynamically reprogrammed by the centralized controller to optimally al-
locate network resources for network congestion avoidance and enhanced QoS
performance;

3. Multiple flow table pipelines in OF switches can make flow management more
flexible and efficient.

Figure 1: Scope of Traffic Engineering in SDN [3]

Traffic Engineering technology is of critical importance to the evolution and

success of SDNs. As shown in 1, current traffic engineering mechanisms mainly
focus on four thrusts including flow management, fault tolerance, topology update,
and traffic analysis including characterization.

6
 According to the basic operation of flow management in SDNs, when a flow arriv-
ing at switch does not match any rules in the flow table, it will send the first packet
of the flow to the controller,the forwarding path for the flow will be computed by the
controller, the controller will send the appropriate forwarding entries to install in the
flow tables at each switch along the planned path, and all subsequent packets in the
flow or even different flows with matching attributes will be forwarded in the data
plane along the path and will not need any control plane action. In this operation,
if the aggregated traffic consists of high number of new flows, a significant overhead
can be yielded at both the control plane and data plane. Moreover, the forward-
ing rule setup can also take time, so that the latency can be increased. Therefore,
to solve these problems, traffic engineering mechanisms for the flow management
should be designed to address the tradeoffs between the latency and load-balance.
To ensure the network reliability, SDN should have a capability to perform fail-
ure recovery transparently and gracefully, when a failure occurs in the network
infrastructure (i.e., controllers, switches and links) [5].To increase the networking
resiliency of SDN, in OF v1.1+, a fast failover mechanism is introduced for link or
node failures, in which an alternative port and path can be specified, enabling the
switch to change the forwarding path in the policy based routing without requiring
a round trip to the controller. Although the situation is much improved with cen-
tralized network management, achieving fast failure recovery is still very challenging
in SDN, because the central controller in restoration must calculate new routes and
notify all the affected switches about the recovery actions immediately. Moreover,
the failure recovery needs to consider the limited memory and flow table resources
at switches.
The topology update mechanism in SDNs focuses on the planned changes such as
the network policy rule changes, instead of the network element or link failures. Since
the centralized controllers manage all switches in SDN/OF networks by dynamically
configuring the global network policy rules, a certain level of required consistency
of the network policies needs to be guaranteed across the switches so that each
individual packet or flow should be handled by either the old policy or the new policy,
but not by the conflicting combinations. Moreover,during the policy updating time,

7
the affected flows may be dropped or delayed, which degrades the network QoS
performance or leads to wasting network resources. Therefore, the key challenge
in topology update is how SDN controller can efficiently update the network with
required consistency in (near) real time.

2.1.3 Traffic Engineering in Floodlight

Based upon the previously listed measures of network performance, floodlight also
encompasses certain other metrics apart from the basic metric of hop count between
switches.The metrics being Utilization, Latency, Link Speed, Hop counts that avoid
external links and simply Hop counts.
The Utilization metric in floodlight evaluates the real-time traffic flow on various
links and assigns appropriate weight to the links based on the actual traffic in order
of mega bits.The weights being assigned to the links depend on the amount of traffic
flow and does not take into consideration the actual link capacity. This results in
a weight assignment, where the links with equal amount of traffic get assigned the
same weights irrespective of the total capacity of traffic that can flow over them.The
assignment of weights is such that links with lower traffic are given lower weights.This
helps balance the traffic flowing over the network links and gives a higher priority
to the links over which the flow of traffic is less.This assignment approach when
implemented in real time by the controller results in a balanced traffic over network
links.

Figure 2: Sample Network [8]

For example in the network in 2 at if we assume same amounts of traffic to be

flowing on all the links the weight assigned to them will be equal irrespective of the

8
fact that the maximum available bandwidth of certain links is 2Gbps while of others
varies upto 8Gbps.
The latency metric takes into consideration the real time latency between the
links and uses them for weight assignment. Latency due to electrical factors over
the link is constant and does not vary in real time.While the latency due to network
congestion keeps varying according to the traffic flowing over the network.The metric
implemented in floodlight only takes into account the latency of the link present due
to electrical factors.The weight assignment here is to favor links with lower latency,
and to reduce the overall delay in communication over the network.However the
nature of paths decided does not change due to static nature of the metric considered.
The link-speed metric in floodlight focuses only upon the total bandwidth of
each link irrespective of the real time utilization of the links.This approach however
at times may result in congestion in networks because only the higher availability
links get lower weights, which is not changed later on.Thus resulting in congestion
over certain links and the network being underutilized in several cases.
The metrics for hop count are the basic metrics which only take into consideration
the total number of links that a packet need to traverse in its path from source to
destination. In order to implement this approach using the concept of metrics, all
the links are assigned equal weights. This assignment results least cost paths which
eventually also have the minimum number of hops.
After assignment of the weights according to the metrics, the floodlight controller
finds the least cost paths for the given source destination pairs.The algorithms used
are for finding both the single shortest path and K-shortest paths.This also involves
periodic re-computations of paths to account for the dynamic metrics which keep on
changing according to the conditions of the network, resulting in real time calculation
routes which are optimal.

9
2.2 Single Source Shortest Path Algorithms

2.2.1 Single Shortest Path

As current Floodlight controller is using dijkstra algorithm to calculate single short-
est path in network. It’s time complexity is O(E + Vlog(V)), where E is number of
links in network and V is number of nodes in network. To analyze it’s performance
we have used two more single shortest path algorithms. First is Bellman Ford and
second is A*.

• Bellman Ford algorithm is a dynamic programming algorithm that com-

putes shortest paths from a single source vertex to all of the other vertices in
a weighted digraph. It’s complexity is O(V*E). It is slower than dijkstra but
more versatile in domain. It’s implementation is way easier than dijkstra. So
we used it to generate data and compare performance of other algorithms.

• A* is an informed search algorithm, or a best-first search, meaning that it

solves problems by searching among all possible paths to the solution (goal)
for the one that incurs the smallest cost (least distance travelled, shortest time,
etc.), and among these paths it first considers the ones that appear to lead most
quickly to the solution. It is formulated in terms of weighted graphs: starting
from a specific node of a graph, it constructs a tree of paths starting from that
node, expanding paths one step at a time, until one of its paths ends at the
predetermined goal node. It’s complexity depends upon heuristics. With best
heuristics it is similar to dijkstra.Dijkstra finds the minimum costs from the
starting node to all others. A* finds the minimum cost from the start node to
the goal node. Dijkstra’s algorithm finds the shortest path definitely. On the
other hand A* depends on the heuristic.

2.2.2 K-Shortest Path

To implement path metrics and use network resources efficiently only one shortest
path between source and destination is not enough. It would be too much calcu-
lation if at each PACKET IN, topology is reset according to path metric and a

10
shortest path is calculated. To avoid this we calculate and store k shortest paths
between source and destination. When path metric is changed we just check these
paths for that metric and choose the best one. We have used two algorithms to cal-
culate k-shortest paths. First is yen’s algorithm and second is hershberger’s rotation
algorithm.

• Yen’s algorithm computes single-source K-shortest loopless paths for a graph

with non-negative edge cost. It employs any shortest path algorithm to find
the best path, then proceeds to find K 1 deviations of the best path.[9] Time
complexity of this algorithm is O(K*V(E+VlogV)). This algorithm is imple-
mented in floodlight controller.

• Hershberger’s rotation algorithm is based on replacement paths[11] al-

gorithm. It yeilds a factor O(n) improvement for k-shortest path calculation.
Time complexity of this algorithm is O(K(E+VlogV)). This algorithm uses
efficient replacement paths subroutine which speeds up the process. Only
problem with this algorithm is that it fails over some directed graphs but
failure is easily detected and a slow but correct algorithm runs at it’s place.
However chances of failure is less than 1%, so we have tried to implement this
into floodlight.

11
Chapter 3

Application Aware Routing(A2R)

In SDN

3.1 Why Application specific Routing ?

Nowadays, it is clear that networking plays a very important role in our society.
As a foundation of information network, a reliable and highly efficient networking
infrastructure is of utmost importance. However, it is becoming increasingly diffi-
cult for the traditional networking infrastructure, designed decades ago, to satisfy
the requirements of modern application. For example, in general network, to avoid
problem caused by information loop such as broadcast storm, STP and many vari-
ations of it is implemented, STP(Spanning Tree Protocol) is a good solution for the
network back when it was originally designed. Unfortunately, STP prevents loops
by deliberately ignore some links. This behavior prevents the network from being
fully utilized to its maximum potential.
In any given network system,there usually are various kinds of application run-
ning on it concurrently. Application performance is of course affected by network
conditions. However, different aspects of network conditions and properties such
as bandwidth, latency or distance affect each application differently depend on the
application. We define application affinity to different network properties as require-
ments.

12
 Also, in a network, there may be more than one path (route) between any pair
of entity. Each of these paths may have different property. For example, one path
may be able to provide higher bandwidth while the other may have lower latency.
With recent technology such as tunneling, overlay network and virtualized network,
it is becoming increasingly difficult to find an appropriate path for the application,
as a shortest path is not necessarily always the best path anymore.

3.2 What is Application aware Routing ?

Each application running on a network infrastructure may have different require-
ments. For example, the Secure Shell protocol requires as little latency as possible
while the FTP(data connection) requires more bandwidth for faster file transfer. To
achieve the best performance, the underlying network infrastructure should be able
to take each application requirements into account and optimizes itself accordingly.
This technique is called application aware networking.
When the client transmits an IP packet, the switch inspects the packet and
depending on the policy/rule installed in it, forwards the packet on a particular
route. If the switch doesnt have any policy/rule installed, it to inspects the packet
header and determines the type of packet (TCP, UDP, HTTP, etc.), and installs a
policy/rule on the switch instructing it to forward packets along a particular route.
One example of application-aware networking is Predictive and Distributed Rout-
ing Balancing (PR-DRB). This is a method for managing network performance by
predicting network communication patterns and distributing network communica-
tions across multiple paths based on those prediction. However,to actually realize
application-aware networking, especially in general cases can be difficult.

13
3.3 Implementation of A2R with SDN
A Software-Defined Network (SDN) is a technology that allows researchers to do
networking experiment such as testing new network protocol at the actual network
line speed using standard devices. Open Flow, an implementation of SDN, provides
standardized interfaces to be implemented by vendors.Unlike traditional networking
paradigm, Open Flow splits a network into data plane and control plane. Data plane
is underlying mechanism of a switch that handles actual data movement from one
interface to others. Control plane is the part that handles routing decisions such as
which packet goes to where. In traditional network, data plane and control plane
reside together in each switch. However, Open Flow separates control plane out
into centralize programmable component called Open Flow controller. When any
event occurs at the switch, it notifies the controller of the event. The controller then
makes a decision according to how it is programmed and sends a response back to
the switch to tell it how it should behave. The result is sent back in a form of new
entry to flow table in the switch. This flow table will be used for future decision
instead of consulting with the controller whenever anything occurs. Using an SDN
implementation such as Open Flow, it is now possible to implement application-
aware networking without being limited by traditional paradigm of network analysis,
which relied on line-rate packet analysis. With Open Flow, it is now possible to
allocate different route specifically to each connection of an application.

Figure 3: Application Aware Routing over network [8]

14
 In our project, we have analyzed the packets that are received at the controller.
Its different layers are extracted and information about the packet is analyzed.
Transport layer uses ports t multiplex packets among different applications. Since
various applications like Web Server, FTP server runs on standard port, transport
layer port number can be used to identify the type of application to which the
packets belong to.The flow info object is obtained and is sent into flow classifier and
the flow is classified.

15
Chapter 4

Model Implementation & Network

Simulation

4.1 Model Implementation

Our project deals with three major areas namely Application Aware Routing(A2R),
shortest path algorithms and network metrics.

4.1.1 Application Aware Routing

As previously discussed, SDN provides adequate network information for better
implementation of traffic engineering concepts. One such idea is the implementation
of application aware routing.
The objectives of Application Aware Routing Implementation are:

1. Routing based on type of application served by the network as opposed to

considering only destination.

2. Performing a better differential routing which increases the utilization of links

in the network.

3. Enabling better network performance of the network for individual applica-

tions based upon the networking protocols being used.

16
 4. Reducing path re-computations for different application dependent routing
metrics by implementing a path cache on the server.

The classification of packets for application aware routing is done based upon
protocols from the network layer to the application layer of the protocol stack.The
first distinction is made between IP and ARP packets.The packets detected to be of
the IP layer are further dissected while those of the ARP protocol are simply routed
over the default configuration provided by floodlight i.e of minimum hop routing.
For the IP packets, further analysis is required to distinguish between the packets
being either UDP or TCP.This classification can then be used to broadly classify
the packets and estimate the type of metric required.Bandwidth and latency are
two major factors that have the most impact to performance of network applica-
tions. However, not all applications are affected by those two factors equally. Some
application may perform better when more bandwidth is available while others are
benefit more from lower latency. Therefore, we categorize application into two types,
bandwidth-oriented application and latency-oriented application based upon the
transport layer protocol.
Bandwidth-oriented application is a category of application that achieves higher
performance when more bandwidth is avail- able. Most applications that involve
transferring a large amount of data fall into this category. Example of application
in this cat- egory includes HTTP, FTP and media (video/audio) streaming.
Latency-oriented application is a category of application that performs better
over low latency network. Usually, applications that involve remote controlling or
real-time communication fall into this category. For example, SSH is considered as a
latency- oriented application. Most online gaming, although using its own protocol,
often fall into this category as well.
Apart from this classification may also be done on the application layer of the
packets, which is devised from the port number used.

17
4.1.2 Path Cache
It is a cache of path,path metric and path hit time(latest when that path has been
pushed into switches). It has a map of PathTime and PathMetric, two data struc-
tures we implemented. PathMetric stores path identifiers and current path metric
and methods to use them and PathTime stores path assigned and it’s hit time.

Need For Path Cache

Even after implementing a better algorithm to calculate shortest path, number of
re-computations of topology was very high in Application Aware Routing(AAR).
Some cases of this problem are :–

• On continuous traffic a source switch sends PACKET IN after a fixed amount

of time. In between that time if a different type of path metric is requested,
topology needs re-computation and it may be possible that traffic of previous
path has been disrupted. New re-computation can affect all paths according
to metric. So if two ingress-egress pairs are transferring different types of
data(different path metric) topology re-computation will be frequent. It will
slow the process of path assignment in controller.

• If traffic is of same type(same path metric) then in continuous traffic, controller

checks all k-paths every time a new PACKET IN comes. Information is fetched
from statistics API that takes some time. It can be avoided using path cache.

Path Cache Implementation

Path cache is a map of these two data structures(10,??).
Method for using path cache is implemented in routing module. This module
operates when PACKET IN comes and paths for packet forwarding are decided here.
Algorithm used is :–

18
Figure 4: Path cache algorithm flowchart

19
 Figure 5: PathMetric

Path Cache Description

Algorithm in above section update the path cache. When PACKET IN comes, it’s
PathMetric is created and checked that whether it is present in the path cache or
not. If it is present then appropriate actions are taken otherwise default procedure
occurs and at the end path cache is updated with current time.For instance we have
taken MAX TIMEOUT TIME thirty seconds. It is dynamically updated according
to path hits.
It is implemented in topology module’s topology manager class. Packet dissection
is done here. Link layer frames reach here, we get payload of upper layer and check
for upper layer protocols.

20
4.1.3 Shortest Path Algorithms
• Bellman Ford Algorithm Implementation of algorithm is done in topology
module of floodlight controller. Bellman procedure takes link costs, links and
source as input and provide a broadcast tree. The root of tree depends upon
whether it is destination rooted or source rooted. Path is then extracted from
that broadcast tree.

• A* Algorithm It is also implemented in the topology module. It takes source,

destination, link costs and link and returns a path between source and desti-
nation.

• Hershberger’s Rotation Algorithm It is also implemented in the topology

module. It stores k shortest paths between source and destination. From this
storage different path metric costs are calculated.

21
 Figure 6: Bellman Ford Algorithm flowchart

4.2 Network Simulation

The domain of our project required considerable testing and analysis of network
parameters which required either the presence of a physical network with support
for OpenFlow or an emulation environment which could provide us with a virtual
platform for fulfilment of our analysis needs. Thereby making emulation necessary.

4.2.1 Tools Used

1. Mininet
Mininet is a software emulator for prototyping a large network on a single
machine. Mininet can be used to quickly create a realistic virtual network

22
Figure 7: A star algorithm flowchart

23
 24

Figure 8: Hershberger Algorithm Flowchart

 running actual kernel, switch and software application code on a personal
computer. Mininet allows the user to quickly create, interact with, customize
and share a software-defined network (SDN) prototype to simulate a network
topology that uses OpenFlow switches.

• Provides a simple and inexpensive network testbed for developing Open-

Flow applications
• Enables multiple concurrent developers to work independently on the
same topology
• Supports system-level regression tests, which are repeatable and easily
packaged
• Enables complex topology testing, without the need to wire up a physical
network
• Includes a CLI that is topology-aware and OpenFlow-aware, for debug-
ging or running network-wide tests

2. NTOP
ntop (stylized as ntop) is computer software that probes a computer network to
show network use in a way similar to what the program top does for processes.
In interactive mode, it displays the network status on the user’s terminal. In
Web mode, it acts as a web server, creating a HTML dump of the network sta-
tus.Here for our project we have used ntop tools to generate different network
graphs.

3. IPERF
Iperf is a commonly used network testing tool that can create Transmission
Control Protocol (TCP) and User Datagram Protocol (UDP) data streams
and measure the throughput of a network that is carrying them. Iperf is a
tool for network performance measurement written in C.

25
4.2.2 Environment Setup
The simulation encvironment was setup using mininet to simulate the openflow
switches, Iperf was used for traffic generation and ntop tool was used to monitor the
various network interfaces.The controller used was floodlight.
The steps involved for the environment setup

• Mininet was setup as virtual machine and different kinds of topologies were
simulated using miniedit.

• The iperf tool helped in setting up a few servers over the simulated hosts.Other
hosts were made to communicate with the servers for periodic intervals to
generate traffic over the network.

• The ntop tool was also setup as a part of the virtual machine housing mininet.

• Ntop provided with real time traffic analysis and status of various links on the
network.

26
Chapter 5

Results

The network topology used for testing various metrics consists of 7 switches con-
nected to a central controller. Some of the hosts acted as servers while others were
used as clients.

Figure 9: Network Topology for simulation

The other topology used for simulation consisted of 6 switches two of which have

27
been arranged on alternate paths , one of which is selected on the usual metrics
while on other both have traffic.

Figure 10: Network Topology for simulation

Figure11 shows topology re-computation time for different shortest path algo-
rithms for different size of networks. Tree topologies of different heights have been
used for it. This shows that as number of levels increase both number of switches
and time of re-computation increase exponentially. A* is performing a little better
than dijkstra due to using heuristic approach.
Figure12 represents traffic on switches s2,s5 and s7 with hop count as path
metric. This shows that all traffic passes by switch s5 because path s1-s5-s4 has
minimum hop count. This is floodlight controller’s default path metric and used for
comparison only in our application.
Figure13 represents network state with utilization as path metric. This shows
that at start all traffic is on single switch but as traffic increases it balances it by
directing some traffic to other paths. Some of other paths are of more hop count

28
 Figure 11: Re-computation time of different shortest path algorithms

than minimum. Here some traffic is on s2 too which is in the path of higher hop
count.
Figure14 represents network state with latency & utilization as path metric.
Latency here represents static latency. This path metric is created by using both
parameter statistics. This parameter uses maximum bandwidth to implement uti-
lization balance. This shows that by using this metric network resource utilization
is better. Traffic is divided according to latency and maximum bandwidth.
Figure15 represents network state with latency as path metric. This shows that
low latency

29
Figure 12: Network state with Hopcount as metric

30
Figure 13: Network state with Utilization as metric

31
Figure 14: Network state with Latency & Utilization as metric

32
Figure 15: Network state with Latency as metric

33
Chapter 6

Future Works

6.1 Shortest Path Algorithm

At this time we have only studied Hershberger’s Rotation Algorithm in theory and
implemented it into basic digraphs for testing. We are aiming to test it in real net-
works in future by modifying it according to floodlight data structures and modules.
We are also aiming to design a better heuristic function for A* so that it can replace
dijkstra in floodlight. We aim to test some other optimization algorithms to perform
routing in SDN in better complexity.

6.2 Application Aware Routing

• For efficient Application Aware Routing we have implemented a path cache
with basic push and update entry mechanism. We are aiming to use a better
algorithm to handle more data efficiently. We are also aiming to find more use
cases for this path cache and merge it with forwarding and topology module
also.

• When testing with real-world traffic, it is felt that initial Port based traffic clas-
sification 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

34
 to classify the traffic.

• 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. We are aiming to find a
better approach to identify the traffic on secure protocols.

35
Chapter 7

Conclusion

The application presents the design of A2R-Application Aware Routing in Software

Defined Networks. It enables proper use of available network characteristics to effi-
ciently implement traffic engineering. Thereby increasing overall network utilization
and limiting the number of re-computations for application aware routing. It also
presents a more diverse view of algorithms that can be used in routing in Software
Defined Networks.

36
References

[1] Open Networking Foundation, ”Software defined networking: the new norm for
networks,” Web white paper.

[2] Q. Ma, and P. Steenkiste. ”On path selection for traffic with bandwidth
guarantees,” IEEE international conference on network protocols; 1997.

[3] Ian F. Akyildiz a, Ahyoung Lee a, Pu Wang b, Min Luo c, Wu

Chou c ”A roadmap for traffic engineering in SDN-OpenFlow networks”, The
International Journal of Computer and Telecommunications Networking.

[4] Slavica Tomovic, Igor Radusinovic ”Fast and efficient bandwidth-delay

constrained” routing algorithm for SDN networks.

[5] B. Niven-Jenkins, D. Brungard, M. Betts, N. Sprecher, S. Ueno ”Re-

quirements of an MPLS Transport Profile, RFC 5654, Tech. Rep.”; September
2009

[6] Saro Velrajan. ”Application-Aware Routing in Software Defined Networks”.

Whitepaper, Aricent; 2013.

[7] Harishkumar Bhokare,Mansi Bhonsle. ”Application Aware Routing in

SDN”. International Journal of Science and Research (IJSR) ISSN (Online):
2319-7064; 2013.

[8] Pongsakorn U-chupala, Kohei Ichikawa, Putchong Uthayopas,

Susumu Date,Hirotake Abe ”Designing of SDN-Assisted Bandwidth and
Latency Aware Route Allocation”. IPSJ SIG Technical Report.

37
[9] Jin Y. Yen ”Finding The K shortest Loopless Paths in a Network”. MAN-
AGEMENT SCIENCE; 1971.

[10] John Hershberger, Matthew Maxel, Subhash Suri ”Finding the k

Shortest Simple Paths: A New Algorithm and its Implementation”.

[11] J. Hershberger and S. Suri. Vickrey ”Prices and shortest paths: What
is an edge worth?”. In Proceedings of the 42nd Annual IEEE Symposium on
Foundations of Computer Science; 2001.

38