universidad politecnica de madridoa.upm.es/54392/1/tesis_master_saloum_jimbara.pdf · within iot...

UNIVERSIDADPOLITECNICA DE MADRID

Escuela Tecnica Superior de Ingenierıa ySistemas de Telecomunicacion

Master en Ingenierıa de Sistemas y Serviciospara la Sociedad de la Informacion

Master Thesis

Usability of SDN RoutingWithin IoT Robotics

Saloum JimbaraJune 5, 2018

UNIVERSIDADPOLITECNICA DE MADRID

Escuela Tecnica Superior de Ingenierıa ySistemas de Telecomunicacion

Usability of SDN RoutingWithin IoT Robotics

Master Thesis

AuthorSaloum Jimbara

SupervisorProf. Ph.D. Jose-Fernan

Martınez OrtegaJune 5, 2018

Usability of SDN Routing Within IoT Robotics

Master en Ingenierıa de Sistemas y Serviciospara la Sociedad de la Informacion

Trabajo Fin MasterTıtulo Usability of SDN Routing Within IoT Robotics

Autor Saloum Jimbara

Tutor Dr. Jose-Fernan Martınez Ortega, V°B°:

Ponente

TribunalPresident Prof. Juana Gutierrez Arriola

Secretario Prof. Vicente Hernandez Dıaz

Vocal Prof. Gregorio Rubio Cifuentes

Fecha de lectura

Calificacion

El Secretario:

I


Acknowledgement

All thanks and praise first goes to almighty God without whose will nothinghappens. I may not have reached this far without the support and encour-agement of many people.

First and foremost, I would like to express my sincere gratitude to my super-visor, Prof. Jose-Fernan Martınez-Ortega for his supervision, support, andencouragements during the process of this master thesis project. My specialthanks also go to all the members of Next-Generation Networks and Services(GRyS) research group of UPM. I am very grateful for all their support inmaking this master theses success. Members of GRyS research group are allknowledgeable and great researchers.

I may not do just without thanking all those who financially supported meduring the course of my whole master program. Thank you all who oneway or the other supported me financially for the completion of my masterprogram. May God reward you for all your supports.

No one deserves my deepest thanks more than my beloved family. Thankyou mother for all your prayers and words of encouragements. I quote, “doyou want to know who you are? Don’t ask. Act! Action will delineate anddefine you”, Thomas Jefferson. Special thanks to you my lovely wife, SohnaKebbeh. Your actions already defined you after unconditionally taken own-ership of all our family affairs in my absence. May God be the one to makeyou happy in this world and hereafter. My son, Muhammed S. Jimbara Iwould like you to know that, “life is a succession of lessons which must belived to be understood”, Helen Keller. I knew how much you suffered whileI was absent. I thank God for making you this strong and for ending yoursufferings. As young as you are, you already experienced how selfish andnarrow-minded some humans can be. I am proud of your this experienceSon. For my lovely daughter, Fatima S. Jimbara I thank you for your un-derstanding during the time I was leaving you. I can remember breakingthe bond with you when I was set to leave for studies. This was before youturn to one year when we were getting to be good friends. Thank you sweetdaughter for your patience.

II


Abstract

Increase in urbanization has greatly decrease manpower in agri-cultural sectors. With the growing world population, the demand foragricultural products is increasing. Thus a more cost-effective andmodern agriculture needs to be addressed. To achieve a cost-effectivemodern agriculture, a simple, reliable, and manageable routing be-tween the nodes of IoT Robotics networks for precision farming areneeded. The focus of this paper is to enhance routing within IoTRobotics networks for precision farming using Software Defined Net-working (SDN) technologies.

Current routing protocols for IoT robotics solve specific issues each.Some of the issues with the nodes are high energy needs and resourceconstraints. This is as a result of both the controller and data planesof the routing function housed within the same node. SDN routingwithin IoT Robotics network is proposed in this paper to reduce en-ergy needs and resource constraints of the nodes as well as to providesimple, reliable and more manageable routing within IoT Roboticsnetworks. Environment setup for the demo of SDN routing withinIoT Robotics networks was made using Ubuntu local machine, vir-tualization system, Mininet Virtual Machine (VM), MiniEdit, POXcontroller, one Ubuntu VM, and Wireshark. In the demo four sce-narios were simulated. The first scenario shows the building of flowin directly-connected nodes by SDN controller to enable routing ofpackets between them. The second scenario shows building flows bySDN controller in different switches to enable routing of packets be-tween none directly-connected nodes. The third scenario shows rout-ing between two nodes in different subnets. The fourth scenario showsrouting between nodes with a completely isolated SDN controller.

With SDN routing within IoT Robotics networks for precisionfarming, a global routing algorithm will be achieved as well as moremanageable routing. This will result in farmers opting for more IoTdevices as a result of lower equipment cost.

III


Contents

1 Introduction 21.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1.1 Lack of global view of the network . . . . . . . 71.1.2 Global routing solution . . . . . . . . . . . . . 71.1.3 Energy need of nodes . . . . . . . . . . . . . . 81.1.4 Resource need of nodes . . . . . . . . . . . . . 81.1.5 Development cycle of protocols . . . . . . . . . 8

1.2 State of the art . . . . . . . . . . . . . . . . . . . . . . 81.2.1 Challenges of routing in IoT Robotics Networks 81.2.2 Solutions of routing issues in IoT Robotics net-

works . . . . . . . . . . . . . . . . . . . . . . . 101.2.3 State of the art conclusions . . . . . . . . . . . 12

1.3 Organization of the thesis . . . . . . . . . . . . . . . . 13

2 SDN routing within IoT Robotics for precision farm-ing 152.1 SDN architecture . . . . . . . . . . . . . . . . . . . . . 18

2.1.1 Components of SDN architecture . . . . . . . . 182.1.2 SDN data plane components . . . . . . . . . . 192.1.3 SDN controller plane components . . . . . . . . 192.1.4 SDN application plane components . . . . . . . 22

2.2 Client and server relationship in SDN . . . . . . . . . 222.3 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.1 OpenFlow Switch . . . . . . . . . . . . . . . . . 232.3.2 OpenFlow Switch (OF-switch)protocol . . . . . 242.3.3 OpenFlow Management and Configuration pro-

tocol (OF-Config) . . . . . . . . . . . . . . . . 242.4 Benefits of SDN routing within IoT Robotics . . . . . 24

3 Environment setup for simulation 283.1 Local machine . . . . . . . . . . . . . . . . . . . . . . . 283.2 Virtualization system . . . . . . . . . . . . . . . . . . . 28

3.2.1 Setting up VirtualBox for network connections 303.3 Mininet/Ubuntu Virtual Machine (VM) . . . . . . . . 33

3.3.1 Setting up Mininet/ubuntu VM for network con-nection . . . . . . . . . . . . . . . . . . . . . . 35

3.3.2 Setting up Mininet/ubuntu VM for SSH . . . . 393.3.3 Setting up XTerm (X11) forwarding . . . . . . 403.3.4 MiniEdit . . . . . . . . . . . . . . . . . . . . . 43

IV


3.4 Ubuntu 16.04 Virtual Machine (VM) . . . . . . . . . . 443.4.1 Creating Ubuntu 16.04 VM . . . . . . . . . . . 443.4.2 Installation of Ubuntu 16.04 ISO file in VM . 503.4.3 Setup Shared Folder on Ubuntu 16.04 VM . . . 513.4.4 Setting up Ubuntu 16.04 VM for Network . . . 553.4.5 Accessing POX controller in Ubuntu 16.4 VM . 58

4 Demo of SDN routing within IoT Robotics Network 664.1 Simulation setup . . . . . . . . . . . . . . . . . . . . . 664.2 Scenario 1: Routing between directly-connected nodes

within the same subnet . . . . . . . . . . . . . . . . . 704.3 Scenario 2: Routing between none directly-connected

nodes within the same subnet . . . . . . . . . . . . . . 774.4 Scenario 3: Routing between none directly-connected

nodes in different subnets . . . . . . . . . . . . . . . . 864.5 Scenario 4: Routing between nodes with a completely

isolated SDN controller . . . . . . . . . . . . . . . . . 89

5 Conclusions and future works 92

6 References 95

V


List of Figures

1 Top 25 funding Agencies for Precision Farming from2007 to 2017, Source: [4]. . . . . . . . . . . . . . . . . 3

2 Publication Years in precision farming 2007 to 2017,Source: [4]. . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Publication by Country/Region 2007 to 2017, Source:[4]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Number of patents publish per year from 2007 to 2017in precision farming, Source: [5]. . . . . . . . . . . . . 5

5 Number of patent per Country/Region from 2007 to2017 in precision farming, Source: [5]. . . . . . . . . . 5

6 Controller and data planes in IoT nodes . . . . . . . . 97 Separation of controller and data planes in SDN . . . 158 Publications in SDN related technologies from 2008 to

2017, Source: [4]. . . . . . . . . . . . . . . . . . . . . . 169 Top 25 by number of publication of SDN technologies

by institutions from 2008 to 2017, Source: [4]. . . . . . 1710 Number of SDN related patents granted from 2008 to

2017, Source: [5]. . . . . . . . . . . . . . . . . . . . . . 1711 Basc SDN Architecture . . . . . . . . . . . . . . . . . 1812 SDN Data Plane detail view . . . . . . . . . . . . . . . 1913 SDN Controller Plane detail view . . . . . . . . . . . . 2014 Client-Server function in SDN architecture . . . . . . . 2215 SDN enabled nodes in IoT Robotics . . . . . . . . . . 2516 VirtualBox downloads for Linux host . . . . . . . . . 2917 VirtualBox window after a successful instillation . . . 3018 VirtualBox network setup window1 . . . . . . . . . . 3019 VirtualBox IPv4 address adapter setup window . . . 3120 VirtuelBox host-only network DHCP setup window . 3221 Confirmation of host-only network setup on the host

computer . . . . . . . . . . . . . . . . . . . . . . . . . 3222 Mininet/ubuntu pre-package virtual machine downloads

3323 Mininet/ubuntu VM creation window . . . . . . . . . 3424 Hard disk file and mininet downloaded file selection . 3525 Default adapter setting of Mininet/ubuntu VM . . . . 3626 Mininet VM network setting window . . . . . . . . . . 3627 Setting up Adapter 2 for host-only network . . . . . . 3728 Setting up and confirmation of DHCP on eth1 . . . . 38

VI


29 Ping results of host machine and Mininet VM . . . . . 3930 SSH session between host machine and Mininet VM . 4031 Default SSH config file . . . . . . . . . . . . . . . . . . 4132 Modified SSH config file . . . . . . . . . . . . . . . . . 4233 Xterm sesion . . . . . . . . . . . . . . . . . . . . . . . 4334 MiniEdit window . . . . . . . . . . . . . . . . . . . . . 4435 Virtual Machine creation . . . . . . . . . . . . . . . . 4536 VM creation Memory size window . . . . . . . . . . . 4537 VM creation Hard disk specification window . . . . . . 4638 VM creation Hards disk file type window . . . . . . . 4739 VM creation, storage on physical hard disk window . . 4840 VM setup, File location and size window . . . . . . . . 4941 Ubuntu VM in VirtualBox manager . . . . . . . . . . 4942 Ubuntu 16.04 ISO file instillation, Select start-up disk

window . . . . . . . . . . . . . . . . . . . . . . . . . . 5043 Ubuntu 16.04 VM login window . . . . . . . . . . . . . 5144 Guest Addition window . . . . . . . . . . . . . . . . . 5245 Sheared folder setting window of Ubuntu VM . . . . . 5346 Ubuntu VM edit share window . . . . . . . . . . . . . 5347 Sheared folder window of Ubuntu VM . . . . . . . . . 5448 Appearance of the sheared folder in ubuntu VM . . . 5549 ubuntu VM default network setting . . . . . . . . . . . 5550 Default address assignment on Ubuntu VM . . . . . . 5651 Setting Adapter 1 as host-only network . . . . . . . . 5752 New IPv4 address of Adapter 1 after setup of host-only

network . . . . . . . . . . . . . . . . . . . . . . . . . . 5853 Starting POX controller in Ubuntu VM . . . . . . . . 5954 Topology of 4 switches, 8 hosts, and 1 controller in

MiniEdit . . . . . . . . . . . . . . . . . . . . . . . . . . 6155 Enabling CLI in MiniEdit . . . . . . . . . . . . . . . . 6256 MiniEdit Controller setup . . . . . . . . . . . . . . . . 6357 Output of connected switches to controller in POX . . 6458 Topology of demo of SDN routing within IoT Robotics

Network . . . . . . . . . . . . . . . . . . . . . . . . . . 6759 POX Controller started in Ubuntu VM . . . . . . . . . 6860 POX Controller connecting to Switches . . . . . . . . 6861 Connecting ports of the nodes . . . . . . . . . . . . . . 6962 Connectivity test before flows are created by the POX-

controller . . . . . . . . . . . . . . . . . . . . . . . . . 7063 Flow table build for routing between Node1h and Node4h 71

VII


64 Flow build in Node4s for routing packets from Node1hto Node4h . . . . . . . . . . . . . . . . . . . . . . . . . 72




68 Connectivity test between Node1h and Node4h . . . . 7669 Comparing connectivity tests between Node1h and Node4h 7770 flow entries build by POXcontroller for exchange of

packets between Node2h and Node4h . . . . . . . . . . 7871 Flow build in Node4s for routing packets from Node2h

to Node4h . . . . . . . . . . . . . . . . . . . . . . . . . 7972 Flow build in Node4s for routing packets from Node4h

to Node2h . . . . . . . . . . . . . . . . . . . . . . . . . 8073 Flow build in Node1s switch for routing packets from

Node2h to Node4h . . . . . . . . . . . . . . . . . . . . 8174 Flow build in Node1s switch for routing packets from



Node4h to Node2h . . . . . . . . . . . . . . . . . . . . 8477 Connectivity test between Node2h and Node4h . . . . 8578 Comparison of connectivity tests between Node2h and

Node4h . . . . . . . . . . . . . . . . . . . . . . . . . . 8679 Connectivity tests between Node1h and Server . . . . 8780 ARP request from Node1h . . . . . . . . . . . . . . . . 8881 ARP reply from POXcontroller . . . . . . . . . . . . . 8982 Repeated test on Scenario 1, 2 and 3 with isolated POX-

controller . . . . . . . . . . . . . . . . . . . . . . . . . 90

VIII


List of Tables

1 Some components bundled with POX . . . . . . . . . 602 Interfaces, IP addresses, and MAC addresses used on

the hosts . . . . . . . . . . . . . . . . . . . . . . . . . . 69

IX


List of Abbreviations

6LoWPAN : IPv6 over Low-Power Wireless Personal Area NetworksA-CPI : Application-Controller Plane InterfaceAfarCloud : Aggregate Farming in the CloudAODV : Ad hoc On Demand Distance VectorARP : Address Resolution ProtocolAUV : Autonomous Underwater VehicleCC : Client ContextCLI : Command Line InterfaceCS : Client SupportD-CPI : Data-controller plane interfaceDHCP : Dynamic Host Configuration ProtocolDSR : Dynamic Source RoutingGPS : Global Positioning SystemGUI : Graphical User InterfaceIETF: Internet Engineering Task ForceIoT : Internet of ThingsIPv4 : Internet Protocol version 4IS-IS : Intermediate system to Intermediate SystemISO : International Organization for StandardsLLN : Low power and Lossy NetworksNBI : Northbound InterfaceOLSR : Optimized Link State RoutingONF : Open Networking FoundationOSPF : Open Shortest Path FirstOVSDB : Open vSwitch DatabasePCT : Patent Cooperation TreatyPTC : Probabilistic Topology ControlRDB : Resource Data BaseRG : Resource GroupsROLL : Routing Over Low-power and Lossy networksRPL : Routing Protocol for Low Power and Lossy NetworksRTT : Round Trip TimeSBI : Southbound InterfaceSC : Server ContextSDN: Software Defined NetworkingSSH : Secure Shell HeaderUASN: Underwater Acoustic Sensor NetworksVM : Virtual Machine

X


WSN: Wireless Sensor NetworkX11 : X window system

XI


1 Introduction

1


1 Introduction

With the increasing world population and the increase in rural-urbanmigration of the youthful population, a great decrease in manpower isexperienced in the agricultural sectors. D. Guo et al. indicated thatthere are several possibilities of the change of the world populationin the future and they predict the world population to rise, peak in2020 and then decline [1]. According to one of the Multiple SigmoidFunctions (MSF) models of Y. Zhang et al. the potential saturationvalue of the world population is approximately 9.6 billion [2]. UnitedNations’s (UN’s) world population prospects 2017 review indicatedthe world population is expected to reach 8.6 billion in 2030 and theupward trend in population size is expected to continue with roughly83 million people being added to the world’s population every year[3].

With these decrease in manpower in agricultural sectors and theincrease in world population, the demand for agricultural productsis raising. This alarming situation needs a more cost-effective andmodern agriculture to address the situation. This alarming situationin agriculture has been partly addressed with the use of precisionfarming. Precision farming is everything that makes the growing ofcrops and raising of livestock more manageable and producing morefood using fewer resources and at reduce production cost.

Research and development in precision farming is a great concernto both governments and regional institutions. Technology watch con-ducted in this thesis in the area of precision farming from the year 2007to 2017 indicates that regional institutions, countries, ministries, uni-versities and associations are taking part in funding precision farming-related projects.

According to the standard UNE 166006:2011, technology watchis define as, “Organized, selective and systematic process to captureinformation from outside and from the organization itself on scienceand technology, to select, analyze, diffuse and communicate it, in orderto convert information in useful knowledge to make decisions with lessrisk and to be able to anticipate relevant changes”.

Figure 1 shows the number of funding made by different institu-tions between 2007 and 2017 in the area of precision farming.

2


Figure 1: Top 25 funding Agencies for Precision Farming from 2007 to 2017,Source: [4].

A lot of publications has been made in the area of precision farm-ing. The result of technology watch made in this thesis shows thatthere is a steady increase in the number of publications made in preci-sion farming between 2007 and 2017. Figure 2 shows that the numberof publications in the area of precision farming increases every year(2017 record 299, 2016 record 247, 2015 record 208). In 2014 therewas a drop in the number of publications 166 compare to 195 recordsin 2013.

3


Figure 2: Publication Years in precision farming 2007 to 2017, Source: [4].

Figure 3 shows the top 25 publications by country and region. TheUSA made the highest publication 381 followed by China 265 and thenGermany 188. The interesting thing to note here is that, if the numberof publications made by the different European countries is sum up,they will score the higher record of publications for example Germanyrecord 188, Italy record 134, Spain record 92 plus the others as shownin Figure 3.

Figure 3: Publication by Country/Region 2007 to 2017, Source: [4].

4


The technology watch of patents in the area of precision farm-ing conducted in this thesis indicates that there is an increase in thenumber of patent applications per year as shown in Figure 4.

Figure 4: Number of patents publish per year from 2007 to 2017 in precisionfarming, Source: [5].

The technology watch also indicates that, United States publishmore patients 236 followed by Patent Cooperation Treaty (PCT) 109then Australia 47 and European Patent Office 33 as shown in Figure5.

Figure 5: Number of patent per Country/Region from 2007 to 2017 in precisionfarming, Source: [5].

The technology watch on precision farming conducted in this the-sis reveals to what extent different institutions, countries and regionsare contributing towards the development of precision farming to in-crease agricultural products at limited cost and with less manpower.The technology watch also identifies possible technology partners andfunding options for research and development in precision farming.

Different technologies have been used to enhance precision farm-ing such as the Internet of Things (IoT) technologies and the use of

5


farming robots. Different precision farming projects such as the Afar-Cloud (Aggregate Farming in the Cloud) project have been sponsoredto come up with a distributed platform for autonomous farming thataims to integrate agricultural Cyber-Physical Systems (CPS) in real-time and provide lower equipment cost for farmers. To achieve this,the resources used must connect to each other and route informationbetween each other. The resources used in precision farming can befarming robots. The robots exchange information using routing pro-tocols. Routing protocols define the rules how information is transfer.For the robots in precision farming to communicate to each other re-liably and more effectively, there must be a reliable, simple, and amanageable routing protocol in place.

Different routing protocols have been developed for IoT Roboticnetworks. According to the review made in this thesis on the currentrouting protocols for IoT Robotics networks, routing protocols arechosen according to the network scenarios. There is no one routingprotocol that addresses a global problem [6],[7],[8],[9]. The routingalgorithms are run in the nodes (robots) themselves making themfunction as routers. The running of routing algorithms in the nodesincreases the energy and resource needs of the nodes. With the above-mentioned issues of the current routing protocols for IoT roboticsnetworks, there is a need for developing a routing protocol for IoTRobotics networks that will solve global issues and will greatly reducethe energy and resource need of the nodes. The nodes are expectedto function in isolation therefore they will need enough energy andresources to sustain themselves in isolation. Thus, a routing protocolthat will require less energy and resource from the nodes is needed.

The focus of this thesis is to enhance routing in IoT Robotics net-works for precision farming using Software Defined Networking (SDN)technologies. Software Defined Networking is a growing area of re-search. All the big players in networking are closely monitoring itsevolution and setting up plans for the big change. The use of SDNrouting within IoT Robotics networks can solve global routing prob-lems in IoT Robotics networks. Because SDN technology separatesthe controller plane and the data plane, thus the nodes will be leftwith only the data plane reducing their energy and resource needswhich use to be caused by the running of routing algorithms in themin computing best routs. SDN routing within IoT Robotics can enablethe nodes to function for a longer period while in isolation because ofreduction in their functional load.

6


Review of current routing protocols for IoT Robotics networks hasbeen made in this thesis. The architecture of SDN has been discussedas well as protocols for SDN. Environment setup for the demo hasbeen made using a local machine, a virtualization system, Mininet,MiniEdit, POX controller, Wireshark. Demonstration of four scenar-ios has been successfully conducted. The results of the scenarios proofthe concept of SDN routing within IoT Robotics networks discussedin this thesis.

1.1 Motivation

The objective of the AfarCloud project is to develop vehicle-mountedsensors and actuators that are able to monitor samples and actuateover different plants and animals without a static deployment of sen-sors and the provision of increased efficiency and reduced farm laborcosts. This objective cannot be achieved without a simple, reliable,and manageable routing between the nodes of the IoT Robotics net-work. To achieve simple, reliable, and manageable routing betweennodes of IoT Robotics networks routing protocols use need to: (1)have the global view of the network, (2) solve global problems, (3)have less energy demand, (4) demand fewer resources, and (5) haveshort development cycle.

1.1.1 Lack of global view of the network

Having the global view of a network at a point is necessary for anyrouting protocol to effectively and quickly make any routing decision.This will enable a routing protocol to quickly learn all possible routesto a destination and choose the best route. In case of a broken linkthe next best route can easily and quickly be learned.

1.1.2 Global routing solution

Almost all the current routing protocols address specific problems,and the majority of them are proprietary protocols. There is a needfor a global routing protocol to address all routing issues at once. Thiswill enable fast and simple management of routing within IoT Roboticnetwork since there will be no requirement for specific configurationfor different proprietary protocols.

7


1.1.3 Energy need of nodes

As IoT nodes are expected to route packets between each other inisolation, they need enough energy to function while in an isolatedenvironment. Thus, the nods need routing protocol that will not re-quire extra energy for the computation of routes. This is one of thedrawbacks of the current routing protocols for IoT Robotic networks.

1.1.4 Resource need of nodes

IoT nodes need resources to store the codes and algorithms that con-trol its functionality. It as well needs resources to store data collectedfrom the environment. It is therefore necessary for the IoT nodes torun routing protocols that will not cause resource contention.

1.1.5 Development cycle of protocols

As technology continues to develop faster than expected, companiesand enterprises continuously come up with new business ideas tosatisfy the needs of their customers. Due to the long developmentcycle of most protocols especially the proprietary protocols, adjust-ments needed to meet business demands are not immediately avail-able. There is a need for routing protocol that will allow immediatesolutions to business needs.

1.2 State of the art

One of the key factors for achieving the goals of the AfarCloud projectis to have a simple, manageable and reliable routing algorithm inplace that will speed up the process of reliable information transferwithin the network. SDN routing within IoT Robotics is proposed inthis paper for the AfarCloud project. With SDN routing, nodes canreliably and efficiently route packets between each other in an isolatedenvironment with fewer energy needs and no resource constraints.

1.2.1 Challenges of routing in IoT Robotics Networks

Due to high mobility of nodes in IoT Robotics networks topologychanges frequently and as a result, routing is difficult. The findingsin the survey of routing protocols use in IoT Robotics networks showsthat a unified standard for IoT routing protocol is yet to be available,thus every routing protocol addresses a specific issue.

8


Challenges of routing in IoT Robotics networks includes energyneeds and resources constraints. The nodes function as both host androuters for making routing decisions on their own. This makes themneed additional energy and resources for the routing function. Thefocus of this paper is the enhancement of routing in IoT Roboticsnetworks by reducing the energy and resource need of the nodes.

When designing routing protocols for IoT Robotics, challengessuch as energy needs and resources constraints need to be considered.One of the main factors for the energy need and resources constraintsof the nodes in IoT Robotics is due to the fact that, both the controllerplane and data plane of the routing function are housed within thesame node as shown in Figure 6.

Figure 6: Controller and data planes in IoT nodes

Figure 6 shows how the routing function is built in the nodes of IoTrobotics network. The controller plane is where the routing algorithmsare run and the routing decisions made. The data plane does theforwarding of information based on the algorithm in the controllerplane. The combination of these two planes housed within the same

9


node posed a high energy and resource need on the nodes.

1.2.2 Solutions of routing issues in IoT Robotics net-works

Different routing protocols exist for solving different routing issues inIoT Robotics networks. Current routing protocols are used accordingto the network scenario. Results in [6] shows that, when comparingAd hoc On Demand Distance Vector (AODV) and AODVDR, AODVgives better performance that AODVDR when a possible number ofthe network connection from each node is less than 25 % of the totalnode in the network. If the total number of network connection isgreater than 40 % of the total nodes in the network, AODVDR givesbetter performance.

Optimized Link State Routing (OLSR) have been suggested in[7] for compacting the size of packets and reducing the number ofretransmissions that causes flooding in the entire networks. OLSR isbest suited for large and dense ad hoc networks.

In the evaluation of reactive routing protocols (Dynamic SourceRouting (DSR) and AODV) and proactive routing protocol (OLSR)in 802.11 ad-hoc network environment, C.S.R Putta et al. made thefollowing conclusions in [8]: Proactive routing protocol, OLSR pro-vides better performance for voice service. Reactive routing protocols(DSR and AODV) are considered more adaptive for data service.

In their work in [9], H. Xin and K. Yang studied the mechanismsof AODV, DSR, and OLSR routing protocols which are used in AdHoc network, and analyzed their usage in IoT network.The result oftheir findings shows that the protocol overhead of the three protocolsincreases with the number of nodes with AODV having the highestoverhead followed by OLSR. This concludes that, if energy saving is tobe used as the key point, DSR should be adapted. Also according totheir findings, in terms of delay OLSR has the lowest delay followed byDSR. This indicates that if rapid communication is to be establishedOLSR mechanism should be used. In terms of network throughput,their results show that AODV performs better followed by OLSR. Thisindicates that AODV should be adapted if communication quality isa priority.

According to [10], ROLL (Routing Over Low-power and Lossy net-works (LLN)) working group have performed analyses on routing pro-tocols such as Intermediate System to Intermediate System (IS-IS),

10


Open Shortest Path First (OSPF), AODV, and OLSR, and concludethat they failed in satisfying the requirements of LLNs. Each protocolhave their own limitations

In their survey, L. Ning et al. in [11] divide the routing pro-tocols of Underwater Acoustic Sensor Networks (UASNs) into twodifferent kinds cross-layer design routing and non cross-layer designrouting and analyze their performance. They concluded that cross-layer design routing has become more important and common in re-cent years. Two kinds of cross-layer design methods introduced arelocation information-free routing protocols and location information-based routing protocols. The conclusion in [11] shows that locationinformation-free routing protocols are blind in routing discovery be-cause of the absence of location information. For location information-based routing protocols, their conclusion was that it can be energyintensive when using underwater GPS or location algorithm, and canwaste a large number of node resources.

The Smart and Networking Underwater Robots in CooperationMeshes (SWARMs) project uses underwater wireless sensor network(WSN) solutions to enable routing of information between nodes.AProbabilistic Topology Control (PTC) algorithm is proposed in [12] forautonomous underwater vehicle (AUV) network for SWARMs project.In PTC when the transmission power of a node is not equal to theoptimal transmission power, the node’s parameters will determine ifthe transmission power needs to be adjusted or not. The results [12]concludes that PTC reduces the transmission power adjustment ratio.

Due to the difference between terrestrial environment and under-water environment, WSN solutions for terrestrial environments willneed some adjustments before their use in underwater environments[11].

Two IETF standards which IP connectivity in sensor networks de-pends on are IPv6 over Low-Power Wireless Personal Area Network(6LoWPAN) and Routing Protocol for Low Power and Lossy Networks(RPL). 6LoWPAN does not satisfy Low power Lossy networks. RPL isIETF’s IPv6 routing protocol for low power lossy networks. RPL ad-dresses single path routing with minimum computational complexityand resource utilization. But in a high congested network situation,it reduces the achievable output of the network [10].

These findings show that a unified standard for IoT routing pro-tocol is yet to be available, thus every routing protocol addresses aspecific issue.

11


The goal of this paper is to come up with proposals for enhancingrouting in the AfarCloud (Aggregate Farming in the Cloud) project.AfarCloud is a precision farming project that aims to provide a dis-tributed platform for autonomous farming that aims to integrate agri-cultural Cyber-Physical Systems (CPS) in real-time. The goal of theAfarCloaud project includes making farming robots accessible to morefarmers by enabling them to work in cooperative mesh and ensuringreusability. The objective is to develop vehicle-mounted sensors andactuators that are able to monitor samples and acuate over differentplants and animals without a static deployment of sensors. The goalalso includes the provision of increased efficiency and reduced farmlabor costs.

One of the key factors for achieving these goals for the AfarCloudproject is to have a simple, manageable and reliable routing algorithmin place that will speed up the process of reliable information transferwithin the network.

1.2.3 State of the art conclusions

The review above concludes that every routing protocol is used fora particular purpose. Thus, currently there is no routing protocolthat addresses all problems. This call for the need of developing arouting protocol that will address multiple issues. In IoT Robotics,nodes serve as both host and router. This makes the nodes to needmore energy and resources to carry out tasks. These are some of thebiggest concerns in IoT Robotics networks since nodes are expected tofunction in an isolated environment where they will need to functionunder the energy and resources available in them.

This paper has proposed the use of SDN routing within IoT roboticsto eliminate the high energy need and resource constraints due to thehousing of both the controller and data planes within the same node.According to their analyses of routing in aeronautical ad hoc networks,M. Kardoust et al. in [13] mentioned in their future work that, the in-tegration of SDN technologies will enable high efficient routing. WithSDN routing, all the controller planes of the nodes are moved to acentral controller which serve as the gateway to the cloud or the In-ternet. The nodes are left with only the data plane. This architecturewill greatly improve both the energy and resource need of the nodes.

12


1.3 Organization of the thesis

The rest of this thesis is organized as follows.Chapter 2: This chapter discusses SDN routing within IoT Robotics

for precision farming. SDN architecture and the functions of compo-nents of SDN architecture have been discussed. The benefits of DSNrouting within IoT Robotics is also discussed.

Chapter 3: Description and the process of environment setup forthe demonstration of SDN routing within IoT Robotics networks forprecision farming have been described in this chapter. The processof setting up virtualization systems, Mininet, and Ubuntu VirtualMachine (VM) is described in this chapter as well.

Chapter 4: Demonstration of SDN routing within IoT Roboticnetworks have been performed in this chapter. Four scenarios havebeen demonstrated using one Ubuntu local machine, VirtualBox, MininetVM, one Ubuntu VM, and Wireshark.

Chapter 5: Chapter 5 is the conclusions of this thesis. Areasfor possible future research are as well discuss in this chapter whichincludes the future works derived as a result of the findings in thisthesis.

The next chapter discusses SDN architecture and SDN routingwithin IoT Robotics. It as well discusses some benefits of using SDNrouting within IoT Robotics.

13


2 SDN routing within IoTRobotics for precision

farming

14


2 SDN routing within IoT Robotics

for precision farming

Work on SDN started in 2008 when the OpenFlow protocol was pub-lished. This enables the separation of control plane and data planeand allows flexible programming how the hardware handles data traf-fic.Figure 7 shows the traditional network architecture and how thecontroller plane and data plane are separated in SDN.

(a) Traditional Networking (b) Software Defined Networking

Figure 7: Separation of controller and data planes in SDN

Open networking foundation (ONF) architecture working groupdeveloped the SDN architecture to support standardizations related toSDN. ONF was found in 2011 and published the first detailed SDN ar-chitecture in June 2014 and the updated SDN architecture in February2016 [14], [15]. As the opportunities for added values of SDN becomesclear, the focus shifted from flexible packet forwarding to dynamic re-source virtualization and service orchestration [16],[17],[18],[19]. Issuesaddressed by SDN technologies include problems of traffic engineer-ing (TE), quality of service (QoS) provisioning and failure recovery ininternet service provider (ISP) networks [20].

Security threats faced by SDN and conventional networks are com-parable under the same threat model if they are to provide the samenetwork properties. Important for SDN controller plane security isthe support of fault tolerance and consistency checks. Filtering inthe edge is effective in conventional networks [21]. In their work that

15


aims to enhance the entire security of developed SDN environment, I.Abdulqadder et al. Proposed a multi-level security mechanism. Firstrouters verify users, secondly, policies are verified, thirdly controllersare authenticated before assigning flow packets [22]. The focus of thispaper is flexible packet forwarding provided by SDN technologies.

Technology watch conducted in this thesis for scientific and tech-nological publications in SDN related technologies from 2008 to 2017shows a great increase in the number of publications done startingfrom 2015 as shown in Figure 8.

Figure 8: Publications in SDN related technologies from 2008 to 2017, Source:[4].

The participation of big tech companies such as Huawei, Ericsson,Nokia, NEC in the publication of SDN related technologies as shownin Figure 9 is a strong indication to the rising of SDN technologies.

16


Figure 9: Top 25 by number of publication of SDN technologies by institutionsfrom 2008 to 2017, Source: [4].

In a similar vein, the number of patents granted to high tech com-panies in the area of SDN technologies is another signal of the road tothe big revolution. Figure 10 shows the number of patents granted tohigh tech companies such as Huawei, Ericsson, Hp, H3C, ZTE from2008 to 2017.

Figure 10: Number of SDN related patents granted from 2008 to 2017, Source:[5].

The result of the technology watch of SDN related technologiesconducted in this thesis shows that SDN is the future technology andall the big players in high tech industries are preparing for the bigchange.

17


2.1 SDN architecture

A basic SDN architecture is shown in Figure 11 . The architectureconsists of three plains, data plane, controller plane, and applicationplane. These planes are also referred to as infrastructure layer, controllayer, and application layer respectively [14] [23].

Figure 11: Basc SDN Architecture

Applications and clients in the application plane communicatetheir network requirements to the controller plane via Application-Controller Plane Interface (A-CPI). Controller plane invokes the ser-vices of the data plane via Data-controller plane interface (D-CPI).The data controller plane interface is also referred to as southboundinterface (SBI), and the application-controller plane interface is alsoreferred to as northbound interface (NBI).

2.1.1 Components of SDN architecture

In this subsection, we will talk about some functions and activities thatare carried out in each of the planes of SDN architecture mentionedin Figure 11. The functions and activities in each of the planes will be

18


explained by defining the function of components that can be presentin the planes.

2.1.2 SDN data plane components

Forwarding decisions made in the controller plane are implemented inthe data plane. The data plane house one or more resource groups(RG). Each resource group is managed as a single entity. The resourcegroups in the data plane deal directly with the traffic of customers andprovide connectivity to end devices.

Figure 12 . Shows a detailed view of the data plane. The compo-nents found in each resource group includes resource data base (RDB),and resources (R).The RDB in the resource group is responsible forstoring resources specific to the resource group.

Figure 12: SDN Data Plane detail view

2.1.3 SDN controller plane components

Control in SDN is logically centralized with no resource contention be-tween entities. SDN controller typically has more than one RGs in itssubnetwork scope and regard itself the owner of the virtual resourcesallocated to it. SDN controller administers resources that are sharedby more than one client or application making sure that the commit-ments made to the clients or applications are fulfilled while isolatingeach client or application from the others. It continuously updates

19


network and service state towards a policy-based optimum configura-tion. Components within SDN controller plane includes client context(CC), server context (SC), and resource data base (RDB) as shownin the detailed architectural view of SDN controller plane in Figure 13.

Figure 13: SDN Controller Plane detail view

Orchestration and virtualization are important processes that arecarried out in the SDN controller plane. The orchestration is theprocess of ongoing selection of resources by a server to satisfy thedemand of a client.Virtualization is the process used to allocate virtualresources to the clients through the process of the mapping function.

Client Context (CC)

Client context is the conceptual component of a server that representsall the information of a client. It participates in the server-clientmanagement-control operation. The relationship between client andserver reciprocally is that client is configured with server context andservers are configured with client context. Each client or applicationhas all it needs to be supported in its own client context in the SDNcontroller server role. The client context of a client or application isdeleted from the SDN controller if it has no more relationship with

20


it. Client context of new clients or applications is created by theadministrator with at least mandatory parameters to enable client-server session. The administrator can populate the client resourceswith virtual resources. Components in the client context include oneresource group (RG), and a client support (CS).

Resource group (RG): A-CPI exposed to the client or appli-cation is defined by the resource group. As shown in Figure 13, theresource group consist of two sub-groups, virtual resource group, andsupport resource group. Virtual resource group represents infrastruc-ture resources that are created through virtualization from SDN con-trollers’ underlying resources and are exposed to the client by way ofthe mapping function. Support resource group represents functionshosted in the SDN controller itself, example login profile, logs, andnotification subscriptions. The resource group of each client contextcan have multiple user logins. These login details are controlled bythe client. The administrator login is the first created during the cre-ation of the client context. This administrator login has unlimitedprivilege within the resource group of the client. The administratorthen creates sub-contexts for other user logins.

Client support (CS): Client support block may contain addi-tional resources like code, ephemeral data, and persistent data thatare not exposed to the client at all.

Server Context (SC)

Server context is the conceptual component of a client that representsall information about a given server and is responsible for participatingin the active server-client operation. Server context is in the SDNcontroller client role. SDN controller must contain a server context foreach resource group to which it may connect to the data plane. Thisserver context includes the association attributes, login, and securityinformation that will be acceptable to the underlying resource groupenvironment. The view provided by the underlying resource group isavailable to the SDN controller’s server context.

Resource data base (RDB)

RDB of the controller plane is the repository of all information thatneeds to be retained in the SDN controller. Data in the resource database can still be access after controller reinitialization or replacement.

21


2.1.4 SDN application plane components

Application plane consists of service consumers. Service consumercan be a client, user, or customer who exchanges both data andmanagement-control operation with some SDN server or provider.The scope of this paper is limited to controller and data planes.

Management and control are viewed as a continuum. Adminis-trator role differs from that of ordinary applications only by havinggreater scope and privilege. The administrator configures the SDNcontroller itself along with client and server contexts and updates themfrom time to time as needed. The administrator configures a clientcontext for each of its clients which includes allocation of underlyingresources to the client in the process call virtualization. The admin-istrator configures each client with a policy that defines the actionand bounds permitted to the client and may modify the client con-text during its lifetime and may destroy a client context if the clientrelationship terminates.

2.2 Client and server relationship in SDN

SDN functions as a set of client-server relationships between SDN con-troller and other entities. The key and central component of SDN isthe SDN controller. Figure 14 shows client-server operation in SDNarchitecture. As a server, SDN controller offer services to service con-sumers at the application plane. SDN controller satisfies client requestby virtualizing and orchestrating underlying resources.

Figure 14: Client-Server function in SDN architecture

22


As a client, SDN controller invokes services from servers in thedata plane. SDN controller exposes services and resources to clientsvia A-CPIs and receives services and resources from the data planevia D-CPIs.

There are two perspectives on the nature of client-server inter-faces. One, service-perspective, which is viewed from the top-downor customer-provider viewpoint. Two, resource-perspective, which isviewed from the bottom-up viewed point of the resource owner. Theperspectives emphasize different things but are complementary.

2.3 OpenFlow

OpenFlow is a key enabler for SDN and the first standard definedbetween controller plane and data plane. OpenFlow allows accessto the data plane devices from the controller plane for manipulationand reshaping of forwarding decision [24],[25]. OpenFlow allows thenetwork to be program on per-flow base providing a granular con-trol that enables networks to respond to real-time changes. Currentrouting protocols do not provide this level of control.

2.3.1 OpenFlow Switch

OpenFlow switches communicate with SDN Controller via OpenFlowSwitch protocol. OpenFlow switch consists of one or more flow ta-bles, group table, one or more OpenFlow channel, OpenFlow ports.Each flow table consists of flow entries. Flow entries consist of matchfields, counters, and instructions to apply to matching packets. In-structions associated with each flow entry either contain actions ormodify pipeline processing.

The two types of OpenFlow compliant switches are OpenFlow-onlyand OpenFlow-hybrid. OpenFlow-only switch support only OpenFlowoperations. OpenFlow-hybrid switch support both OpenFlow opera-tions and normal switch operations [24].

When the controller is isolated, OpenFlow switches immediatelyenters into a fail secure mode or fail standby mode. In the fail securemode, packets and messages destined to the controller are dropped.Flow entries continue to exist according to their timeouts. Fail stan-dalone mode is only available on the Hybrid switch. In the fail stan-dalone mode, the OpenFlow switch behaves like a normal legacy Eth-ernet switch or router. The switch uses the flow table anyhow it

23


wishes. It can modify, add, or delete flow entries. If the controllerreinitializes it synchronizes with the flow table by maintain the flowentries or delete them and building new ones.When an OpenFlow switch starts up for the first time, it operates ineither fail secure mode or in fail standalone mode.

2.3.2 OpenFlow Switch (OF-switch)protocol

Controller-to-switch messages are initiated by the controller to directlymanage and inspect the state of the switch using OpenFlow protocol.These messages may or may not require response from the switch.With the OpenFlow switch protocol, the controller can add, update,and delete flow entries in flow tables, both reactively (in response topackets) and proactively.

2.3.3 OpenFlow Management and Configuration proto-col (OF-Config)

OpenFlow Management and Configuration Protocol (OF-Config) isa companion protocol to OpenFlow. OF-Config enables remote con-figuration of OpenFlow Switches [26]. OF-Config defines OpenFlowswitch as an OpenFlow Logical Switch. The controller communicatesand controls the OpenFlow Logical switch via the OpenFlow protocol.

2.4 Benefits of SDN routing within IoT Robotics

To enhance the routing process of the AfArCloud project by reducingenergy need and resource constrains of the nodes, we proposed the useof SDN routing in this paper. To implement SDN routing within IoTrobotics, the SDN architecture discussed earlier will be implememtedas showh in Figure 15.

24


Figure 15: SDN enabled nodes in IoT Robotics

Figure 15 is a modification of Figure 6 using SDN architecture.Figure 6 shows the traditional routing architecture of IoT nodes. InFigure 15, all the controller planes of the nodes are moved to the cen-tral controller which serve as the gateway to the cloud or the Internet.The nodes are left with only the data plane.This architecture will greatly improve both the energy and resourceneed of the nodes. Some of the benefits of SDN networks are as shownbelow.

The requirements of today’s users, enterprises, or carriers werenot catered for in the current existing network architectures. Today’snetworks are relatively static due to complexity and the fact thatadministrators seeks to minimize service disruption as a result of thecomplexity of the network. Another limitations of today’s networksis due to the fact that most protocols are proprietory without any

25


fundamental abstraction, and each protocol solving a specific problem.Vendor’s equipment product cycle can range to three years or more

[23]. This can delay enterprises intending to deploy new capabilitiesand services leading to slow innovation. By allowing network operatorsand even users to program and reprogram the network in real time tomeet specific business needs as they arise, SDN adoption acceleratesinnovation.

Enterprises today operates converged networks for voice, data, andvideo traffic. Configuring converged networks today is highly manual,each vendor’s equipment must be configured separately. SDN con-troller can control any OpenFlow enabled network device from anyvendor. Administrators can use SDN orchestration and managementtools to deploy, configure, and update devices across networks. Thisreduces operational overheads and increases agility. This eliminatesthe need to individually configure network devices each time a newdevice is added or remove, or a change in policy is made.

With the addition of hundreds or thousands of network devicesthat must be configured, the network becomes more complex. Carriersmust deliver higher values and better differentiated services to staycompetitive. Due to the fact that SDN controllers provide a completevisibility and control over the network, configurations and policies areenforced consistently across the network [27]. The flow based controlmodel of SDN allows the application of policies at a very granularlevel.

Due to the separation of controller plane and data plane in thenetworking devices leaving the devices with only the data plane, anddue to the openness of the devices, SDN technology will encouragemore SDN equipment vendors. Thus, resulting to drop in price ofSDN equipments. This will encourage farmers to go for more SDNenabled IoT devices for enhancing their precision farming activities.

This chapter discussed SDN architecture and the function of thecomponents in each plane of the architecture. Client-server relation-ship and functions are discussed as well as OpenFlow protocols andOpenFlow switches. The benefits of SDN routing within IoT Roboticsnetworks are discussed too. The next chapter discusses how the en-vironment setup was done for the simulation of SDN routing withinIoT Robotics networks.

26


3 Environment setup forsimulation

27


3 Environment setup for simulation

The proof of concept was demonstrated in a lab environment using alocal machine, a Virtualization system, Mininet/ubuntu Virtual Ma-chine (VM), and Ubuntu 16.04 64bits Virtual Machine.

3.1 Local machine

The local machine used is Ubuntu 16.04 64bits computer. The Ubuntu16.04 local machine act as the host machine for the Mininet/UbuntuVM and Ubuntu 16.04 VM. The local machine is used to SSH intothe Mininet/ubuntu VM for configuration and management of theMininet. Thus, Mininet is a command line Interface (CLI) and isnot friendly to work with especially when trying to capture or printoutputs. The local machine is used to open the nodes in Xterm in thelocal machine for their management. The local machine is also usedto open Wireshark on the local machine. Wireshark is a tool used tomonitor traffic in the SDN network.

3.2 Virtualization system

The virtualization used is operating system virtualization. The virtu-alization allows the running of multiple instances of different operatingsystems on the local machine. VirtualBox is used as the virtualizationsystem. VirtualBox is free and can run on Windows, Linux, and OSX. The latest VirtualBox version at the time of downloading (Ver-sion 5.2.8) was downloaded at VirtualBox official site [38] as shown inFigure 16.

28


Figure 16: VirtualBox downloads for Linux host

Each instance of an operating system running on the virtualiza-tion system is called a virtual machine. Each of the VMs is termed as aguest machine. In our case, the guest machines are the Mininet/ubuntuVM and the ubuntu 16.04 64bits VM.During the downloading and installation of the VirtualBox, note hasbeen taken to make sure that the package architecture of the Virtu-alBox downloaded matched the Linux kernel architecture of the localmachine. In our case we are running 64bits kernel Ubuntu, therefore,AMD64 is the appropriate package to install.After a successful installation of the VirtualBox, it was opened and thewindows in Figure 17 shows. This indicates the successful completionof VirtualBox installation.

29


Figure 17: VirtualBox window after a successful instillation

3.2.1 Setting up VirtualBox for network connections

To connect a VM to the host computer or to other VMs, a host-onlyinterface needs to be created in the VirtualBox. This will enable thehost computer to run SSH sessions with the VMs.

From the “Global Tools” drop-down arrow key select “Host Net-work Manager”. A window in Figure 18 will appear. In the windowsthat appear in Figure 18, “vboxnet0” is the name of the host-onlyinterface, 192.168.56.1/24 is the default IPv4 address assigned to theadapter, and DHCP server is enabled by default.

Figure 18: VirtualBox network setup window1

Right-click on “vbnet0” in the windows that appears in Figure 18and chose “Properties” from the list that appears. Another windowwill appear under as shown in Figure 19.

30


Figure 19: VirtualBox IPv4 address adapter setup window

The “Adapter” tab shown in Figure 19 indicates the adapter set-ting which can be changed. The default adapter settings are main-tained for this lab. The “DHCP Server” tab shows the DHCP settingsas shown in Figure 20.

31


Figure 20: VirtuelBox host-only network DHCP setup window

DHCP settings can be changed in this window. The default DHCPsettings are used in this thesis. The host-only network settings of theVirtualBox can be confirmed by running “ifconfig” command on theCLI terminal window of the host computer as shown in Figure 21.

Figure 21: Confirmation of host-only network setup on the host computer

32


This concludes the setup of the host-only adapter on the Virtual-Box.

3.3 Mininet/Ubuntu Virtual Machine (VM)

Mininet is a network emulator that supports tasks that benefit fromhaving a complete experimental network on a local machine. Mininetcreates a network of virtual controllers, switches, hosts, and links.Mininet switches support OpenFlow for customized routing and SDN.Mininet hosts run Linux network software. Some of the main advan-tages of Mininet are: it provides a simple and inexpensive testbedfor developing OpenFlow applications, allows independent concurrentworks on the same topology, supports complex topology testing with-out the need to wire up a physical network.

In this experiment, a pre-packaged Mininet/ubuntu Virtual Ma-chine containing Mininet, OpenFlow binaries and Controllers is used.During the time of Mininet installation, the latest version of Mininet(version 2.2.2) on Ubuntu 14.04 LTS 64bits that came with two con-trollers (POX and Pyretic) was downloaded from Mininet official site[39] as shown in Figure 22 and imported into VirtualBox.

Figure 22: Mininet/ubuntu pre-package virtual machine downloads

33


To import the virtual machine into the VirtualBox, the VirtualBoxmanagement application was started. The “New” button on the menuclicked and then the “Create Virtual Machine” window appears. Infor-mation on “Create Virtual Machine” window in Figure 23 was enteredand selected. Then the “next” button was clicked.

Figure 23: Mininet/ubuntu VM creation window

After clicking the “Next” button again to select the default mem-ory size, the window in Figure 24 appears. “Use an existing virtualhard disk file” radio box selected. The folder icon clicked to browseto the downloaded unzipped Mininet file in the Downloads folder onthe local machine and select it.

34


Figure 24: Hard disk file and mininet downloaded file selection

The “Create” button was then clicked to proceed with the comple-tion of the importation of the Mininet into the VirtualBox manager.After few moments the Mininet appears in the VirtualBox managerwindows.

3.3.1 Setting up Mininet/ubuntu VM for network con-nection

Before proceeding with the adapter setting of the Mininet/ubuntuVM, the default adapter set up was checked using “ifconfig” commandon the CLI of the Mininet and the result in Figure 25 was outputted.

35


Figure 25: Default adapter setting of Mininet/ubuntu VM

Open the Mininet settings window by selecting Mininet on theVirtualBox Manager windows and then clicking “Settings” tab. TheMininet-settings window will open. Selecting “Network” will show thenetwork adapters of the Mininet VM as shown in Figure 26.

Figure 26: Mininet VM network setting window

36


Adapter 1 in Figure 26 corresponds to eth0 interface in Figure25 and adapter 2 in Figure 26 corresponds to eth1 interface whichdoesn’t appear in Figure 25 because adapter 2 is not yet enabledfor the network. In Figure 25, eth0 interface has a NAT address of10.0.2.15/25. This NAT address enables the Mininet VM to connectto the Internet. To connect the Mininet to the “host-only network”in order to enable communication between it and the host machineand other VMs, adapter 2 was enabled and attached to “vboxnet0”as shown in Figure 27.

Figure 27: Setting up Adapter 2 for host-only network

After clicking “Ok” button to enable the settings in Figure 27, thecommand “ sudo dhclient eth1” was entered in the CLI of the Mininetto start the DHCP client in eth1 of the Mininet VM. Then “ifconfig”command was run to confirm the IPv4 address on the eth1 interface.The output of these commands is shown in Figure 28.

37


Figure 28: Setting up and confirmation of DHCP on eth1

Comparing Figure 28 with Figure 25, eth1 appears in Figure 28with an IPv4 address 192.168.56.102 from the DHCP pool configuredearlier in the VirtualBox. The IP address on eth1 will enable theMininet to have a connection with the local host and other VMs con-nected to “host-only Network”.

This setup was confirmed and tested with a ping from the lo-cal host to the Mininet VM IPv4 address (192.168.56.102) and withanother ping from the Mininet VM to the local host IPv4 address(192.168.56.1) as shown in Figure 29.

38


Figure 29: Ping results of host machine and Mininet VM

The two pings in Figure 29 both shows 100 percent success. Thisis a confirmation of the successful setup of the Mininet VM network.The Mininet is now ready to be accessed by the local computer andother VMs.

3.3.2 Setting up Mininet/ubuntu VM for SSH

The version of Mininet (version 2.2.2) at the time of downloading isa performance improvement and bug fix release. It is recommendedto destroy any default SSH keys in the existing Mininet VMs [40].The following commands were run on the Mininet CLI to enable SSHservice:

sudo rm -f /etc/ssh/*key*sudo /usr/sbin/dpkn-reconfigure openssh-serversudo service ssh restart

SSH connection was then established between the local computer andthe Mininet VM as shown in Figure 30.

39


Figure 30: SSH session between host machine and Mininet VM

Figure 30 shows a successful establishment of ssh session betweenthe local computer and the Mininet VM.

3.3.3 Setting up XTerm (X11) forwarding

XTerm is a terminal emulator for X11. X11 is referred to as X win-dow system or shortened as X. Xterm provides compatible terminalsfor programs that cannot use the window system directly. Differentinvocation of Xterm can run at the same time each running an inde-pendent input/output for a particular node. XTerm forwarding hasbeen set up in the host computer for opening configuration windowsof the Mininet nodes in the local/host computer. The following com-mands were run in the local computer terminal:

cd /ets/sshsudo gedit ssh config

After running the above command, the document in Figure 31 ap-pears.

40


Figure 31: Default SSH config file

In the document shown in Figure 31, “ ForwardX11 no” and “For-wardX11Trusted yes” are commented. This document is edited by un-commenting both “ ForwardX11 no” and “ForwardX11Trusted yes”and making sure that they are both prefixed “yes” as shown in Figure32.

41


Figure 32: Modified SSH config file

Clicking the “save” button, will save the changes and then closethe document. This setup will turn on Xterm /X11 forwarding atstartup.

This setup was tested by running “Xterm” command in the SSHsession running on the local computer. Xterm window appears afterrunning the “xterm” command in the ssh session of the local computeras shown in Figure 33.

42


Figure 33: Xterm sesion

This proofed successful implementation of the Xterm forwardingin the local computer.

3.3.4 MiniEdit

Mininet topology commands are used to create a network topologyin Mininet. In this paper, MiniEdit is as well use to create a net-work topology in Mininet. MiniEdit graphical user interface is usedto setup network made up of OpenFlow switches and Linux hosts andprovides a visual representation of the topology. The command belowwas run in the SSH session of the local machine and after few momentsMiniEdit window appears as shown in Figure 34. This concludes thesuccessful running of MiniEdit.

sudo /mininet/examples/miniedit.py

43


Figure 34: MiniEdit window

3.4 Ubuntu 16.04 Virtual Machine (VM)

Ubuntu 16.04 VM was added to the VirtualBox Manager. Ubuntu16.04 VM is used to set up ssh session with the Mininet VM to runthe POX controller.

3.4.1 Creating Ubuntu 16.04 VM

The Virtual Machine is created in the VirtualBox by clicking “New”button and filling and selecting the parameters as shown in Figure 35.

44


Figure 35: Virtual Machine creation

The “Next” button on the windows in Figure 35 was pressed. Amemory size allocation windows appear as shown in Figure 36.

Figure 36: VM creation Memory size window

45


In Figure 36, the default memory size was chosen by clicking onthe “Next” button. This leads to the hard disk specification windows.“Create a virtual hard disk now” option is chosen as shown in Figure37.

Figure 37: VM creation Hard disk specification window

Clicking “Create” button in the windows of Figure 37 opens thehard disk file type windows as shown in Figure 38 below.

46


Figure 38: VM creation Hards disk file type window

The default settings of the Hard disk file type window was taken.The “Next” button clicked and Storage on physical hard disk windowopened. The default selection is taken as shown in Figure 39 and the“Next” button clicked.

47


Figure 39: VM creation, storage on physical hard disk window

This leads us to the final window of the VM setup (File locationand size window) as shown in Figure 40.

48


Figure 40: VM setup, File location and size window

Clicking “Create” will create the Virtual Machine. The new VMwill appear on the VirtualBox Manager as sown in Figure 41.

Figure 41: Ubuntu VM in VirtualBox manager

49


This concludes the creation of Ubuntu 16.04 virtual machine setup.More details on the setup can be found at [41].

3.4.2 Installation of Ubuntu 16.04 ISO file in VM

This process starts by first downloading Ubuntu 16.04 ISO file fromthe official site of Ubuntu [42].

The VM (Ubuntu) is then selected on the VirtualBox Manager andthen the “Start” button clicked. After few moments, “select start-updisk” window appears. The arrow on the folder icon clicked to browseto the Downloads folder and select the downloaded Ubuntu 16.04 ISOfile as shown in Figure 42.

Figure 42: Ubuntu 16.04 ISO file instillation, Select start-up disk window

The “Start” button on the windows that appears in Figure 42was then clicked and the installation of Ubuntu 16.04 ISO file starts.The normal installation procedures for Ubuntu was followed until theend. After rebooting the VM, the screen in Figure 43 appears. Thiscompletes the installation of Ubuntu 16.04 in the VM.

50


Figure 43: Ubuntu 16.04 VM login window

3.4.3 Setup Shared Folder on Ubuntu 16.04 VM

Before enabling shared folder on Ubuntu 16.04 VM, VirtualBox GuestAdditions software was first installed on the VM. Guest Additionssoftware enables the Ubuntu 16.04 VM screen size to be extendableand also allows folder sharing between the VM and the host computer.

Guest Addition was installed by clicking “Devices”→ “Insert GuestAddition CD images” on the VM window and the warning on thewindow in Figure 44 appears.

51


Figure 44: Guest Addition window

The “Run” button on the windows that appears in Figure 44 wasclicked and the installation starts. The installation process was fol-lowed until the end. The VM was then restarted to enable the setupto take effect. This completes the installation of Guest Additions.

The shared folder was created by clicking “Devices” → “SharedFolder” → “Sheared Folder Settings” on the Ubuntu VM window.

A window in Figure 45 then appears. In the window, “MachineFolders” was selected and the add button icon on the right was clicked.

52


Figure 45: Sheared folder setting window of Ubuntu VM

After clicking the add button on the right, a small window appearson top of the previous window in Figure 45 as shown in Figure 46.

Figure 46: Ubuntu VM edit share window

The drop-down arrow key of the “Folder Path” is used to browseand select the “VMFiles” folder in the local Machine. VMFiles folderwas created earlier on the Desktop of the Local computer. This is

53


where shared files will be saved and retrieved in both the Ubuntu 16.04VM and the Local computer. “Auto-mount” and “Make Permanent”checkboxes are both checked as shown in Figure 46. The “OK” buttonwas then clicked. This completes the parameter settings of Shearedfolders as shown in the window that appears in Figure 47.

Figure 47: Sheared folder window of Ubuntu VM

“OK” button on the window in Figure 47 was then clicked to com-plete the setup of the shared folder on the Ubuntu VM.

To be able to use the VirtualBox Sheared Folder feature, the com-mand below was run in the terminal of the Ubuntu 16.04 VM.Sudo adduser pox vboxsf

After running the above command, the VM was restarted. Theshared folder appears in the list of files of the Ubuntu VM startingwith sf (sf VMFiles) as shown in Figure 48. This concludes the settingup of shared folder between the Ubuntu 16.04 VM and the Localcomputer.

54


Figure 48: Appearance of the sheared folder in ubuntu VM

3.4.4 Setting up Ubuntu 16.04 VM for Network

By default, only adapter one is enabled and with NAT as shown inFigure 49. This allows the VM to have an Internet connection

Figure 49: ubuntu VM default network setting

55


Figure 50 shows the output of the address assigned to the Ubuntu16.04 VM with NAT default configuration. In Figure 50 “ensp0s3corresponds to Adapter 1 in Figure 49.

Figure 50: Default address assignment on Ubuntu VM

Ubuntu 16.4 VM was then set up to connect to the “host-onlyNetwork” by attaching Adapter 1 to “Host-only Adapter” as shownin Figure 51.

56


Figure 51: Setting Adapter 1 as host-only network

After the above step,“ifconfig” command was run again and a newIP address configuration setup was effected as shown in Figure 52.This IPv4 configuration will enable the Ubuntu 16.04 VM to have SSHsession with the Mininet VM to enable it to run the POX controller.

57


Figure 52: New IPv4 address of Adapter 1 after setup of host-only network

3.4.5 Accessing POX controller in Ubuntu 16.4 VM

There are many types of SDN controllers available. In their feature-based comparison and performance evaluation of Ryu, Floodlight,ONOS, and OpenDayLight SDN controllers, L. Mamushiane et al.concludes that the choice of which controller to use is entirely de-pendent on the requirement of the user. They recommend the use ofOpenDayLight for interfaces vendor support, ONOS for best through-put result, Ryu for delay sensitive applications since it displays thebest latency result [43]. POX controller is use in this thesis.

POX is use by developers to create an SDN controller using Pythonprogramming language. POX communicates with SDN switches us-ing OpenFlow protocol or Open vSwitch Database (OVSDB) protocol[44]. POX comes with some components bundled with it. The compo-nents bundled with POX enables it to be immediately used as a basicSDN controller. A common way to build your own POX componentis to copy an existing module into “ext” directory and then modify it.The “ext” directory is automatically added to the python search pathby POX. In this paper we are not going to be building our own POXcomponent, we will use some of the components bundled with POX.

58


POX was started by first setting up SSH session between Ubuntu16.04 VM and the Mininet VM. Before starting the SSH session, it wasmade sure that, the Mininet VM was up and running and connectedto the “host-only Network”.

POX controller was then started by running the command “ sudo∼ /pox/pox.py” in the SSH session as shown in Figure 53.

Figure 53: Starting POX controller in Ubuntu VM

The command “sudo ∼/pox/pox.py” was only used during the set-ting up of the lab environment. Starting POX with “pox.py” optionwill make it to run under ordinary circumstances. Another option isto start POX with “debug-pox.py”. This option is use when doingdevelopment, it debugs problems. Some optional command line argu-ments ( eg “– verbose” and “–no-openflow”) can be use at the startof the command line. The optional command line arguments are notuse in this paper.

Note that, to start POX controller, one has to specify the functionsthe controller should perform at the time of starting it by selectingthe POX components that provides those functionality. Running POXby itself without components does not do much. Table 1 shows somePOX components that do different tasks.

59


Table 1: Some components bundled with POX

forwarding.l2 pairs make openflow switches to behave like a layer 2 learning switchesand install rules purely based on MAC addresses

forwarding.l3 learning Uses POX’s packet library to examine and construct ARP requestand replies. It is a layer 3 learning-switchy-thing and does notcare about IP addresses only learn where they are. If a host have agateway IP address configured on it, you can configure a fake defaultIP addresses with the command “./pox.py forwarding.l3 learning–fakways=10.0.0.254 192.168.0.1”. The IP addresses specified arethe default gateway IP to be use by the hosts

forwarding.topo proactiveforwarding rules are install based on the IP addresses of the topol-ogy. Uses discovery function.

Openflow.discovery sends LLDP messages out of OpenFlow switches for it to discoverthe network topology. It raise alarms when links goes up or down.

Openflow.keepalives POX sends periodic echo request to connected switches. This en-ables switches not to disconnect from the controller after a long idleconnection period to the controller. With a periodic echo requestssend to the switches and tracking the echo replies, you can estimatethe down time.

proto.dhcp is a DHCP server with a default address of 192.168.0.254 claimingitself to be the gateway and DNS server. The default client addressrange is from 192.168.0.1/24 to 192.168.0.253/24.

misc.full payload configures the switches to send full packets to the controller whena packet misses the table in a switch. By default when a packetmisses a table, the switch sends only part of the packet (the first128 bytes) to the controller.

log.level each log have a level associated to it which shows how severe it is.The log levels from most to least severe are critical, error, warning,info, and debug. INFO is the default level for POX.

hos tracker attempts to keep track of hosts in the network where they are andhow they are configured.60


An example command of starting POX controller with a stockcomponent is “sudo ∼/pox/pox.py forwarding.l2 learning”. POX con-troller terminal can be quit using ”Control-C” key combination.

After starting the POX controller, a topology has been created inMiniEdit to test the POX controller. The topology was set up in theMiniEdit as follows: A topology of four switches each with two hostsand a controller was set up in MiniEdit as shown in Figure 54.

Figure 54: Topology of 4 switches, 8 hosts, and 1 controller in MiniEdit

CLI was enabled on the MiniEdit window by clicking “Edit” andthen selecting “preferences” as shown in Figure 55. This allows thelog to be shown on the Mininet CLI.

61


Figure 55: Enabling CLI in MiniEdit

The remote controller is chosen for the controller type by right-clicking on the controller (C0) on the MiniEdit topology and selecting“Controller Details” as shown in Figure 56.

62


Figure 56: MiniEdit Controller setup

The topology in Figure 56 was then saved for future use by clicking“File” and the “Save”. After saving the topology, the “Run” buttonwas clicked to run the topology in Mininet. While the topology wasrunning in the Mininet, the POX controller shows logs in Figure 57.Remember that the POX controller was still up before running theMiniEdit topology.

63


Figure 57: Output of connected switches to controller in POX

The output in Figure 57 confirmed that all the four switches areconnected with the POX controller as designed on the MiniEdit win-dow. This concludes the environmental Setup and the testing of thecomponents.

This chapter discussed the components used for the simulationof SDN routing within IoT Robotics network and the steps used toinstall them. The components used and discussed in this chapter arelocal machine, virtualization system, Mininet/ubuntu VM, Ubuntu16.04 VM. The next chapter is the demo of SDN routing within IoTRobotics networks using four scenarios.

64


4 Demo of SDN routingwithin IoT Robotics

Network

65


4 Demo of SDN routing within IoT

Robotics Network

Conditions for routing packets in wireless networks can differ fromconditions for routing packets in wired networks. In wireless networks,if the same channel is used by the nodes, communication on thatchannel is heard by all nodes using the same channel. To avoid this,different communications are dedicated to different channels. In thisthesis, the focus is not on the physical and the data link layers. Inthe demo of SDN routing within IoT robotics, we assumed that thesituation of nodes using the same channel doesn’t exist.

During the demo four scenarios were simulated. Observation hasbeen made on the first three scenarios to observe how the SDN con-troller build flow tables on the various switches to enable routing ofpackets to the right destinations. On the fourth scenario, observationhas been made to confirm if routing within the nodes still continues ifthe SDN controller is completely isolated.

4.1 Simulation setup

During the demo four nodes (Node1, Node2, Node3, Node4), oneserver (Server), one OpenFlow Switch (Switch5), and one SDN Con-troller (POXcontroller) were used as shown in Figure 58.

66


Figure 58: Topology of demo of SDN routing within IoT Robotics Network

Each node represents an IoT robot and consist of one OpenFlowSwitch and one host as shown in Figure 58. In SDN devices suchas switches do not operate only at a specific layer of the OSI model.Devices in SDN can operate at any layer of the OSI Model dependingon the function it is carrying out. All the nodes belong to the samesubnet (10.0.0.0/8) and have a direct connection to the SDN controller(POXcontroller). The Server is in a different subnet (192.168.0.0/24)than the nodes. The server serves as the repository for all the nodes.The server is accessed through an OpenFlow Switch (Switch5) whichhave a direct connection to the SDN controller. As shown in Figure 58,some nodes have a direct connection to each other. This is depictingdirect connections between isolated nodes in IoT Robotic networks.

POXcontroller was started in SSH session in Ubuntu 64bit VM us-ing “log.level”, “forwarding.l2 pairs”, “forwarding.l3 learning” com-ponents as shown in Figure 59.

67


Figure 59: POX Controller started in Ubuntu VM

The topology in Figure 58 was created in MiniEdit using SSH ses-sion of the Mininet on the local machine. When the topology wasrun, confirmation of the connection of the OpenFlow switches to thePOXcontroller was shown on the POXcontroller window as shown inFigure 60.

figdsdnr3

Figure 60: POX Controller connecting to Switches

In Figure 61 Mininet command “net” is used in the SSH session

68


on the local machine to show the network topology in Mininet and theconnecting ports of the nodes.

Figure 61: Connecting ports of the nodes

The IP addresses and MAC addresses used on the four hosts (Node1h,Node2h, Node3h, and Node4h) and the Server are shown in Table2. The output of the command run in Figure 61 and the output ofMininet “ifconfig” command run for all the host machines was usedto populate Table 2.

Table 2: Interfaces, IP addresses, and MAC addresses used on the hosts

Node Active Port No. MAC Address IP address Default gateway IP

Node1h eth0 fa:87:9a:a2:52:c0 10.0.0.1 10.0.0.254

Node2h eth0 22:93:46:16:8e:b9 10.0.0.2

Node3h eth0 46:d9:0f:c0:10:25 10.0.0.3

Node4h eth0 f2:05:ac:3a:86:49 10.0.0.4

Server eth0 e2:c5:7e:8e:22:ee 192.168.0.2 192.168.0.1

69


4.2 Scenario 1: Routing between directly-connectednodes within the same subnet

Connectivity test was made between Node1 and Node4 using ping.Node1 and Node4 are directly connected to each other and they be-long to the same subnet. POXcontroller was first isolated, Figure62(a) and then a connectivity test done by sending pig packets fromNode1h to Node4h. This connectivity test could not be successful asshown in Figure 62(b). This is because this is the first packet exchangebetween Node1h and Node4h and there is no SDN controller to buildthe flow table in the switches for packets to be forwarded.

(a) Isolating POX controller (b) Connectivity test by ping command

Figure 62: Connectivity test before flows are created by the POXcontroller

The POXcontroller was connected back and the connectivity testrepeated. Since this is the first packet exchange between Node1h andNode4h, the packet first went to the POXcontroller after the ARPprocess. The POXcontroller then created flows in Node1s and Node4s.

The “dpctl dump-flows” Mininet command outputted the flowsbuild by the POXcontroller in the flow tables of the Node4s switchand Node1s switch as shown in Figure 63. The flow tables of the restof the switches (Node3s, Switch5, and Node2s) are still empty, thusthe POXcontroller did not build any flow in them because they haveno routing task yet.

70


Figure 63: Flow table build for routing between Node1h and Node4h

The building process of the flows in the flow tables of the Node1sswitch and the Node4s switch was monitored using Wireshark. Fig-ures 64 and Figures 65 shows the captures by Wireshark during thebuilding of the flows in the Node4s switch by the POXcontroller forthe exchange of packets between Node1h and Node4h.

71


Figure 64: Flow build in Node4s for routing packets from Node1h to Node4h

72



Figure 66 and Figure 67 show the captures by Wireshark duringthe building of the flows in the Node1s switch by the POXcontrollerfor the exchange of packets between Node1h and Node4h.

73



74



After the building of flows by the POXcontroller the connectivitytest was seen successful as shown in Figure 68.

75


Figure 68: Connectivity test between Node1h and Node4h

After repeating the same connectivity test between Node1h andNode4h after the flows have been created in the switches the RoundTrip Time (RTT) time was seen to be less than the previous test dur-ing which the flows were built by the POXcontroller. Figure 69 showsthe comparison of RTT time in the two connectivity tests.

76


Figure 69: Comparing connectivity tests between Node1h and Node4h

The difference in the RTT time of the two connectivity tests isbecause the packets are no more going to the POXcontroller sinceNode1s and the Node4s switches already have the route entries intheir flow tables.

This scenario shows how SDN controller builds flows in directlyconnected nodes and allow them to route packets between each other.

4.3 Scenario 2: Routing between none directly-connected nodes within the same subnet

Node2 and Node4 are within the same subnet (10.0.0.0/8) but notdirectly connected to each other. Connectivity test made betweenNode2h and Node4h using ping first went to the POXcontroller afterthe ARP process. This is because this is the first packet exchangebetween Node2h and Node4h. Upon receiving packets from Node2h,the POXcontrolle build flows in Node2s, Node1s, and Node4s switchesto enable routing of packets between Node2h and Node4h.

Figure 70 is the output of “dpctl dump-flows” Mininet commandshowing flow entries build by the POXcontroller in Node2s, Node1s,

77


and Node4s switches as a result of packet exchange between Node2hand Node4h.

Figure 70: flow entries build by POXcontroller for exchange of packets betweenNode2h and Node4h

Note that, there is no flow entry for Switches Node3s and Switch5in Figure 70. This is because they do not have any routing task as atnow.

The building process of the flows in the flow tables of Node2s,Node1s, and Node4s switches for the routing of packets between Node2hand Node4h was monitored using Wireshark. Figure 71 and Figure72 shows the captures on Wireshark during the building of the flowsin switch Node4s by the POXcontroller for the exchange of packetsbetween Node2h and Node4h.

78



79



Figure 73 and Figure 74 shows the captures on Wireshark duringthe building of the flows in switch Node1s by the POXcontroller forthe exchange of packets between Node2h and Node4h.

80


Figure 73: Flow build in Node1s switch for routing packets from Node2h toNode4h

81



Figure 75 and Figure 76 shows the captures on Wireshark duringthe building of the flows in switch Node2s by the POXcontroller forthe exchange of packets between Node2h and Node4h.

82



83



The connectivity test was then seen successful as shown in Figure77.

84


Figure 77: Connectivity test between Node2h and Node4h

The same connectivity test was repeated after the flows ware buildby the POXcontroller in the various switches. With this connectivitytest, RTT time taken by the packets is less than the previous connec-tivity test. Figure 78 shows the comparison of the two connectivitytests.

85


Figure 78: Comparison of connectivity tests between Node2h and Node4h

The difference in the RTT time is due to the fact that during thesecond connectivity test, packets were not routed to the POXcontrollerinstead they were routed according to the flows in the flow tables ofthe switches.

This scenario shows that SDN controller build flows in nodes suchthat nodes that are not directly connected to each other can routepackets to each other through other nodes.

4.4 Scenario 3: Routing between none directly-connected nodes in different subnets

Node1 and the Server are none directly-connected nodes in differ-ent subnets. Before the connectivity test between Node1h and theServer, default gateway addresses were assigned to both Node1h andthe Server using the commands shown below:

mininet > Node1h route add default gw 10.0.0.254mininet > Server route add default gw 192.168.0.1

86


The default gateway configuration on Node1h and the Server are nec-essary since they are on different subnets. Note that the same defaultgateway addresses were used during the starting of the POXcontrollerin Figure 59.

Connectivity test was done using ping command from Node1h toServer. Since this is the first packet exchange between Node1h andServer, the packets were forwarded to the POXcontroller after theARP process. The POXcontroller then build flow entries in Node1s,and Switch5 switches to enable routing of packets between Node1hand the server.

The connectivity test was then seen successful as shown in Figure79.

Figure 79: Connectivity tests between Node1h and Server

The ARP process captured by Wireshark during the connectivitytest between Node1h and the Server is shown in Figure 80 and Figure81. Figure 80 shows ARP request from Node1h and Figure 81 showsARP response from the POXcontroller. This is so because the defaultgateway addresses (10.0.0.254 and 192.168.0.1) are configured on thePOXcontroller.

87


Figure 80: ARP request from Node1h

88


Figure 81: ARP reply from POXcontroller

This scenario demonstrates how SDN controller enables routingbetween nodes of different subnets.

4.5 Scenario 4: Routing between nodes witha completely isolated SDN controller

The objective of this scenario is to confirm continuous routing of pack-ets between nodes in a situation where the controller is completelyisolated. To simulate this scenario, the POXcontroller was completelyisolated from the nodes (Node1s, Node2s, Node3s, Node4s), and Switch5.

Then the connectivity tests done in the previous scenarios (Sce-nario 1, Scenario 2, and Scenario 3) were repeated. Repeated testsfor scenario 1 and scenario 2 were successful except for Scenario 3 asshown in Figure 82.

89


Figure 82: Repeated test on Scenario 1, 2 and 3 with isolated POXcontroller

This scenario demonstrates that in SDN routing after the flowtables are built, nodes can route packets to each other within thesame subnet even if the SDN controller is completely isolated. Fornodes in different subnets, routing ceases after the isolation of theSDN controller because the SDN controller serves as the gateway forthe subnets.

This chapter demonstrated SDN routing within IoT Robotics net-works with four scenarios. The first scenario demonstrated SDNrouting between directly-connected nodes within the same subnet.The second scenario demonstrated routing between none directly-connected nodes within the same subnet. The third scenario demon-strated routing between none directly-connected nodes in differentsubnets. The fourth scenario demonstrated routing between nodeswith a completely isolated SDN controller. The next chapter will dis-cuss the conclusion of the thesis and suggest possible future researchworks.

90


5 Conclusions and futureworks

91


5 Conclusions and future works

The problem of routing in IoT Robotic networks have been elaborated.Review of solutions provided by some common routing protocols usein IoT Robotics networks today was discussed. This review concludedthat every routing protocol is used for a particular purpose. Thus, cur-rently there is no routing protocol that addresses all problems. Thiscall for the need of developing a routing protocol that will address mul-tiple issues. In IoT Robotics, nodes serve as both host and router. Asa host, the nodes send and receive messages and as a router, the nodesmakes the routing decision for the forwarding of packets. This makesthe nodes to need more energy and resources to carry out these tasks.These are some of the biggest concerns in IoT Robotics networks sincenodes are expected to function in an isolated environment where theywill need to function under the energy and resources available in them.

This thesis proposed the use of SDN technologies to enhance rout-ing within IoT Robotics networks for precision farming. With SDNrouting within IoT Robotics networks, energy and resource needs ofthe nodes will be greatly improved. SDN separates the Controllerplane and the Data plane and allows programming of nodes by ad-ministrator how data is routed in the network. The nodes only housethe data plane. Controller plane where routing decisions are made ishoused in a central controller. This reduces the high energy demandand resource constraints of the nodes. It also enables simple, reliable,and more manageable routing within IoT Robotics networks.

The environmental setup for the demonstration of SDN routingwithin IoT Robotic network was done by using One Ubuntu 16.0464bits local machine, a virtualization system (Oracle virtual box),one Mininet Ubuntu VM (this came bundled with a POX controller,Wireshark, and MiniEdit), and one Ubuntu 16.04 64bits VM.

Four scenarios have been demonstrated. The first scenario demon-strates how controller build flows in directly-connected nodes that arein the same subnet to enable routing between them. This demon-stration shows that routing between directly connected nodes cannotbe possible before the building of flows in the nodes by the controller.The second scenario demonstrates how the controller build flows in dif-ferent nodes to enable routing between none directly-connected nodesthat are in the same subnet. In this demonstration captures of howthe controller build flows in different nodes were made and the routingof packets between the none directly-connected nodes through other

92


nodes was successful. The third scenario demonstrates how the con-troller handles routing between nodes that are in different subnetsby using itself as the default gateway. During this demonstration,captures were made on how the nodes performed their ARP requestand how the controller made the ARP responses as the default gate-way. After the ARP processes, routing was successful between thetwo nodes in different subnets. The fourth scenario was done by com-pletely isolating the Controller and repeating the connectivity tests ofthe above three scenarios. Tests for the first and the second scenariowere successful. This shows that after the building of flows by thecontroller, the nodes that are within the same subnet can still routepackets to each other in isolation. The test for the third scenariocould not be successful. This is because the isolated controller servesas the default gateway for the nodes in different subnets and packetsforwarded to it while in isolation are drop. These four scenarios areproof of concept proposed in this thesis.

The aim of this thesis is to enhance the management of routing inIoT Robotics networks using SDN technologies. The demonstrationsof SDN routing within IoT Robotics networks made in this thesis isa successfully proof of concept proposed in this thesis.Possible futureresearch directions derived from this work can be summarized as fol-lows.

One of the issues observed during the demonstrations is that,directly-connected nodes could not route packets to each other afterinitialization and before the building of flows in their flow tables bythe controller. Future work can focus on finding solutions for directly-connected nodes to be able to build flows in their own flow tables toenable routing between them after initialization and where the con-troller is not reachable. The nodes should exchange the informationin their flow table to the controller upon their connection for synchro-nization purpose. This will enable the SDN enable nodes to be ableto route packets between each other when they encounter each otherin isolation. It will as well enable isolated nodes to synchronize theentries of their flow tables with the controller upon their connectionwith the controller.

Another issue observed during the demonstration and may needfuture findings is the issue of nodes in different subnets not been ableto route to each other after the isolation of the Controller that servesas the default gateway. The solution to this issue will be a great in-vention in SDN routing between IoT Robotics networks. The solution

93


will enable communication between nodes of different subnets whilethe SDN controller is still isolated. Other possible future researchdirections can include the following.

As the potential of SDN technology is recognized to be beyond justreliable packet transfer [45],[46],[47]. SDN technology can be used inIoT Robotics networks to solve a number of issues including trackingof mobile nodes. SDN technology can be utilized in IoT networks totrack the moving nodes. It is importing to track the moving node toknow its current location as well as to know how far it is from othernodes. This is very useful in livestock management as it can be usefor monitor livestock for security purpose. If a node goes isolated andcannot be located anywhere, this will help to determine how long ithas gone isolated and where it was last seen alive.

Since the number of nodes to be deployed can be significant, theperformance of SDN network will heavily depend on the responsetime of the SDN controller to PACKET IN messages and the num-ber of PACKET IN messages SDN controller can handle per second.PACKET IN messages are packets the OpenFlow switches have noflow entries for. OpenFlow switches forward such packets to the SDNcontroller to enable it to make a decision on the routing of the pack-ets to the right destination. Improving the respond time of SDNcontrollers to PACKET IN messages and improving the number ofPACKET IN messages it can handle per second could be an impor-tant research area in the development of SDN.

94


6 References

[1] D. Guo, Y. Zhang, L. He, K. Zhai, and H. Tan, “Chebyshev-polynomial neuronet, wasd algorithm and world populationprediction from past 10000-year rough data”, in The 27thChinese Control and Decision Conference (2015 CCDC),May 2015, pp. 1702–1707. doi: 10 . 1109 / CCDC . 2015 .

7162194.[2] Y. Zhang, N. Wang, L. He, W. Li, and H. Tan, “A poten-

tial saturation value of world population is near?”, in 2016IEEE 13th International Conference on Signal Processing(ICSP), Nov. 2016, pp. 1781–1786. doi: 10.1109/ICSP.2016.7878134.

[3] N. United. (Jun. 2017). World population prospects: The2017 revision, [Online]. Available: http://wos.fecyt.es.

[4] WOS. (). Scientific and technological publications, [Online].Available: http://wos.fecyt.es.

[5] WIPO. (). Scientific and technological patent, [Online]. Avail-able: http://www.wipo.int/pctdb/en.

[6] A. K. Sharma and M. C. Trivedi, “Performance compari-son of aodv, zrp and aodvdr routing protocols in manet”,in 2016 Second International Conference on ComputationalIntelligence Communication Technology (CICT), Feb. 2016,pp. 231–236. doi: 10.1109/CICT.2016.53.

[7] P. Jacquet, P. Muhlethaler, T. Clausen, A. Laouiti, A. Qayyum,and L. Viennot, “Optimized link state routing protocol forad hoc networks”, in Proceedings. IEEE International MultiTopic Conference, 2001. IEEE INMIC 2001. Technology forthe 21st Century., 2001, pp. 62–68. doi: 10.1109/INMIC.2001.995315.

[8] C. S. R. Putta, K. B. Prasad, D. Ravilla, R. S. M. Nath, andM. L. R. Chandra, “Performance of ad hoc network rout-ing protocols in ieee 802.11”, in 2010 International Con-ference on Computer and Communication Technology (IC-CCT), Sep. 2010, pp. 371–376. doi: 10.1109/ICCCT.2010.5640497.

[9] H. M. Xin and K. Yang, “Routing protocols analysis forinternet of things”, in 2015 2nd International Conference on

95


Information Science and Control Engineering, Apr. 2015,pp. 447–450. doi: 10.1109/ICISCE.2015.104.

[10] A. Bhat and V. Geetha, “Survey on routing protocols forinternet of things”, in 2017 7th International Symposiumon Embedded Computing and System Design (ISED), Dec.2017, pp. 1–5. doi: 10.1109/ISED.2017.8303949.

[11] N. Li, J.-F. Martınez, J. M. Meneses Chaus, and M. Eckert,“A survey on underwater acoustic sensor network routingprotocols”, Sensors, vol. 16, no. 3, 2016, issn: 1424-8220.[Online]. Available: http://www.mdpi.com/1424-8220/16/3/414.

[12] N. Li, B. Curuklu, J. Bastos, V. Sucasas, J. A. S. Fernan-dez, and J. Rodriguez, “A probabilistic and highly efficienttopology control algorithm for underwater cooperating auvnetworks”, Sensors, vol. 17, no. 5, 2017, issn: 1424-8220.[Online]. Available: http://www.mdpi.com/1424-8220/17/5/1022.

[13] M. Kardoust, M. R. Khayyambashi, and A. Bohlooli, “In-troducing a method for improving the performance of rout-ing algorithms in unmanned aeronautical ad-hoc networks”,in 2017 9th International Conference on Information andKnowledge Technology (IKT), Oct. 2017, pp. 85–92. doi:10.1109/IKT.2017.8258623.

[14] ONF. (Jun. 2014). Sdn architecture issue 1, [Online]. Avail-able: https://www.opennetworking.org/images/stories/downloads / sdn - resources / technical - reports / TR _

SDN_ARCH_1.0_06062014.pdf.[15] O. N. Foundation. (Feb. 2016). Sdn architecture issue 1.1,

[Online]. Available: https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-

reports/TR-521_SDN_Architecture_issue_1.1.pdf.[16] F. Tang, Z. M. Fadlullah, B. Mao, and N. Kato, “An in-

telligent traffic load prediction based adaptive channel as-signment algorithm in sdn-iot: A deep learning approach”,IEEE Internet of Things Journal, pp. 1–1, 2018. doi: 10.1109/JIOT.2018.2838574.

[17] R. Bencel, K. Kost’al, I. Kotuliak, and M. Ries, “Commonsdn control channel for seamless handover in 802.11”, in

96


2018 Wireless Days (WD), Apr. 2018, pp. 34–36. doi: 10.1109/WD.2018.8361690.

[18] W. Qi, Q. Song, X. Wang, L. Guo, and Z. Ning, “Sdn-enabled social-aware clustering in 5g-vanet systems”, IEEEAccess, pp. 1–1, 2018. doi: 10.1109/ACCESS.2018.2837870.

[19] Y. Bi, G. Han, C. Lin, Q. Deng, L. Guo, and F. Li, “Mo-bility support for fog computing: An sdn approach”, IEEECommunications Magazine, vol. 56, no. 5, pp. 53–59, May2018, issn: 0163-6804. doi: 10.1109/MCOM.2018.1700908.

[20] S. Tomovic and I. Radusinovic, “A new traffic engineeringapproach for qos provisioning and failure recovery in sdn-based isp networks”, in 2018 23rd International Scientific-Professional Conference on Information Technology (IT),Feb. 2018, pp. 1–4. doi: 10.1109/SPIT.2018.8350854.

[21] A. R. Abdou, P. C. van Oorschot, and T. Wan, “Compar-ative analysis of control plane security of sdn and conven-tional networks”, IEEE Communications Surveys Tutorials,pp. 1–1, 2018. doi: 10.1109/COMST.2018.2839348.

[22] I. H. Abdulqadder, D. Zou, I. T. Aziz, and B. Yuan, “Mod-eling software defined security using multi-level securitymechanism for sdn environment”, in 2017 IEEE 17th Inter-national Conference on Communication Technology (ICCT),Oct. 2017, pp. 1342–1346. doi: 10 . 1109 / ICCT . 2017 .

8359852.[23] ONF. (Apr. 2012). Software-defined networking:the new norm

for networks, [Online]. Available: https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-

papers/wp-sdn-newnorm.pdf.[24] ONF-TS-020. (Dec. 2014). Openflow switch specification

version 1.5.0 ( protocol version 0x06 ), [Online]. Available:https://www.opennetworking.org/images/stories/

downloads/sdn-resources/onf-specifications/openflow/

openflow-switch-v1.5.0.noipr.pdf.[25] ONF-TS-023. (Mar. 2015). Openflow switch specification

version 1.3.5 ( protocol version 0x04 ), [Online]. Available:https://www.opennetworking.org/images/stories/

downloads/sdn-resources/onf-specifications/openflow/

openflow-switch-v1.3.5.pdf.

97


[26] ONF. (Oct. 2014). Openflow management and configura-tion protocol (of-config 1.2), [Online]. Available: https://www.opennetworking.org/images/stories/downloads/

sdn-resources/onf-specifications/openflow-config/

of-config-1.2.pdf.[27] R. Jmal and L. C. Fourati, “Implementing shortest path

routing mechanism using openflow pox controller”, in The2014 International Symposium on Networks, Computers andCommunications, Jun. 2014, pp. 1–6. doi: 10.1109/SNCC.2014.6866528.

[28] A. Kumar and A. Lakkshmanan, “An enhancement of dy-namic source routing by efficient load balancing in wire-less ad hoc networks”, in 2013 IEEE International Con-ference on Computational Intelligence and Computing Re-search, Dec. 2013, pp. 1–6. doi: 10.1109/ICCIC.2013.6724123.

[29] C. E. Perkins and E. M. Royer, “Ad-hoc on-demand dis-tance vector routing”, in Mobile Computing Systems andApplications, 1999. Proceedings. WMCSA ’99. Second IEEEWorkshop on, Feb. 1999, pp. 90–100. doi: 10.1109/MCSA.1999.749281.

[30] I. V. S. Brito and G. B. Figueiredo, “Improving QoS andQoE Through Seamless Handoff in Software-Defined IEEE802.11 Mesh Networks”, IEEE COMMUNICATIONS LET-TERS, vol. 21, no. 11, 2484–2487, NOV 2017.

[31] P. Wang, H. Xu, L. Huang, J. He, and Z. Meng, “ControlLink Load Balancing and Low Delay Route Deploymentfor Software Defined Networks”, IEEE JOURNAL ON SE-LECTED AREAS IN COMMUNICATIONS, vol. 35, no.11, 2446–2456, NOV 2017.

[32] J. Zheng, G. Chen, S. Schmid, H. Dai, J. Wu, and Q. Ni,“Scheduling Congestion- and Loop-Free Network Update inTimed SDNs”, IEEE JOURNAL ON SELECTED AREASIN COMMUNICATIONS, vol. 35, no. 11, 2542–2552, NOV2017.

[33] N. Abdolmaleki, M. Ahmadi, H. T. Malazi, and S. Milardo,“Fuzzy topology discovery protocol for SDN-based wireless

98


sensor networks”, SIMULATION MODELLING PRACTICEAND THEORY, vol. 79, 54–68, DEC 2017.

[34] A. Mayoral, R. Vilalta, R. Munoz, R. Casellas, and R.Martinez, “SDN orchestration architectures and their in-tegration with Cloud Computing applications”, OPTICALSWITCHING AND NETWORKING, vol. 26, no. SI, 2–13,NOV 2017.

[35] X. Ye, G. Cheng, and X. Luo, “Maximizing SDN controlresource utilization via switch migration”, COMPUTERNETWORKS, vol. 126, 69–80, OCT 24 2017.

[36] S. Sehaller and D. Hood, “Software defined networking ar-chitecture standardization”, COMPUTER STANDARDS &INTERFACES, vol. 54, no. 4, SI, 197–202, NOV 2017.

[37] T. Zhang, P. Giaccone, A. Bianco, and S. De Domenico,“The role of the inter-controller consensus in the placementof distributed SDN controllers”, COMPUTER COMMUNI-CATIONS, vol. 113, 1–13, NOV 15 2017.

[38] Oracle. (Feb. 2018). Download virtualbox for linux hosts,[Online]. Available: https://www.virtualbox.org/wiki/Linux_Downloads.

[39] Github. (Mar. 2017). Mininet vm images, [Online]. Avail-able: https : / / github . com / mininet / mininet / wiki /

Mininet-VM-Images.[40] Mininet. (Mar. 2017). Announcing mininet 2.2.2, [Online].

Available: http : / / mininet . org / blog / 2017 / 03 / 17 /

announcing-mininet-2-2-2/.[41] Linux. (Jan. 2015). Install ubuntu, [Online]. Available: https:

/ / linus . nci . nih . gov / bdge / installUbuntu . html #

install.[42] Ubuntu. (Jan. 2016). Download ubuntu desktop, [Online].

Available: https://www.ubuntu.com/download/desktop.[43] L. Mamushiane, A. Lysko, and S. Dlamini, “A comparative

evaluation of the performance of popular sdn controllers”,in 2018 Wireless Days (WD), Apr. 2018, pp. 54–59. doi:10.1109/WD.2018.8361694.

[44] L. R. Prete, A. A. Shinoda, C. M. Schweitzer, and R. L. S.de Oliveira, “Simulation in an sdn network scenario usingthe pox controller”, in 2014 IEEE Colombian Conference on

99


Communications and Computing (COLCOM), Jun. 2014,pp. 1–6. doi: 10.1109/ColComCon.2014.6860403.

[45] X. Wei and Q. Sun, “A wireless control plane for deployingsdn in data center networks”, in 2017 IEEE 17th Interna-tional Conference on Communication Technology (ICCT),Oct. 2017, pp. 981–985. doi: 10.1109/ICCT.2017.8359781.

[46] F. Chahlaoui and H. Dahmouni, “Towards qos-enabled sdnnetworks”, in 2018 International Conference on AdvancedCommunication Technologies and Networking (CommNet),Apr. 2018, pp. 1–7. doi: 10.1109/COMMNET.2018.8360251.

[47] J. Wang, S. Zhang, W. Chen, D. Kong, X. Zuo, and Z.Yu, “Design and implementation of sdn-based underwateracoustic sensor networks with multi-controllers”, IEEE Ac-cess, pp. 1–1, 2018. doi: 10.1109/ACCESS.2018.2835477.

100

universidad politecnica de madridoa.upm.es/54392/1/tesis_master_saloum_jimbara.pdf · within iot...

Documents