Figure 1. SDN Architecture
Emerging trends such as cloud computing and big data have altered the requirements of future internet, for which low latency, extraordinary bandwidth and dynamic management are very significant. In order to adapt to the new needs, Software-Defined Networking (SDN) has been considered as one of the most favorable solutions. In SDN approach, centralized entities called "controllers" manages and controls the network via well-defined APIs (Application Program Interface). The forwarding layer has a set of clear and definite rules. Traffic passing through these switches is compared with these rules and a match-action method is applied to this traffic. However, with the ever growing demand of traffic, the need of more sophisticated, secure and high performance controllers has increased. Therefore, in this paper, the authors have presents performance (in latency, throughput perspective) and security evaluation for some of the most well-known controllers: Maestro, Floodlight, NOX, OpenMul, Beacon, OpenIRIS. The survey shows that OpenIRIS controller has the lowest latency, and the OpenMul controller shows the highest throughput. Whereas, security wise OpenIRIS is the least vulnerable controller.
Lately, SDN has become one of the most popular subjects in the ICT domain. The Open Networking Foundation (ONF) [1] is a non-profit consortium dedicated to expansion, standardization, and commercialization of SDN. ONF has provided the most explicit and well received definition of SDN as follows:
"The physical separation of the network control plane from the forwarding plane and where a control plane controls several devices".
The SDN controller uses the interface and arbitrates the control of network resources in a logically centralized manner. Also, it manages the distributed network resources and provides the abstracted view of the network resources for the SDN applications. The SDN application can customize and automate the operations (including management) of the abstracted.
Normally routers, switches or any other network devices have three planes. The bottom plane is the forwarding plane for the job of forwarding the data; hence it is called the traffic-carrying plane. Secondly, we have the control layer, which is responsible of all the intelligence in the network and the decision making on where to route the traffic. Third one is management plane. The idea of SDN represented in Figure 1, is to decouple first two planes and to transform the traditional static network into a responsive, programmable, intelligent one that can be centralized controlled [2]. This all can be done in logical manners that will respond according to the traffic patterns, types or even emergencies.
Figure 1. SDN Architecture
An SDN Controller in a Software-Defined Network (SDN) is the "brains" of the network. It is the strategic control point in the SDN network, relaying information to the switches/routers 'below' (via southbound APIs) and the applications and business logic 'above' (via northbound APIs). The controllers in SDN architecture have two modes of operation, proactive and reactive. In the proactive approach, rules are already installed in the switches. In this approach, the performance and scalability become better. The reactive approach takes a considerable time while installing rules. In the reactive approach, packets of each new flow coming to switch are forwarded to the controller to decide how to manage the flow. Evaluation for both approaches has been done in [3]. In some papers [4]-[7] a hybrid approach has been presented to gain the benefits of both approaches. In this paper, the authors have surveyed the number of controllers that runs in reactive mode.
SDN community has been witnessing the expansion of numerous controllers written in multiple programming languages such as C, C++, Java, JavaScript, Ruby and Python as shown in Table 1 and Table 2. In the next few paragraphs, the authors have given basic introduction of the controllers which are under consideration.
Table 1. Controller Implementations and Characteristics
Table 2. Summary and Characterization of Controllers
Maestro is designed in a way that requires as little effort from programmers as possible to manage the parallelization. Instead, it handles most of the tiresome and complicated job of managing workload distribution and worker threads scheduling. Maestro was created at Rice University and it is represented as "Operating System (OS)" for orchestrating network control application. Since, Maestro platform and the components were created in Java, it can provide extraordinary portability to numerous OS. Furthermore, it provides high scalability, since it takes full advantage of multi-core processors systems.
The Floodlight open source SDN controller is written in Java language. It is a cross-platform controller and it is considered as one of the best OpenFlow controllers. It is considered as a rather easy to use, build and run. Due to all these reasons, it is a popular option for engineers starting to learn and test an OpenFlow. It has been designed to scale and to manage the growing number of OpenFlow enabled switches, wireless access points, routers and virtual switches.
NOX is an open source software, OpenFlow controller that was written in C++ programming language. In the beginning, it was created at Nicira Networks along with Open Flow. NOX was the first Open Flow controller, and it was donated to the research community in 2008. NOX aims to provide a platform which allow developers and researchers the ability to innovate in the form of developing novel applications. Applications on NOX control how each flow is routed in the network. Learning switch and topology discovery are some of the main reason of NOX use in the industry.
OpenMul, is an OpenFlow (SDN) controller [8] written in C programing language which is known for its high performance and low CPU resource requirements. OpenMul is an open source, since it is under the GPLv2 license, which encourages getting involved in its expansion. Also, it is most known for modular application hosting capability, consistency, and great performance.
Beacon is an OpenFlow controller that is created using Java programing language and since Java is known as cross-platform language or Write-once-run-anywhere, it can run on many platforms. Beacon code can be started/stopped/refreshed/installed at runtime. It is very much possible to replace the running Learning Switch application without disconnecting any connected switches. It has been in expansion for four years; since its expansion started in early 2010 and also it has been used in several research projects and trial deployments.
Open IRIS is an open source version of IRIS OpenFlow controller [9]. Java language is used for its expansion with a vision, that led to create a SDN controller platform with high scalability to accommodate carrier-grade networks. Moreover, it can provide high availability via transparent fail over solution. It includes three controller implementations. Open IRIS is an open source controller where it uses Apache-2.0 license for its licensing policy. IRIS supports a multi-domain and recursive network abstraction based on OpenFlow.
Figures 2-7 show the throughput of the controllers under discussion. The vertical axis shows the flow setup throughput in flows/sec, whereas, the horizontal axis shows the number of switches. The numbers of switches are gradually increased. The number of switches eventually reaches from 1 to 128. The results are as shown in Figures 2-7.
Figure 2. Beacon Throughput [10]
Figure 3. Floodlight Throughput [10]
Figure 4. OpenMul Throughput [10]
Figure 5. OpenIRIS Throughput [10]
Figure 6. NOX Throughput [10]
Figure 7. Maestro Throughput [10]
In Figures 8-13, the authors have shown the latency of the controllers under discussion. On the vertical axis, the authors have shown flow setup latency in micro-seconds, whereas, the horizontal axis shows the number of switches. The numbers of switches are gradually increased. The number of switches eventually reaches from 1 to 128. The results are as shown in the Figures 8-13.
Figure 8. Beacon Latency [10]
Figure 9. Floodlight Latency [10]
Figure 10. OpenMul Latency [10]
Figure 11. OpenIRIS Latency [10]
Figure 12. NOX Latency [10]
Figure 13. Maestro Latency [10]
From the above results, the lowest throughput was shown by NOX and Floodlight controllers with approximately throughput of 900,000 flows/sec. The Beacon controller which was considered by many pervious works [5], [9] and [8] as having the highest throughput, has been dominated as compared to releases of OpenMul controllers, while NOX throughput decreases severely on 128 switches. This indicates that NOX controller is not suitable for large scale networks. The average flow setup latency time can be effected as more workload was added. Due to the distribution algorithm for that controller, Maestro controller showed the highest latency among other controllers and it decreases by the increase in the number of switches, while OpenIRIS controller have the lowest latency value with approximately 5μs per flow.
Empirical studies describe the relative ease of beginning attacks against some commonly used SDN controllers- Beacon, Floodlight, OpenIRIS, OpenMul, NOX, Maestro. These studies indicate that the above mentioned controllers are vulnerable and can be easily exploited. Some of the common attacks to SDN are shown in Table 3. A Few security threats in context of SDN planes are shown in Table 4. Some of the well-known attacks are defined below.
Table 3. Common attacks to SDN
Table 4. Security Threats in Context of SDN Planes
ARP (Address Resolution Protocol) poisoning can fool the controller into installing malicious flow rules to divert traffic flows. A malicious user can possibly eavesdrop and intercept traffic intended for another host. These ARP requests are transmitted as PACKET_IN messages to the controller, and eventually corrupt target's ARP cache along with the controller's view of the entire topology.
In fake topologies attack a single malicious user tries to create fake links, thereby resulting in changing the controllers view of the network. A compromised soft switch can also fool the controller by sending hoaxed LLDP packets.
Control plane flooding may significantly increase the computational load on the controller. This flooding can bring down the controller as well. OpenFlow needs the switches to send complete packets to the controller.
The network denial of services attack hampers the ability of network to work properly. It overflows the entries of the switches, so that the switches are unable to work properly, hence resulting in network DoS.
A compromised or malicious switch may drop the packet instantly or may end the flow path abruptly. This situation results in a blackhole in network terminology. As a result of this, traffic cannot be routed to the destination.
The results of empirical studies show that Maestro is the most vulnerable controller among the controllers under discussion. While Beacon, Floodlight and Open Mul show one vulnerability each. However, the most promising performance has been displayed by Open IRIS controller. It showed great results against attacks like fake topologies and controller DoS. A summary of the above mentioned results is shown in Table 5.
Table 5. Comparison of Controller Vulnerabilities
In this paper, a survey of most commonly used controllers has been presented. The authors have surveyed the performance of these controllers in the perspective of throughput and latency. The survey shows that OpenIRIS controller has the lowest latency; and the OpenMul controller shows the highest throughput. On the other hand, in case of security, OpenIRIS has the least known vulnerabilities as compared to other controllers under consideration.