978-1-4799-5874-0/14/$31.00 ©2014 IEEE 1

Implementing Shortest Path Routing

Mechanism using Openflow POX Controller Rihab JMAL and Lamia CHAARI FOURATI

Laboratory of Electronics and Information Technologies (LETI) Sfax University, National School of Engineering

B.P.W, 3038 Sfax, Tunisia lamiachaari1@gmail.com

Abstract— Network management is a challenging problem of

wide impact with many enterprises suffering significant financial losses. The Software Defined Networks (SDN) approach is a new paradigm that enables the management of networks with low cost and complexity. The goal of SDN is to make sure that all control-level logical decisions are taken at a central way, as compared to traditional networking, wherein control-level decisions are taken locally and intelligence is distributed in each switch. The aim of this paper is to present a routing solution based on SDN architecture implemented in OpenFlow environment and providing the shortest path routing. The simulations have been carried out in an emulation environment based on Linux and POX controller.

Keywords— SDN, OpenFlow, Shortest path routing, POX, Wireshark.

I. INTRODUCTION

With the explosive growth of data traffic over the past few years, the bottlenecks of traditional data networks have been exposed. An emerging technology, OpenFlow [1], has been developed at Stanford University, it is currently gaining more and more support from companies such as Cisco, Juniper, Microsoft, Google and Facebook. OpenFlow allows the realization and implementation of reconfigurable networks architectures named SDN (Software Defined Networking) [2] which present an attempt to solve the bottlenecks of traditional routing based networking deployments. Thus, OpenFlow is the most advanced communication protocol between a control plan (one or more controllers) and a data plan (network devices such as switches and routers). OpenFlow is used as a basic protocol in centralized routing where transfer tables inside switches are programmed and controlled remotely. Having this central approach will reduce the need for N number of intelligent nodes in an N-nodes topology. OpenFlow technology allows network administrators to segment telecommunication networks programming the devices involved in the system. OpenFlow devices identify different traffic flows following rules pre-configured by network managers. This technology virtualizes network into flows in a way that there are no interferences between traffics. Furthermore, once the virtualization is done the network

administrator can delegate the management of network segment(s) to the researchers as if it was a new network. An OpenFlow controller is responsible for managing network devices, ports and queues assigned to the physical host. Among the most used controllers in the fields of research we highlight NOX [3], the first controller developed, POX [4], a Python-based SDN controller platform geared towards research and education, Beacon [5], a Java-based OpenFlow controller platform, Big Switch [6], to control big networks and Floodlight [7], evolved version of Big Switch. Our work is based on POX controller which is the youngest controller, it is a platform for the rapid development and prototyping of network control software, characterized by reusable sample components for path selection, topology discovery, etc. We focused on determining the shortest path routing in order to meet different criteria of quality of service through this new technology OpenFlow. The rest of this paper is organized as follows: Section two presents the basic concepts of the reconfigurable network approach. Section three discusses the OpenFlow technology and describes the architecture. Section four is reserved to the deployment and implementation of POX controller under OpenFlow network. Finally, conclusions and future works are drawn in the section five.

II. BASIC CONCEPTS OF THE RECONFIGURABLE NETWORK

APPROACH

Software Defined Networking is an approach centralizing network management by establishing the decoupling of hardware and software elements. It allows researchers to orchestrate and automate a computer network or telecommunications network without having to physically access the hardware (routers, switches, etc…). SDN avoid repeating the same manipulations on the various components and provides a central software interface allowing control of the entire network. Thus, the objective of the SDN approach is to simplify network management by centralizing intelligence historically embedded in physical equipment, take advantage of resource sharing virtualization, user personalization, and rapid network configuration. In fact, many actors propose

978-1-4799-5874-0/14/$31.00 ©2014 IEEE 2

OpenFlow, which is an Open Source protocol, as reconfigurable networks standard. The SDN approach brings in advantage an innovative side, virtualizing a programmable network, the barrier to entry new ideas is reduced. For example, researchers can test their ideas on a segment of a network without additional hardware investment. In addition, this approach based on virtualization allows administrator to configure the network, to change its topology, its application without physically modifying the network equipment and subsequently no additional investment, which gives the flexible, efficient and economical aspect.

The OpenFlow protocol is the base of reconfigurable networks architectures, it provides the interface between the control layer and the infrastructure layer by applying rules of transmission. Fig .1 illustrates the layered model associated for SDN architectures.

Fig. 1 The layered architecture model of reconfigurable networks

SDN network is characterized by an architecture based on three layers the infrastructure, the control and the applications. The infrastructure layer, it corresponds physically to network devices with programmable network interfaces between the control plane and the data plane based on OpenFlow protocol. The control layer incorporates an SDN controller as a "middleware" that serves as the key of the whole architecture. In an OpenFlow environment, the controller uses the OpenFlow protocol to communicate with network devices. The application layer communicates with SDN controllers via open and programmable API. Applications are those that offer services such as the virtualization of network switches, firewalls and flow balancers. Most innovations are coming in networks occur in the SDN applications.

III. OPENFLOW MECHANISM

A. Presentation

OpenFlow is the most advanced communication protocol between a centralized control plane (one or more controllers) and the data plane (switches, routers ...).

The development of OpenFlow began in 2007 as part of collaboration between the academic world (universities) and the industrial world. It is standardized by the Open Networking Foundation (ONF) [8] and implemented by many manufacturers, including Cisco, IBM, Juniper, HP, NEC and Ericsson. According to the OpenFlow protocol, routing decisions are taken by the controller for each data flow and pushed in switches as simple switching commands.

OpenFlow allows to easily deploying innovative routing protocols and switching in the network without the need to physically change the network. It is used for applications such as virtual machine mobility [9], secured networks [10] and in the next generation of IP mobile networks [11]. The OpenFlow protocol provides an open, programmable and virtualized network.

• Open: The fact of using a standard set of instructions in the communication process between the OpenFlow controller and the OpenFlow switch gives an open network independently of vendors and network devices manufacturers.

• Programmable: The instruction set is still evolving, OpenFlow is used to create sets of rules that work in combination with the configuration options for a switch vendor, or independently of them. OpenFlow allows users to test new ideas and create new protocols independent of any vendor. Moreover, it is possible to program a network for the specific requirements of a given application.

• Virtualized: OpenFlow can specify different forwarding rules for various types of data and allows creating several logical expedition paths on the same physical network. This corresponds to network virualisation.

B. Reconfigurable architecture based on OpenFlow

To highlight the key elements of OpenFlow architecture, we consider the case of an OpenFlow switch in communication with an OpenFlow controller. Fig. 2 illustrates the presence of the OpenFlow protocol in reconfigurable network architecture.

• OpenFlow switch: consists of two modules: the flow table and the secure channel.

� The flow table indicates to switch how processing each data flow by associating an action with each flow table entry.

� The secure channel ensures safe passage of rules between OpenFlow controller and OpenFlow switch.

978-1-4799-5874-0/14/$31.00 ©2014 IEEE 3

Fig. 2 OpenFlow network architetcure

• OpenFlow controller: is who manages switches, ports of each switch, the quality of service (QoS) and the queues assigned to the physical host. It processes packets reported in the OpenFlow switch.

• OpenFlow Protocol: provides an open standardized communication interface between OpenFlow controller and OpenFlow switches.

Thus, the good working of OpenFlow is related at its design based on the use of flow table as shown in Fig. 3.

*Forward packet to a port list *add/remove/modify VLAN Tag *Drop packet *Send packet to the controller

Fig. 1 Composition of flow table

IV. DEPLOYMENT AND IMPLEMENTATION OF POX

CONTROLLER IN OPENFLOW NETWORK

A. Establishment of communication channels

between switches and controller

During this initialization phase, several OpenFlow messages are exchanged between controller and switches such as the following messages: SM, CSM, Feature Request CSM, Set config and Feature Replay. Messages exchanged when establishing a connection between switch and controller, are described below. "SM" is a symmetrical message while "CSM" is an asymmetric message for communication between switch and controller. Using the "Hello (SM)" packets, the switch identifies the existing controller then he agrees with the controller on the version number of the OpenFlow protocol will be used for communication. Messages exchanged when establishing a connection switch- controller are described below: - The controller sends a features request (CSM) to see which ports are available.

- The controller asks the switch to use specific parameters with the message "set config ". - The switch responds with a message "features reply (CSM)" to identify the physical ports, port capacity, the actions supported, the size of buffer; ... Different messages exchanged during this initialization phase were captured with "Wireshark" tool and are illustrated in Fig. 4.

Fig. 4 Messages exchanged during the establishment of a switch-controller connection

The switch and controller exchange between them "hello request (SM)" messages with a random transaction ID and they respond with "hello reply (SM)" messages, repeating the same transaction number. This process called "Keep alives" is repeated every 15 seconds. All flows with type OpenFlow have a timeout value "idle_timeout" set by default to a value of 60 seconds. If no new traffic has been adapted to a rule before the end of "idle-timeout" value the OpenFlow protocol removes the flow and informs the controller of this suppression by sending a message "Flow removed."

B. Shortest path routing based on OpenFlow with

POX controller

1) Topology specification

We created a topology containing 12 hosts (h11, h12, h21, h22, h31, h32, h41, h42, h51, h52, h61, h62), 6 switches (s1, s2, s3, s4, s5, s6) and a controller as shown in Fig. 5.

Fig. 5 Reconfigurable network architecture created

2) Implementation of POX controller

978-1-4799-5874-0/14/$31.00 ©2014 IEEE 4

We use an OpenFlow 1.1 User Switch Implementation [12] inside a Mininet [13] testbed. Mininet is a platform that enables creation of OpenFlow based software defined networks on a single PC using Linux processes in network namespaces.

The routing mechanism OpenFlow using the POX controller provides the shortest path in the reconfigurable network, due to the "forwarding.topo_proactive" module specific to POX controller which exists only in the 'carp' version.

Indeed, the "forwarding.topo_proactive" module depends on several other modules, the most important are the “topology discovery” module and the "spanning tree" module as shown in Fig. 6.

Fig. 6 Interaction of the components with the "forwarding.topo_proactive" module

• “openflow.discovery”: This module is designed for automatic discovery of topology, is necessary for network recovery in case of topology change. It is based on LLDP « Link Layer Discovery Protocol ».

• "openflow.spanning_tree": This module uses the topology discovery module to build a view of the network topology. It allows developing a spanning tree and prevents flooding on disabled ports. The objective of the "spanning tree" module is to disable certain ports that are not departed from spanning tree. This means that even if a switch has received an order to deliver a frame, it must be sent only on active interfaces to eliminate loops.

When a host sends traffic to another, the switch asks the POX controller how to handle this traffic. The discovery module detects the topology and passes the traffic to the routing module "forwarding.topo_proactive" (if the destination address is known) or "SpanningTree" module (if the destination address is unknown). The routing module "Topo Proactive" is used to transmit traffic through the shortest path between the source and destination. Where the destination is unknown or unspecified, "spanning tree" module is used to broadcast the traffic across the network.

In order to evaluate the performance of POX controller which presents a shortest path routing algorithm supported by the OpenFlow protocol, we chose the scenario of transmission

from h11 to h62. We note that the route traversed is h11 �(S1-1�S1-4)�(S3-5�S3-7)�(S6-4�S6-3)�h62 as presents Fig.7, it confirms that it is a shortest path algorithm.

Moreover, we repeat the scenario but with creating a rupture by cutting the connection between the switch 3 (SW3) and the switch 6 (SW6). We note that the POX controller covered the new topology and the flow OpenFlow has followed the shortest path between the source host "h11" and destination host "h62" as shown in Fig.8.

Fig. 7 Route traversed by "forwarding.topo_proactive" module

Fig. 8 Route traversed by "forwarding.topo_proactive" module after rupture

The curves show the number of packets transferred in seconds for each protocol (OpenFlow, LLDP, TCP and ARP). Fig. 9 illustrates the statistics on the various protocols used during the packet transfer from host "h11" to host "h62".

In Fig. 10, we present the graphs relating to frames exchanged during the execution of the "forwarding.topo_proactive" module.

Switch

POX CONTROLLER

openflow.spanning_tree

Host

Host

openflow.discovery

forwarding.topo_proactive

Data

Control

978-1-4799-5874-0/14/$31.00 ©2014 IEEE 5

Fig. 9 Statistics on different protocols during the execution of the "forwarding.topo_proactive" module

Fig. 10 Graphs of the frames exchanged on all interfaces using the "forwarding.topo_proactive" module

The graph describing throughput of TCP over the time in seconds for all of the network interfaces according to the "forwarding.topo_proactive" module is shown in Fig. 11 and according to the « openflow.spanning_tree » module is shown in Fig. 12.

Fig. 11 Throughput graph according to the "forwarding.topo_proactive" module

Fig. 12 Throughput graph according to the "openflow.spanning_tree" module

We note that throughput was increased exponentially when the "forwarding.topo_proactive" module was implemented compared to the "openflow.spanning_tree" module. Statistics on traffic from the execution of different modules: "openflow.discovery", “openflow.spanning_tree” and "forwarding.topo_proactive" are grouped in table1.

Table 1: Statistics on traffic resulting from the execution of the «openflow.discovery», «openflow.spanning_tree» and

«forwarding.topo_proactive» modules

Captured packet

Avg.packet/s Avg.MBit/s

«openflow.discovery» 38773 17.633 0.011 «openflow.spanning_tree» 41786 27.801 0.018

«forwarding.topo_proactive» 100137 139.005 0.158

From table1 we note that the average overload after execution of topology discovery module is in the order of 0.011 Mbit / s, 0.018 Mbit / s for spanning tree module and 0.158 Mbit / s for topo_proactive module. This led us to evaluate the overhead caused by the shortest path routing protocol when openflow controller is used.

V. CONCLUSIONS

978-1-4799-5874-0/14/$31.00 ©2014 IEEE 6

OpenFlow presents a promising technology for enabling advanced functionality in programmable networks. In this paper we first introduced the basic concepts of the reconfigurable network approach with presenting the layered architecture of Software Defined Networking approach. Next, we presented the OpenFlow technology and discussed about it as an SDN example. Then, we succeeded to implement the shortest path routing algorithm deployed with POX controller in OpenFlow network. In future work we focalized our study on content centric network supervision using openflow controller.

REFERENCES

[1] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow: enabling innovation in campus networks,” SIGCOMM Comput. Commun. Rev., vol. 38, no. 2, 2008.

[2] A.C. Risdianto, E. Mulyana, “Implementation and analysis of control and forwarding plane for SDN”, Telecommunication Systems, Services, and Applications (TSSA), 2012 7th International Conference on, Bali, 30-31 Oct. 2012.

[3] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker, “Nox: towards an operating system for networks,” SIGCOMM Comput. Commun. Rev., vol. 38, no. 3, pp. 105–110, Jul. 2008.

[4] “Pox homepage,” http://www.noxrepo.org/pox [5] “Beacon homepage,” https://openflow.stanford.edu/display/Beacon/

Home [6] “Bigswitch homepage,” http://www.bigswitch.com/ [7] “Floodlight homepage,” http://floodlight.openflowhub.org [8] Open Networking Foundation. [Online]. Available:

https://www.opennetworking.org/ [9] Cisco, “Cisco Overlay Transport Virtualization Technology

Introduction and Deployment Considerations,” tech. rep., Cisco Systems, Inc., January2012.

[10] S. Srivastava, G.C.Nandi, “Enhancing the efficiency of secure network monitoring through mobile agents”, Computer and Communication Technology (ICCCT), 2010 International Conference on, Allahabad, Uttar Pradesh, 17-19 Sept. 2010.

[11] F. Giust, C.J. Bernardos, “Mobility management in next generation mobile networks”, World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2013 IEEE 14th International Symposium and Workshops on a, Madrid, 4-7 June 2013.

[12] “OpenFlow 1.1 Software Switch.” [Online]. Available: https://github.com/TrafficLab/of11softswitch “Mininet: rapid prototyping for software defined networks.” [Online]. Available: http://yuba.stanford.edu/foswiki/bin/ view/ OpenFlow/ Mininet