AN ABSTRACT OF THESIS OF
Sara Alhamar for the degree of Master of Science in Computer Science presented on June 12, 2018.
Title: The Impact of Network Topology on Software Defined Network Performance.
Abstract Approved: ___________________________________________ Bechir Hamdaoui
Software Defined Network (SDN) is a new networking concept in which the data plane is decoupled from the control plane. Due to the huge demand on network resources and the rapidly increasing numbers of devices needing to be connected to the network, SDN paradigm has emerged as a potential solution for managing and solving such issues. However, SDN still faces many challenges when it comes to its achievable network performance in terms of delay, packet dropped rate, throughput, and other metrics. This thesis studies the impact of SDN topologies on network performances such as end-to-end latency, control packet overhead, and flow setup failure rate. Understanding the nature of each topology and how it is affecting the SDN performance help us make appropriate network design decisions that can enhance SDN systems. In this thesis, we study the impact of the network topology on SDN performances, by simulating the network performance under three different topology scenarios and evaluating the average end-to-end latency, flow setup failure rates and Open Flow control message overhead that are achievable under each of these three scenarios.
©Copyright by Sara Alhamar June 12, 2018
All Rights Reserved
The Impact of Network Topology on Software Defined Network Performance by
Sara Alhamar
A THESIS
submitted to
Oregon State University
in partial fulfillment of the requirement for the
degree of
Master of Science
Presented June 12, 2018 Commencement June 2018
Master of Science thesis of Sara Alhamar presented on June 12, 2018. APROVED:
Major Professor, representing Computer Science
Director of the School of Electrical Engineering and Computer Science
Dean of the Graduate School
I understand that my thesis will become part of the permanent collection of Oregon State University libraries. My signature below authorizes release of my thesis to any reader upon request.
Sara Alhamar, Author
ACKNOWLEDGEMENT
I would first like to thank Allah for his generosity and graces; this accomplishment would not have been possible without his kindness. I would like to thank my husband for providing me with unfailing support and continuous encouragement through my years of study. I would like to thank my baby's smile after a tough day. I would like to thank my parents for their love and support, and for teaching me how I never back down.
I would like also to thank Dr. Bechir Hamdaoui for his supports, patience and guidance. Finally, I would like to thank my friends and colleagues for supporting me during my academic journey.
TABLE OF CONTENTS
Chapter 1: Introduction ... 1
Chapter 2: Literature Review ... 6
Chapter 3: SDN and Topology Discovery Module ... 8
Chapter 4: Simulation Framework ... 12
4.1 Simulation Tool ... 12
4.2 Topology Setup ... 12
4.3 Traffic Setup ... 14
Chapter 5: Performance Evaluation ... 16
5.1 Performance Metrics ... 16
5.2 Performance Evaluation ... 17
Chapter 6: Conclusion ... 27
LIST OF FIGURES
Figure 1: Traditional Network Vs Software-Defined Network ... 2
Figure 2 SDN Architecture ... 3
Figure 3 How does SDN Work? ... 8
Figure 4 One Layer Topology ... 13
Figure 5 Two Layers Topology ... 13
Figure 6 Three Layers Topology ... 14
Figure 7 Average Failure Rate ... 18
Figure 8 average Latency / Second ... 19
Figure 9 Network Average Latency in 100 seconds ... 20
Figure 10 Average Number of Packet_In ... 22
Figure 11 Average Packet_In ... 23
Figure 12 Average Packet_Out ... 25
LIST OF TABLES
Table 1 SDN Controllers... 4 Table 2 Generated Traffic Type ... 15
Chapter 1: Introduction
Computer Networks are complex and hard to control by nature because of the different types of equipment and elements that they are composed of, starting from switches and routers, to middleboxes such as firewalls, to server load balancers and intrusion detection systems. What makes computer networks even more complicated is the fact that routers and switches need to be dynamic and adapt to network changes in real time. Routers and switches run complex and unopen distributed control software. Moreover, when it comes to controlling the network, network administrators monitor each network device using configuration interfaces that can be different from one vendor to the other. Albeit there are network management tools that provide a central view of the network, these tools are limited to specific protocols and configuration setups and they lack flexibility and efficiency. Such limitations restrict innovation in computer networks and increase the barrier to deploying new services [1]. As a result, Software-Defined Network (SDN) concept was introduced to bring flexibility and programmability features to computer networks. The basic idea behind SDN, which was first introduced in 1996 [2], is to decouple the control plane and the data plane from one another, which has traditionally been looked at as one layer. While the data plane is concerned with forwarding data across the network, the control plane is in charge of managing the forwarding behavior and rules across the network elements [3].
As shown in Figure 1, traditional networks couple the control plane and data plane in the switches, which are responsible for making forwarding decisions. On the contrary, the controller at the SDN is responsible for the control plane functionalities, such as forwarding decision, while the network switches are responsible for the forwarding plane functionalities, such as the forwarding of packets depending on the rules that were dictated by the controller [1]. Figure 2
shows typical SDN architecture. With SDN, the introduction of new features becomes less manual, less prone to error, and faster to implement [4]. Recent studies show the role of SDN in overcoming traditional network barriers. [5], [6], [7] and [8] employed the concept of SDN in enhancing the QoS of the network. For instance, the works of [9], [10], [11] and [12] leverage the programmability feature of SDN to reduce network energy consumption. Moreover, SDN concept can be
Control Plan Data Plan Control Plan Data Plan Control Plan Data Plan Switch Switch Switch
applied to network resource allocation problems like those proposed in [13], [14] and [15]. An SDN architecture consists of three different layers [16]: application layer, controller layer, and infrastructure layer. Figure 2 shows such an SDN architecture.
The application layer consists of SDN applications, which are programs that deliver network requirements and desired network behaviors to the SDN controller via North Bound Interface [17]. Application layer [12] consists also of network virtualization, network monitoring, intrusion detection and flow balancing systems.
Application /Services NW Device NW Device NW Device NW Device Controller Application Layer Control Layer Controller Controller Infrastructure Layer
Southbound API (e.g. , OpenFlow) Northbound API
The controller layer, on the other hand, consists of controllers that control the switches programmatically, manage network traffic, decide on forwarding rules and other management abilities. There exist different SDN controllers, including NOX [18], POX [19], Beacon [20], Floodlight [21] and OpenDayLight [22] . Each controller has different characteristics and is developed using different programming languages [23] as shown in Table 1.
Controller Language NOX C++ POX Python Beacon Java Floodlight Java OpenDayLight Java Table 1 SDN Controllers
Infrastructure layer includes all network hardware devices and cabling required to support the network, such as switches and routers. Different types of switches can be included in SDN. The widely used one is OpenFlow switch. OpenFlow is the most popular communication protocol in SDN. Any device in OpenFlow environment that wants to communicate to an SDN controller must support the OpenFlow protocol. The original concept for OpenFlow begun at Stanford University in 2008. By December 2009, Version 1.0 of the OpenFlow switch specification was released [35]. However, SDN faces a set of challenges such as network scalability, fault tolerance, and reliability. While the idea behind SDN is to help the network management process, it will always be a bottleneck in exchanging large volume of data [24]. Moreover, due to the centralized
nature of control functions, SDN can incur excessive overhead as the number of users increases, which leads to other network performance problems such as increased latency and packet dropped rate. Though there could be multiple various factors that impact such performances, the focus of this thesis is on studying the impact of the SDN topology.
The rest of this thesis is structured as follows: Literature Review is presented in Chapter 2. In Chapter 3, we give a brief background about SDN. In Chapter 4, we explain the impact of network topology on SDN. In Chapter 5, we present our simulation framework and performance analysis. Finally, we conclude our thesis in Chapter 6, followed by the future work in Chapter 7.
Chapter 2: Literature Review
This section sheds some light on related works of studying the impact of switch topology on SDN. In [2], the performance characteristics of flow table update in Open Flow switch was measured, reported and explained. Sood et al. [25] studied the performance of SDN switches using M/Geo/1 queuing theory modeling. They found that that the decisive factors of switch’s mean response time are: packet arrival rate, number of flow-table entries, and position of the targeting rule by a corresponding packet. [26] addressed the issue of topology discovery module in SDN, analyzed the overhead of OpenFlow Discovery Protocol in terms of controller load, and proposed and implemented an improved version. [27] proposed a centralized topology discovery methodology taking advantage of existing protocols already running on the SDN control and forwarding plane. The relation between SDN controller and certain topologies was discussed in [28]. It was shown that not only does the network topology have an impact on SDN performance, but so does the SDN controller. [29] presented a new novel cost-effective method to make the SDN topology discovery process fully automated. This new method was experimentally validated with two different topology scenarios, and it was shown that it reduces the time of network topology discovery. Finally, in [3] the impact of network topology on the processing time of SDN controller was investigated. After the investigation, from the initial observation it was found that the number of
switches has an influence on the controller processing time. However, after testing 261 topologies from the Topology Zoo, the final conclusion [3] that was drawn is that no correlation between the processing time of the controller and the number of switches was found.
Chapter 3: SDN and Topology Discovery Module
Software Defined Network (SDN) is a new networking design paradigm, where the control plane is decoupled from the forwarding plane. SDN uses logically centralized controllers that are responsible for directing the forwarding decision to the connected switches [1].
The idea behind Open Flow (OF) switches is simple [30]. In contrary of Ethernet switches which contain static flow-table, OF provides an open protocol that offers flexibility to program flow tables with network administrators being able to partition traffic and assign flow priorities. Moreover, network administrators, using SDN controller, can reroute the packets depending on SDN applications, such as Intrusion detection programs. An OF switch consists of at least three parts [30].
Flow table, with as action associated with each flow entry, to tell the switch how to process the flow. A secure channel that connects the switch to the controller to allow commands and packets to be sent between the controller and the switches. The OF protocol provides an open and standard way for the controller to communicate with the switches [30]. The flow table in the switch had different tuple along with the action tuple. The first tuple is matching criteria as IP source, IP destination and protocol where the incoming packets are matched with these criteria and the action is performed depending on the associated action. Priority tuple assign plays a role on prioritizing the action when packet criteria are matched with two different actions. Hard to tuple specifies how long a forwarding rule can be stored in the flow table before it is removed, while Idle To tuple specifies how long a rule in the flow table can stay in idle mode. Once the network is initialized and triggered with traffic, a traffic packet will reach the switch. The flow table in the switch is initially empty and has no rules. As illustrated earlier, OF switches are dummy and can’t forward the packet without requesting the controller to send a rule. Hence, the switch will send Packet_in messages to the controller. Then, the controller will consult some of its modules, such as topology discovery module, which is responsible for figuring out the network topology, and discover any new contacted link to the controller. Also, the controller may consult with the application layer on forwarding the packet. After the controller makes a decision, it will send a packet_out message to the switch with the forwarding rule to be
installed in the flow table. Then, the switch follows the rule in forwarding the packet, and the switch will not contact the controller again regarding the same rule as long as it is installed in the flow table and it is not removed due to Handle or Idle time. The actions of each rule can for example be ‘out:1’ which means forward the packet from port 1. In some circumstances, the action could be ‘drop packet’ or ‘send to controller’. Moreover, the controller can send a flow modification rule to modify a previously installed rule in the flow table without the request from the switch. Adopting SDN paradigm brings network flexibility, dynamicity and reduces network operational complexity [2]. Moreover, SDN can allow to test new research ideas and networking approach such as network management, protocol design, security models, addressing schemes, and even alternatives to IP. On the same network, the production traffic is isolated and processed in the same way as today [31]. SDN controller is in charge of managing the network and providing network services, such as routing. To do so, the controller should be updated with network statues and be aware of network topology. Any newly connected switch to SDN will initiate a connection to the controller informing it about the switch occurrence. However, it is not switches’ responsibility to discover the network topology; it is controller’s responsibility. As a result, most current controllers have topology discovery mechanisms implemented in them [36]. To discover the unidirectional link between S1 and S2, the controller encapsulates a link layer discovery protocol (LLDP) packet, in a packet_out message and sends it to S1. The
packet_out contains instruction for S1 to send the LLDP packet to S2 via port P1. By receiving the LLDP packet via port P2, S2 encapsulates it in a packet_in message and sends it back to the controller. Finally, the controller receives the LLDP packet and concludes that there is a unidirectional link from S1 to S2. The same process is performed to discover the link in the opposite direction, between S2 and S1 as well as for all other switches in the network. In highly dynamic network, keeping to-date view of the topology is a critical function. To stay up-to-date, the controller needs to repeat this process periodically [36]. Discovery period must be chosen carefully based on the dynamicity, size and capacity of the network. An inefficient, vulnerable topology discovery can affect network performance. By using OFDP, the controller periodically sends multiple packets to every switch in the network, which could result in a performance decrease of the data plane. Increasing controllers' CPU usage may not reliably work for heavily loaded links, because discovery packets might get dropped or delayed [36].
Chapter 4: Simulation Framework
In this section, we provide detailed simulation framework and performance evaluation. We first describe the simulation setup, then present performance metrics. In the last section, we briefly analyze our obtained results.
4.1 Simulation Tool
In order to test the performance of different SDN topologies, we used OFNet. OFNet is an Open Flow Network emulation. OFNet provides interesting features like visual debugging of control plane transactions, traffic generation on emulated network and helps in characterizing performance of an SDN controller [32]
4.2 Topology Setup
We first start by implementing three different topologies scenarios. The first scenario is a one-layer, flat network topology consisting of 16 connected switches and 512 hosts. All switches are connected to each other and connected to the controller, and there are 32 hosts connected to each switch. The connection between the switches and the controller serves to exchange OF Messages only, while the connection between the hosts and the switches serves to exchange traffic packets. The first scenario is shown in Figure 4. The second scenario is two-layer tree network topology consisting of 18 connected switches and 512 hosts. Two switches located at the first layer, while the remaining ones are located at the second layer. Each switch at the second layer is connected to 32 hosts and all the topology switches are connected with the controller to exchange OF messages. Figure 5
shows the second scenario. The third scenario is three layers of switches, with 22 switches in total and 512 hosts. The first layer has two switches, the second layer has four switches and the third layer has 16 switches. Each switch at the third layer is connected with 32 hosts. All the switches are connected to the controller to exchange OF messages. Third scenario is shown in Figure 6.
Figure 4 One Layer Topology
Figure 6 Three Layers Topology
4.3 Traffic Setup
After we set up the topology, we start generating the network traffic using the traffic generator module in OFNet. Traffic generator module in OFNet generates N flows per second in total; that with M hosts in the network, each host ends up generating N/M flows on average. The traffic generator module supports 8 different types of flows, which are shown in Table 1.
Traff ic Num
ber
Traffic Type How the traffic is generated Who send to whom 1 Web Traffic wget --timeout=2 -q www.google.com From host to
google.com 2 DNS Traffic netperf -H %s -t UDP_RR -l -1 -- -r 128,128 From host to
DNS server 3 NFS Traffic netperf -H %s -t UDP_STREAM -l -100000 From host to
NFS server 4 Large send Traffic netperf -H %s -t TCP_STREAM -l -2000000 From host to
random host 5 FTP Traffic netperf -H %s -t TCP_STREAM -l -500000 From host to random host 6 Talent Traffic netperf -H %s -t TCP_RR -l -100 -- -r 1,1 From host to random host
7 Ping Traffic ping -c 1 %s From host to random host
8 Multicast Traffic %smcast_server %s From host to Multicast server Table 2 Generated Traffic Type
Now each host needs to generate a mix of N/M flows. Suppose each host generates different traffic types (web/dns/ftp etc) and let the number of traffic types supported by the module be p; that is, the traffic types can be labeled as t1,t2..tp. Now N/M flows generated by each host are divided among traffic types, t1,t2,...tp. Let the percentage of traffic type 'ti' be pi% (0 < i < p). Then the rate of traffic of type 'ti' generated by the host is (pi/100 * N/M) per second, and the average inter-arrival time of traffic 'ti' is 100/(pi * N/M) [32].
Chapter 5: Performance Evaluation
5.1 Performance Metrics
A. Failure rate
Due to the high numbers of traffic flows in the network and hence the high demand on the controller to process such flows, some flows could be dropped. One of the performance metric to assess is then the rate of dropped flows or dropped flow rate in flows/sec. In this study, we run the simulation 10 times, each with 100 seconds of generated traffic. The dropped flow rates are then averaged over the 10 runs. We do the same for all three scenarios.
B. Average Latency
As all the flows are being supported by the network during the course of the simulation time, two random hosts i, j are chosen every 10 seconds to measure their end-to-end latency. The latency is measured by having host i ping host j. Ten different hosts are chosen over 100 seconds of simulation time to ensure that we get the average latency among 10 different hosts/simulation. The simulation is repeated 10 times; hence we will get the average among 100 hosts.
C. Packet – In
While N flows/sec are being supported by the network and the network runs for 100 seconds, one random switch is chosen and then ‘snoop’ command is used to measure the number of ‘packet-in’ packets generated from the random switch. Snoop is an OpenFlow switch command that can be used to assigned switch and
print all OpenFlow messages [33]. After that, the OpenFlow messages are sorted as packet-in messages and are then counted. This snooping process is repeated every 10 seconds over 100 seconds of generated traffic, so we get a number of packet-in packets in every 10 seconds. The simulation is repeated 10 times; hence we get number of packet_in from 100 different switches.
D. Packet _Out
While N flows/sec are being supported by the network and the network runs for 100 seconds, one random switch is chosen and then ‘snoop’ command is used to measure the number of ‘packet-out’ packets generated from the random switch. After that, the OpenFlow messages are sorted as packet-out messages, counted and multiplied by the number of switches in the network. This snooping process is repeated every 10 seconds over 100 seconds of generated traffic, so we get the number of packet_out packets in every 10 seconds. The simulation is repeated 10 times; hence we get number of packet_out from 100 different switches.
5.2 Performance Evaluation A. Failure rate
A switch will drop a packet when the switch doesn’t know where to forward the packet [34]. In SDN, all the switches are learning switches and they all request the controller for a forwarding rule. In some point in the network, especially when the load is high, the controller will be overwhelmed with requests from all switches in
the network. As a result, some requests will be queued. When the queue is full, the incoming request will be dropped. As result, the switch didn’t get any information about how to forward the packet, and hence the packet is dropped. From the results obtained from the simulation, we found that the one-layer switch topology has the highest failure rates due to the flat topology where all the switches are connected to each other and all share the same link. All the switches are also responsible for forwarding the network packets, which generate more load on each switch. Our
insight is as follows: In SDN, when the controller is overwhelmed, it is likely that packets coming from the switches are dropped, leading to increased flow failure rates. This study suggests that clustered topologies be used to decrease flow failure rates.
B. Average Latency
In SDN, a switch can’t forward any packet without requesting the controller for a forwarding rule, unless such a rule is stored in the switch flow table. Latency is how long a packet will take before it reaches the final destination. Any packet coming from any host to the switch has to wait for the switch that is also waiting for the controller to respond. To find the average latency, we send one ping message between two random hosts in the network every 10 seconds over 100 seconds of
generated traffic. Figure 8 shows the average latency over 100 seconds of network traffic. One-layer topology intends to be the topology who causes the highest latency rate due to the way of connecting the switches and sharing the same link. In contrary of one-layer topology, two layers and three layers topologies adopted
the clustering concept where one switch is the cluster command switch, and all other connected switches are clustering members [35]. Clustering helps in reducing the network latency as shown in Figure 9. From the obtained results, we found that two-layer topology causes the lowest average latency among all topologies. Moreover, we found that one-layer topology causes the highest average latency compared to two and three layers. One-layer topology shares the same link. If h1 sends to h512, the packet goes through 16 switches, from S0 to S15. Moreover, if h1 sends to h256, the packet goes through 8 switches, from S0 to S7. Two-layer
topology adopts the clustering concept, which means that all switches are divided into two groups and each switch in the first group connects to one switch in second layer. If h1 sends to h512, the packet goes through 4 switches S2, S0, S1, S17. While the average Latency in three-layer topology is higher than two-layer topology, it is lower than one-layer topology. All switches are divided into four clusters, which is better than a sequence of connected switches as in the one layer case. In the three-layer topology, however, when h1 sends to h512, the packet goes through 6 switches S6, S2, S0, S1, S5,S21. While in two layers topology, when h1 sends to h512, the packet goes through 4 switches S2, S0,S1,S17. Back to one-layer topology, when h1 sends to h512, the packet goes through 15 switches, from S0 to S15 serially. Furthermore, as illustrated earlier, no packet can be processed without the controller consultation, unless its forwarding rule is available in the switch flow table. From the results, we have seen that, beside the latency caused due to the switch topology, packets are delayed because they are waiting for the controller that is busy processing all packets in the network. Our insight is as follows: In SDN, high levels of latency are highly expected due to the centralized controller. This study suggests employing a topology that does not increase SDN 's latency because of the topology design.
C. Packet_in
Packet_in is a OpenFlow request message from the switch to the controller asking for a forwarding rule to be installed in the flow table. Packet_In will be sent for
every incoming traffic with unknown rule. In Figure 10, we can see that the number of Packet_In reaches the highest level at the beginning of the network traffic,
because all the flow tables in the switches are empty. Then, as the forwarding rules are being stored in the flow table, the number of Packet_In starts to decrease until no more packets are generated.
On average, as shown in Figure 11, one-layer topology with the lowest number of switches led to a lower number of Packet_In. A higher number of Packet_In messages means that the controller will be overwhelmed, and its performance will be affected negatively which impact the overall performance of the network. There is always a trade-off between topologies in SDN. Every switch in SDN sends packet_in messages to the controller unless the forwarding rule is not installed or removed in the flow table.
Position of the switch has no impact on the number of packet_in messages. However, the number of switches affects the number of packet_in messages. A higher number of switches leads to higher numbers of packet_in messages in
SDN. In our simulated topologies, we ensure that all switches in the last layer are connected to the same number of hosts. So, we have 16 switches in one-layer topology. But we have 18 switches in two-one-layer topology, because this topology is the adopting clustering concept. However, we have 21 switches in three-layer topology, because this topology is adopting clustering concept, and needs three layers of switches. Hence, one-layer topology has the lowest number of packet_in messages, because it has the lowest number of switches. High numbers of packet_in messages overwhelm the controller and increase its CPU utilization, leading to other SDN performance issues like failure rate. Our insight is as follows: In SDN, a high number of switches leads to a high number of packet_in messages, which overwhelms the controller and causes performance issues. This study suggests, when it comes to controller utilization, to choose the lowest possible number of switches to maintain SDN performance.
D. Packet_out
The controller will send OpenFlow message to the switch called Packet_Out, which contains a forwarding rule to be installed in the flow table. However, the controller is not sending the Packet_Out to the required switch only, but it will send it to all switches in the network. Moreover, in some cases, such as SDN application request or the need to re-route a packet in the network, the controller will send a Flow Modification message - Flow_Mod - that modifies the entry
of a flow table without receiving a request from the switch. Flow_Mod is considered as Packet_Out message as well. Going back to Figure 11, we see that the average number of Packet_In reached 500 packets. Each Packet_In sent to the controller will get a Packet_Out on average unless the Packet_In was not dropped. In Figure 12, we can see that the average number of Packet_Out in
one-layer topology is higher than the number of Packet_In with 1000 packet. These 1000 Packet_Out packets are flow_mod packets. In the two-layer topology, we only got 50 packets as flow_mod. We can conclude that one-layer topology requires more flow modifications. When the controller sends a packet_out message as a reply to a packet_in message, the controller sends packet_out to all switches in the network. Packet_out is not just a reply to packet_in message, as it could be flow_mod message that is sent without a request from the switch. The total average number of packet_in and packet_out indicate the load of the controller.
From the obtained results we found that one-layer topology increases the controller load more than the other two topologies and incurs more flow modification.
However, two-layer topology puts lower load on the controller when compared to one-layer topolgy, but needs a modification higher than the three-layer topology. Three-layer topology comes second in increasing load on controller, but it needs lower flow modification than in other layers. Our insight is as follows: SDN controller load is critical with a high load leading to other network issues. Moreover, more flow modification messages from the controller increases the load on the controller and occupies bandwidth between controller and switches, which may lead to packet being dropped. This study finds that there is a trade-off between the controller load reduction and the number of modifying flows.
Chapter 6: Conclusion
In this thesis, we study the impact of network topology on SDN performance. Using OFNet, we experiment three different clustered SDN topologies with different numbers of layers. We evaluate end-to-end flow latency, flow failure rate, Packet_In and Packet_Out messages under each of the three studied topologies. We found that there is a trade-off between the topologies, depending on the priority of the network performance, and it is hard to generalize and identify the most effective topology for SDN. In SDN, when the controller is overwhelmed, it is likely that packets coming from the switches get dropped, leading to increased failure rates in the network. This study suggests to adopt clustered topologies to decrease failure rates. In SDN, high levels of latency are highly expected due to centralized controller. This study suggests to implement a topology that does not increase SDN's latency because of the topology design. In SDN, a high number of switches leads to a high number of packt_in messages, which can overwhelm the controller and cause performance degradation. This study suggests, when it comes to controller utilization, to choose the lowest possible number of switches to maintain good SDN performances. Moreover, the greater the number of flow modification messages sent to/from the controller, the greater the load on the controller and the higher the bandwidth needed between the controller and switches, which increases
the chances of packets being dropped. This study finds that there is a trade-off between the controller load reduction and the number of modifying flows.
Reference
[1] Nick Feamster, Jennifer Rexford, and Ellen Zegura. 2014. The road to SDN: an intellectual history of programmable networks. SIGCOMM Comput. Commun. Rev. 44, 2 (April 2014), 87-98. DOI: http://dx.doi.org/10.1145/2602204.2602219
[2] D. Turull, M. Hidell and P. Sjödin, "Performance evaluation of openflow controllers for network virtualization," 2014 IEEE 15th International Conference on High Performance Switching and Routing (HPSR), Vancouver, BC, 2014, pp. 50-56.
[3] C. Metter, S. Gebert, S. Lange, T. Zinner, P. Tran-Gia, and M. Jarschel, “Investigating the impact of network topology on the processing times of SDN controllers,” 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM), 2015.
[4] O. N. Summit, "SDN: TRANSFORMING NETWORKING TO ACCELERATE BUSINESS AGILITY," in opennetsummit, 2013. [Online]. Available: http://opennetsummit.org/archives/mar14/site/why-sdn.html. Accessed: Nov. 22, 2017.
[5] S. Peros, H. Janjua, S. Akkermans, W. Joosen and D. Hughes, "Dynamic QoS support for IoT backhaul networks through SDN," 2018 Third International Conference on Fog and Mobile Edge Computing (FMEC), Barcelona, Spain, 2018, pp. 187-192. doi: 10.1109/FMEC.2018.8364063
[6] S. E. Middleton and S. Modafferi, "Experiences monitoring and managing QoS using SDN on testbeds supporting different innovation stages," Proceedings of the 2015 1st IEEE Conference on Network Softwarization (NetSoft), London, 2015,
pp. 1-5.
[7] A. Raschellà, F. Bouhafs, G. C. Deepak and M. Mackay, "QoS aware radio access technology selection framework in heterogeneous networks using SDN," in Journal of Communications and Networks, vol. 19, no. 6, pp. 577-586, Dec. 2017.
[8] D. L. C. Dutra, M. Bagaa, T. Taleb and K. Samdanis, "Ensuring End-to-End QoS Based on Multi-Paths Routing Using SDN Technology," GLOBECOM 2017 - 2017 IEEE Global Communications Conference, Singapore, 2017, pp. 1-6. [9] R. Maaloul, R. Taktak, L. Chaari and B. Cousin, "Energy-Aware Routing in Carrier-Grade Ethernet using SDN Approach," in IEEE Transactions on Green Communications and Networking. doi: 10.1109/TGCN.2018.2832658
[10] N. Huin, M. Rifai, F. Giroire, D. L. Pacheco, G. Urvoy-Keller and J. Moulierac, "Bringing Energy Aware Routing closer to Reality with SDN Hybrid Networks," in IEEE Transactions on Green Communications and Networking. doi: 10.1109/TGCN.2018.2842123
[11] W. H. Liao and S. C. Kuai, "An Energy-Efficient SDN-Based Data Collection Strategy for Wireless Sensor Networks," 2017 IEEE 7th International Symposium on Cloud and Service Computing (SC2), Kanazawa, 2017, pp. 91-97.doi: 10.1109/SC2.2017.21
[12] W. H. Liao and S. C. Kuai, "An Energy-Efficient SDN-Based Data Collection Strategy for Wireless Sensor Networks," 2017 IEEE 7th International Symposium on Cloud and Service Computing (SC2), Kanazawa, 2017, pp. 91-97.doi: 10.1109/SC2.2017.21
[13] U. Zehra and M. A. Shah, "A survey on resource allocation in software defined networks (SDN)," 2017 23rd International Conference on Automation and Computing (ICAC), Huddersfield, 2017, pp. 1-6.
[14] Y. Zhao, Y. Chen, R. Jian and L. Yang, "A Resource Allocation Scheme for SDN-Based 5G Ultra-Dense Heterogeneous Networks," 2017 IEEE Globecom Workshops (GC Wkshps), Singapore, 2017, pp. 1-6.
[15] K. T. Bagci and M. Tekalp, "Dynamic Resource Allocation by Batch-Optimization for Value-Added Video Services over SDN," in IEEE Transactions on Multimedia
[16] S. Raghul, T. Subashri and K. R. Vimal, "Literature survey on traffic-based server load balancing using SDN and open flow," 2017 Fourth International Conference on Signal Processing, Communication and Networking (ICSCN), Chennai, 2017, pp. 1-6.
[17] “SDN Architecture Overview,” www.opennetworking.org, 12-Dec-2014.
[Online]. Available: https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/SDN-architecture-overview-1.0.pdf [18] https://github.com/noxrepo/nox [19] https://github.com/noxrepo/nox [20] http://yuba.stanford.edu/~derickso/docs/hotsdn15-erickson.pdf [21] http://www.projectfloodlight.org/floodlight/ [22] https://www.opendaylight.org
[23] M. Priyadarsini, P. Bera and R. Bhampal, "Performance analysis of software defined network controller architecture—A simulation based survey," 2017 International Conference on Wireless Communications, Signal Processing and Networking (WiSPNET), Chennai, 2017, pp. 1929-1935.
[24] Abdelaziz A, Fong AT, Gani A, Garba U, Khan S, Akhunzada A, et al. (2017) “Distributed controller clustering in software defined networks”. PLoS ONE 12(4): e0174715. https://doi.org/ 10.1371/journal.pone.0174715
[25] K. Sood, S. Yu, and Y. Xiang, “Performance Analysis of Software-Defined Network Switch Using $M/Geo/1$ Model,” IEEE Communications Letters, vol. 20, no. 12, pp. 2522–2525, 2016.
[26] G. Tarnaras, F. Athanasiou, and S. Denazis, “Efficient topology discovery algorithm for software-defined networks,” IET Networks, vol. 6, no. 6, pp. 157– 161, Jan. 2017.
[27] G. Tarnaras, F. Athanasiou, and S. Denazis, “Efficient topology discovery algorithm for software-defined networks,” IET Networks, vol. 6, no. 6, pp. 157– 161, Jan. 2017.
[28] G. H. Shankar, “OFNet,” OFNet - Quick User Guide. [Online]. Available: http://sdninsights.org/. [Accessed: 05-Jun-2018].
[29] R. Montero, F. Agraz, A. Pagès, J. Perelló and S. Spadaro, "Dynamic topology discovery in SDN-enabled Transparent Optical Networks," 2017 International Conference on Optical Network Design and Modeling (ONDM), Budapest, 2017, pp. 1-6.
[10] W. H. F. Aly, "A Novel Fault Tolerance Mechanism for Software Defined Networking," 2017 European Modelling Symposium (EMS), Manchester, United Kingdom, 2017, pp. 233-239.
[30] N. Mckeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow,” ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, p. 69, 2008.
[31] “What is SDN application (software-defined networking application)? -
Definition from WhatIs.com,” SearchSDN. [Online]. Available:
https://searchsdn.techtarget.com/definition/SDN-application-software-defined-networking-application. [Accessed: 01-Jun-2018].
[32] G. H. Shankar, “OFNet,” OFNet - Quick User Guide. [Online]. Available:
http://sdninsights.org/. [Accessed: 06-Jun-2018].
[34] Abdelaziz A, Fong AT, Gani A, Garba U, Khan S, et al.”Distributed controller clustering in software defined networks “ (2017) Distributed controller clustering in software defined networks. PLOS ONE 12(4): e0174715. https://doi.org/10.1371/journal.pone.0174715
[35] “Catalyst 3750-X and 3560-X Switch Software Configuration Guide, Release 12.2(55)SE,” Cisco, 07-Aug-2017. [Online]. Available: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/softwar e/release/12-2_55_se/configuration/guide/3750xscg.html. [Accessed: 05-Jun-2018].
[36] https://www.sdxcentral.com/sdn/definitions/what-is-openflow/
[37] A. Azzouni, N. T. Mai Trang, R. Boutaba and G. Pujolle, "Limitations of openflow topology discovery protocol," 2017 16th Annual Mediterranean Ad Hoc Networking Workshop (Med-Hoc-Net), Budva, 2017, pp. 1-3.
