Scalability of Software Defined Network on Floodlight Controller using OFNet

Transcription

1 2017 International Conference on Electrical, Electronics, Communication, Computer and Optimization Techniques (ICEECCOT) Scalability of Software Defined Network on Floodlight Controller using OFNet Saleh Asadollahi Computer Science Saurashtra University Rajkot, India Bhargavi Goswami, Ahmad Sohaib Raoufy, Hedmilson Guimaraes Jose Domingos Computer Science Christ University Bangalore, India Abstract Software Defined Network is the thriving area of research in the realm of networking. With growing number of devices connecting to the global village of internet, it becomes inevitable to adapt to any new technology before testing its scalability in presence of dynamic circumstances. While a lot of research is going on to provide solution to overcome the limitations of the traditional network, it gives a call to research community to test the competence and applicability to hold up the fault tolerance of the solution offered in the form of SDN Controllers. Out of the accessible multiple controllers with enabled the SDN functionalities to the network infrastructure, one of the best choice in controllers is Floodlight Controller. This research article is a contribution towards performance evaluation of scalability of the Floodlight Controller by implementing dual scenarios implemented, experimented and analyzed on the emulation tool of OFNet. Floodlight Controller is tested in the emulation environment by observing eight different parameters of the controller and checked its performance in scalable networking conditions over linear topology by gradually increasing the number of nodes. Keywords Software Defined Networks(SDN), Controller, OpenFlow, Floodlight, OFNet, OpenFlow. I. INTRODUCTION It is 1983 the birth year of IPv4 indicating about 35 years of existence of Internet. New technologies and concepts such as IoT, 4G, 5G and VANET [1] cause almost all the devices connect to each other through the internet. Internet as a part of computer network is based on traditional network equipments and infrastructure such as routers and switches were working suitably so far. But, Lack of global view of entire network, modifying and making change dynamically in network, huge administrator task, time and cost consuming and no programmability option can be mentioned as problems of computer network where as number of device increased more than one per user today and increasing day by day [2]. SDN rose as address to above mentioned problems with lack of base concept of separation of Control plan from Data plan. Traditional routers and switches are combined of control plan and data plan in same chassis making these devices complex and a big headache for administrators to configure each device individually with pre-defined and low level commands. Taking away the Control plan (brain) of each device and providing a centralized controller for entire or a part of network, simplifies the traditional devices. In this approached, switches contain just few physical and logical port for transfer the data among flow tables that are filled up by controller. Reactive and proactive are two way to fill up the flows tables in each switches. Proactive) flow tables are filled up with few records before controller runs. Once new packet arrives, in lack of information it will be sent to controller. In other mode Reactive) there are no records in tables, once controller starts, every new packet enters to the switches, IN_PACK message is sent to the controller, according to the configuration and programs controllers respond via OUT_PACK to switches and fill up the flow tables with new records. Southbound interface and northbound interface are important objectives in SDN where southbound interface plays as a bridge between the switches and controller and allow controller to manage and feed the end devices. OpenFlow[3], Opflex[4], ForCES [5], NETCONF [6], POF [7], etc., are the examples of southbound interface where as OpenFlow is most well known and standardization which is used widely in research community with current version of 1.5. Northbound interfaces work between the controller and applications resided in application plan and provide an abstract for programmer to avoid complex details of how low level devices works. There are numbers of SDN controller such as OpenDaylight [8], POX [9], Beacon [10], NOX [11], Ryu [12], Floodligh [13] etc., with different feature and complexity that authors in [14] have provided article on comparison of these controllers. With this paper, authors are providing detailed demonstration of experimenting with particularly OFNet [15] emulator over Floodlight Controller over the emulation environment using two different scenarios implemented in linear topology by increasing number of nodes in multiples. Section II provides detailed description of working of Floodlight giving glimpses on features of the controller used in the experiments followed /17/$ IEEE

2 by section III providing details about OFNet emulator used in the experiments. Section IV provides the details of the apparatus and experimental setup with details of the commands used to execute the developed networking scenario which is near to real life scenario over emulator. This section provides step by step implementation procedure of experimentations. Section V provides the detailed performance evaluation of the obtained eight different performance matrices followed by conclusion and references. II. FLOODLIGHT CONTRLLER Floodlight is an open source, Java-based and Apache licensed SDN platform. Floodlight v1.2 supports OpenFlow 1.0 and 1.3 along with experimental support for OpenFlow 1.1, 1.2, and 1.4. Floodlight uses the Java library generated OpenFlowJ-Loxigen. Floodlight controller came with collection of application in application layer on top of it. Beacon controller is used as its foundation. it is one of the open source project contributions from Big Switch Networks (BNC). Additionally it is an open standard managed by Open Network Foundation (ONF). Modular architecture is a term to describe the Floodlight architecture. The core architecture includes various modules, such as topology management, device/end-station management, path/route computation, infrastructure for web access (management), counter store (OpenFlow counters), and a state storage system, that are well stitched by module-management system. Floodlight controller includes number of different module, application and utility such link discovery, topology manager/routing, device manager, packet streamer, firewall, etc. it also support web GUI interface, figure 1 shows topology connectivity with other option such as dashboard, switches and hosts. It shows connectivity of 5 switches in linear topology. simulator and emulators which is widely used by research community. Mininet is an amazing tool to generate simulation environment of SDN OpenFlow network with customized number of flows and number of hosts in fraction of seconds. But, if falls short when additional desirable emulation capabilities are expected such as easy debugging of networks that are SDN enabled, detecting connectivity and flow generation errors in controllers, testing controllers behavior other than ping, generating near to real world traffic scenario obtaining matrices such as CPU cycles eaten up by individual OF Switch, debugging and determining active flows in case of flow failures, visualization support for network scenarios. It is notable; the switch that OFNet uses is OVS-Switch [17]. To overcome all these stated shortcomings, OFNet comes into the picture. In addition to all the stated advantages over Mininet, it supports exciting features such as testing of controllers, generation of customized traffic and monitoring performance that inspires researchers to explore more about this emulator. Fig.2 shows the OFNet architecture. The authors of this paper are writing this paper with an intension of contribution to research community by bringing ease and confidence amongst the SDN knowledge seekers though experimenting practically, demonstrating and bringing out results obtained using OFNet. While experimenting, it was observed that the biggest advantage of using this emulator is its inbuilt traffic generation capabilities providing functional utility of performance of controllers by providing us results directly in graphs. It provides us results in the form of graphs such as flow generation rate, flow failures, average flow set up latency, message to and from controllers, flow missed and flow modes, maximum and average flow table entries, average RTT, CPU utilization, etc. In this paper, we have utilized these prominent features of OFNet emulator to emulate the scalability of Software Defined Networks using Floodlight Controller to analyze the performance matrix in presence of small to large scale networks that is described in details in next section. Fig. 2. OFNet Simulation Architecture Fig. 1. Nodes connectivity in GUI Floodlight controller environment III. OFNET The first question that comes to our mind is why do we need additional network emulator when Mininet [16] already exist. Mininet is an open source SDN both IV. EXPERIMENTAL ENVIRONMENT In this section authors provide the details of the experimental settings done. The aim of this experiment is to test the scalability of SDN network over OFNet using Floodlight Controller. As an emulator, we have used 558

3 OFNet and as a controller, we have used Floodlight. This section demonstrates the experimental setup to determine scalability of Floodlight Controller based network topology with increasing number of host in OFNet. Step 1: First step is to generate topology over OFNet. For this, we need to create a scenario and based on that, we should write our topology file with.topo extension. The content of.topo file is provided in Fig.3 which also shows the generated topology by that topo file once topo file is executed using command: topoc <filename.topo> <output.net>. TOPOLOGY my_custom_topo { NODES SECTION : switches 5; hosts 100; LINKS SECTION : /* Trunks - switch to switch links. Switch names start with gs0. */ gs0 -- gs1; gs1 -- gs2; gs2 -- gs3; gs3 -- gs4; /* Host to switch links. Host names start with gh1. */ (gh1-gh20) -- gs0; (gh21-gh40) -- gs1; (gh41-gh60) -- gs2; (gh61-gh80) -- gs3; (gh81-gh100) -- gs4; CONTROLLER SECTION : contrl0( ); /* Wire switches to controllers */ ALL -- contrl0; } Step 4: Generate the traffic using command: tctrl start. Fig. 3 shows the output of the provided command. Fig. 1 shows the execution of scenario in Floodlight. Step 5: Output is generated after traffic monitoring dashboard activities are completed and results that are obtained are discussed in next section. V. PERFORMANCE ANALYSIS This section provides the results obtained during the experimentation. The figures provided in this section have two graphs. Top graph show results obtained in scenario with 100 nodes and bottom graph shows results obtained in scenario with 50 nodes. Fig. 4 shows the Flow Failures per second. It was observed that top graph showing scenario with 100 nodes have flow failures in the range of two to four every 10 seconds. The same Fig.4 bottom graph shows 0 flow failures during the entire simulation run for scenario with 50 nodes. Fig. 3. Topo file content and generated scenario In this experiment, there are 5 switches connected to 1 controller. Each switch is connected to 10 host that makes it total 50 nodes in first scenario. The only difference in second scenario is the number of nodes each switch gets connected to. In second scenario, each switch gets connected to 20 hosts making the total number of host equal to 100. As we can observe the.topo file content, first we provide the number of switches =5, number host = 100 followed by link section. In link section, we connect switches to each other. Please note that switch names has suffix gs and host names has suffix gh. Eg. gs0, gh1, etc. Further, in link section we connect range of hosts to switch. At the end, we configure controller by providing IP of floodlight controller followed by connecting all host to the controller. If the controller is installed in the same machine, we can provide loopback address of the system. Step 2: Start floodlight controller command: java -jar target/floodlight.jar Step 3: Start the OFNet Network with the command: ctopo netup <output.net>. Fig. 4. Flow Failure for scenario one and two Fig.5 shows average flow setup latency. As the number of flows is more in scenario with 100 nodes connectivity, it was observed in top graph of Fig.5 that average flow setup latency is more in comparison on bottom graph depicting latency of flow setup for scenario with 50 nodes. Fig. 5. Avreage Flow Setup Latency for scenario one and two 559

4 Fig.6 and Fig.7 shows the OF messages to and from controller for both the scenarios. It was observed in the graphs that variation in scenario having 100 nodes is far more in comparison of the graph for scenario with 50 nodes. The reason for this must be presence of huge traffic creating congestion for the large number of communicating nodes in first scenario [18]. Fig. 8. Flow Misses to Controller for scenario one and two Fig. 6. OpenFlow Messages to Controller for scenario one and two Fig. 9 shows the maximum flow table entries for both the scenarios. It is observed that it never overflows the capacity of handing the entries, nor does it flood the tables abruptly. This indicates that memory utilization is to optimum when the scalability is increased but, does not become unmanageable. Fig.9 also shows that memory requirement to manage max flow table entries is almost double in 100 nodes scenario in comparison of 50 nodes scenario. Fig. 7. OpenFlow Messages From Controller for scenario one and two Similarly if we observe the Fig.7 showing OF messages from controller, the observation is the same. 100 nodes scenario seems to be highly versatile in comparison of 50 nodes scenario. The sudden high instances observed for to and from messages from controller graphs for scenario with 50 nodes may be because of the flow miss detected for other flows creating space for other flows. Fig. 8 shows flow misses to controller for both the scenarios. It was observed that top graph with 100 nodes shows the same behavior that was observed in Fig.6 for OF message to controller. Similarly, bottom graph with 50 nodes shows behavior same as Fig.6 bottom figure for OF msg to controller. Again, the reason is same, it s because few flows observe miss/drop which makes space for other flows keeping average flow to an average flow miss same. Fig. 9. Maximum Flow Table Enties for scenario one and two Fig. 10. Average Round Trip Time (RTT) for scenario one and two 560

5 Fig. 10 shows the Avg RTT in msec. For first few seconds when the traffic is getting settled in the provided network resources, RTT is small. But, when all the flows are actively communicating using the resources optimally, may result in congestion bringing the value of RTT high. Because of this reason, we can observe very few instances of large RTT which may end up in drops. On an average, RTT stays small confirming the assured high delivery ratio for both the scenarios. Fig. 11 shows CPU Utilization for both the scenarios which was observed to be same and small indicating that the simulator does not eat the complete processing resources and proves itself to be light enough to handle which is an highly appreciable feature of OFNet. It was observed that range of CPU utilization stays between 20% and 40% throughout the simulation run proves that resource utilization does not need complex computations with optimum memory resources utilization. Fig. 11. CPU Utilization for scenario one and two VI. CONCLUSION & FUTURE SCOPE: With this paper, authors have made attempt to address the scalability features of the Floodlight controller by implementing two scenarios in simulation experimental environment over OFNet. In this paper, authors have provided the clear idea how to create experimental test bed with analysis of obtained statistical results keeping the performance as the central focus. We would conclude this paper by providing additional option of the implementation of SDN in simulation and emulation environment to inspire researchers to ideate and practically implement their ideas in the form of simulations to come up with contributions pushing the technology ahead. In this paper, we implemented Floodlight Controller using OFNet on two scenarios which shows step by step experimental setup that can be followed to implement their own experiments with ease. This paper may be used as guidance to new researchers in the domain of SDN willing to explore Floodlight and OFNet. Not just, experimentation, analysis provided in this experiment with lot of reasoning provides the logic behind every action during the experimentation and reasons for the results. Further, the research team will come up with few more papers on implementation of other SDN controllers in the coming future. The team also has planned to compare the controllers of SDN, once all the stellar controllers are implemented and experimented by them. REFERENCES [1] Gowsami, B. Asadollahi, S., (2016). Novel Approach to Improvise Congestion Control over Vehicular Ad Hoc Networks (VANET) Proceedings of the 10th INDIACom; International Conference on Computing for Sustainable Global Development, March Delhi, India. IEEE Xplore ISBN: [2] Asadollahi, S., Gowsami, B. (2017). Revolution in Existing Network under the Influence of Software Defined Network. Proceedings of the INDIACom 11th, Delhi, March IEEE Conference ID: [3] McKeown et al, N. (2008). OpenFlow: Enabling innovation in campus networks. ACM SIGCOMM - Computer Communication Revie, vol. 38, no. 2, p [4] Smith et al, M. (2014). OpFlex control protocol, Internet Engineering Task Force, from : [5] Doria et al, A. (2010). Forwarding and control element separation (ForCES) protocol specification. Internet Engineering Task Forc, from [6] Enns, R., Bjorklund, M., Schoenwaelder, J., Bierman, A. (2011). Network configuration protocol (NETCONF). Internet Engineering Task Forc, form [7] Song, H. (2013). Protocol-oblivious forwarding: Unleash the power of SDN through a future-proof forwarding plane. Proceedings of ACM SIGCOMM Workshop Hot Topics Softw Defined Netw II. p [8] Asadollahi, S., Gowsami, B. (2017). Implementation of SDN using OpenDaylight Controller. Proceeding of An International Conference on Recent Trends in IT Innovations - Tec'afe ISSN(Online) : [9] McCauley, M. (2012). POX, from [10] Erickson, D. (2013). The Beacon OpenFlow controller. Proceedings of ACM SIGCOMM Workshop Hot Topocs Software Defined Network II, p, [11] Gude al, N. (2008). NOX: Towards an operating system for networks. ACM SIGCOMM - Computer Communication Revie. vol. 38, no. 3, pp [12] Nippon Telegraph and Telephone Corporation, RYU network operating system, 2012, from [13] Project Floodlight, Floodlight. (2012). from [14] Asadollahi, S., Gowsami, B. (2017). Software Defined Network, Controller Comparison. Proceedings of Tec'afe 2017,Vol.5, Special Issue 2, April ISSN: [15] OFNet, from [16] Lantz, B. Heller, and N. McKeown. (2010). A network in a laptop: Rapid prototyping for software-defined network. Proceedings of ACM SIGCOMM Workshop Hot Topics Netw, 19th. p. 19:1 19:6 [17] B. Pfaff and B. Davie. (2013). The Open vswitch database management protocol. Internet Engineering Task Force, RFC 7047, from [18] Gowsami, B. Asadollahi, S., Performance evaluation of widely implemented congestion control algorithms over diversified networking situations Proceedings of International Conference on Computer Science Networks and Information Technology Held on 23rd-24th January 2016, Pattaya, Thailand. 561