1
Short: A case study of the performance of an OpenFlow Controller Fouad Benamrane, Mouad Ben Mamoun, and Redouane Benaini LRI, Faculty of Sciences of Rabat, Mohammed V University, Rabat, Morocco. Email:
[email protected], ben mamoun,
[email protected]
Abstract— Over the last four years there has been significant growth in the interest that researchers and IT industry have shown in a new network architecture approach called SoftwareDefined Networking (SDN). This new approach is based on the separation between the control plane (routing decisions) and the data plane (packet forwarding). Communication between these two planes is mainly established today by the OpenFlow protocol. The interest of SDN is that it allows network programmability through applications acting on the control plane and hence it facilitates the development of new network protocols and services. However, there are some problems of performance and scalability when a single centralized controller is deployed in an SDN architecture. In this paper, we briefly introduce SDN, OpenFlow and review performance studies. After, we study through some experiments the performance issues of the Ruy OpenFlow controller especially in a large-scale network case. Index Terms— Software-Defined Networks; OpenFlow; Performance; Scalability.
I. I NTRODUCTION The Internet has become a universal digital infrastructure essential for billions of people. Nevertheless, its architecture has some weaknesses in security, quality of service and performance and must cope with new needs due to the continuous increase in traffic and changing uses. However, because of the enormous installation of equipments and difficulty of testing new protocols in operational networks, this infrastructure has remained static and no significant progress has been made on its fundamental architecture in nearly three decades. The initial objective of the “Software Defined Networks (SDN)” approach that has recently emerged is to solve this problem and open network infrastructure for innovation. The idea is to allow researchers to run experimental code on programmable switches and routers that could handle packets from the experimental traffic without disrupting the operation of the production network [1]. After the emergence of SDN, several recent work has shown that this approach is suitable for applications in various environments such as distributed data centers, wireless networks and enterprise networks [2], [3]. In SDN architecture, the control plane is supported by centralized software application called a controller and the switches becomes simple packet forwarding devices. This architecture raises the problem of controller performance and its capacity to handle all the network devices, especially for large and highly distributed networks. In this paper, we try to contribute to the efforts of analyzing performances of SDN controllers by studying the performances of Ryu OpenFlow controller [4] through some
experiments. The paper is organized as follows: Section II is devoted to some works on performances of OpenFlow controllers. Section III presents the used tools and scenarios of the experiments. Simulation results are given in section IV. Finally, we give some conclusions in section V. II. R ELATED WORKS The OpenFlow protocol is an open source protocol normalized by the Open Networking Foundation (ONF) [5], it specifies how a software controller and a switch should communicate in an SDN architecture. Openflow allows users to implement rules into switches flow tables. The communication between the flow table and the remote controller will be established through Secure Shell (SSH), using the OpenFlow protocol agent to exchange messages and configuration management with the switch. Currently, there are several available OpenFlow controllers, for example, Floodlight [6], NOX [7] and Ryu [4]. The differences between these controllers relies on programming language, performances and application domain. As SDN is a new technology, the performance issue is not yet sufficiently studied. We mention here some works that are interested in this problem. In [8], the authors present a study of SDN controller performance using some publiclyavailable OpenFlow controllers. They show that the problem of performances is not an intrinsic limitation of the SDN control plane, but of the available controllers which are not optimized for performance. To prove this, they propose a multi-threaded controller called NOX-MT (a new release of the NOX controller) that improves the performance of NOX by more than 30 times. In [9], the authors consider the FloodLight OpenFlow controller and show how the latency between an OpenFlow switch and its controller affect the performances of the whole network. The SDN fundamental concept is to centralize the control plane through a single controller, but thereafter researchers suggest to deploy multiple controllers to manage different components of the network. In [10], the authors studied the impact of the number of controllers to deploy and their placement on performances. They conclude that there are no placement rules that applies to every network and that the controllers number depends on the network topology and the metric choice. The mentioned works and also other studies show that there are many facets
2
with Controller
OpenFlow Controller
w/o Controller
Multiple instances
5000
OVS-Edge
OVS-2
OVS-Edge
Time delay (ms)
4000 3000 2000 1000 0 20
40
60
80
100
Nodes
Figure 1. Linear OVS topology
to analyze the performances of a network based on SDN approach. In the next two sections, we consider the Ryu OpenFlow controller and perform some experiments to evaluate its scalability.
Figure 2. Time delay variation according to the OVS nodes number of different scenarios
time the controller receives a packet, hence the measured time is already the sum of all delays. In the next section, we give results of both scenarios. IV. S IMULATION RESULTS
III. S TUDY DESCRIPTION In this section, we give a description of our testbed, we specify the hardware configuration and the different tools used in our experiments. To emulate an SDN platform, we must have an SDN controller, an SDN software switch and an SDN emulation tool. In our testbed, we use the Ryu OpenFlow controller [4], which is based on python language and provides software components with well defined API. We also use a programmable switch called Open Vswich (OVS) [11], and the Mininet emulation environment [12], developed by Stanford University. We note that all the results shown in the next section depend on the lab device 1 used to conduct the experiment. The goal of this study is to analyze the scalability issue. For this, we consider a basic network topology as shown in (Fig.1), we vary the number of nodes and measure the network delay. We consider two scenarios with and without (w/o) centralized controller to clearly see the impact of the controller. In the first case, every packet sent to an unknown address will be delivered to the controller to decide what to do with it. The other case (w/o) corresponds to a proactive technique where we pre-populates the flow table in each switch before receiving the first packets from the data plane. In fact, the second scenario can be viewed as the limit case (for the first scenario) when the controller is never solicited. Hence, the delay difference between the two scenarios gives an idea about the delay caused by the solicitation of the controller. In both cases, we generate an ICMP messages (Ping) and measure the time delay between the two edges. In the case without controller, this time is the sum of the traditional packet-network latency to which will be added flow setup time, the necessary time to insert the appropriate rules in each OVS flow table. In the other case, the flow setup time is added each 1 All senarios run in Ubuntu 12.04.3 LTS 3.2.0-57-generic-pae i686 , gcc 4.8, Boost 1.46.1, Sun Java 1.6.0.27,Core(TM)2 Duo CPU, 2.00GHz. Ryu (v.3.2), Mininet (v.2.0) and Open vSwitch 2.0.90
There are various performance metrics to quantify for an SDN controller. We focus here on the latency metric (delay to respond to data path requests), which have an impact on the network time delay. Figure (2) gives this delay according to the OVS nodes number. We can observe that until 60 nodes, the delay difference between the two scenarios (with and w/o) is very low and becomes more important as the number of nodes increases. In fact, when the network size increases, the controller becomes much solicited and could not handle all the requests within a reasonable time. For example, in the case of 100 nodes, the time delay is equal to 4s, while it’s less than 2s in the scenario without controller. We can also observe that up to 60 nodes, the delay is less than or nearly equal to a second, even in the case with controller. So, we can benefit from simplicity management of a centralized controller and a reasonable time delay. Obviously, the threshold of 60 nodes depends on this case study and may change according to the lab device and the considered topology. From this experiment, we can deduce that one controller can handle a reasonable number of switches such as a network of small and medium enterprise, but it could not handle a large-scale network. To investigate more the performances of one centralized controller, we propose to apply the multiple instances technique that is widely used in today’s complex systems with virtualization technologies. In the previous experiment, the network is managed by only one instance of the controller. The exchanged messages (Packet In, Packet Out et Flow mod) are on only one port (by default 6633), which can cause an overload on the controller in larger networks. In the multiple instances scenario, each instance manages a small part of the network and communicates with the nodes on a unique port. In figure 2, we consider the case of 4 instances. We can observe that the time delay decreases in comparison of the single instance case. Therefore, this technique alleviates the problem of scalability. However, we think that it is not sufficient to solve the problem.
3
V. C ONCLUSION SDN is undoubtedly one of the important trends in networking area. A large networking community in industry and academia is interested and works on different aspects of this topic. In this paper, we investigated the performance issue and focused especially on scalability. The results of our experiments confirm that effectively scalability may be an issue and a single centralized controller could not handle a large size network. The multiple instances technique may help to reduce the effect of the scalability limitation. However, we think that the real solution is to have several controllers and to design new protocols to communicate between controllers. We note that this idea has been already proposed in some works, but there is no protocol that was developed and tested yet in the best of our knowledge. R EFERENCES [1] Casado, M., Freedman, M.J., Pettit, J., Luo, J., McKeown, N., Shenker, S.: Ethane: Taking control of the enterprise. In: ACM SIGCOMM Computer Communication Review. Volume 37. (2007) 1–12 [2] Wang, R., Butnariu, D., Rexford, J.: OpenFlow-based server load balancing gone wild. In: Proceedings of the 11th USENIX conference on Hot topics in management of internet, cloud, and enterprise networks and services, USENIX Association (2011) 12–12 [3] Bansal, M., Mehlman, J., Katti, S., Levis, P.: Openradio: a programmable wireless dataplane. In: Proceedings of the first workshop on Hot topics in software defined networks, ACM (2012) 109–114 [4] : Ryu SDN framework. http://osrg.github.io/ryu [5] : Open networking foundation. https://www.opennetworking.org/ [6] : Floodlight OpenFlow controller. http://floodlight.openflowhub.org/ [7] : Nox open controller. http://www.noxrepo.org/ [8] Tootoonchian, A., Gorbunov, S., Ganjali, Y., Casado, M., Sherwood, R.: On controller performance in software-defined networks. In: USENIX Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (HotICE). (2012) [9] Phemius, K., Thales, M.B.: OpenFlow: why latency does matter. In: Integrated Network Management (IM 2013), 2013 IFIP/IEEE International Symposium on. (2013) 680–683 [10] Heller, B., Sherwood, R., McKeown, N.: The controller placement problem. In: Proceedings of the first workshop on Hot topics in software defined networks. (2012) 7–12 [11] : Open vswitch. http://openvswitch.org/ [12] Lantz, B., Heller, B., McKeown, N.: A network in a laptop: rapid prototyping for software-defined networks. In: Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks. 19
