Comparison Of Open Source SDN Controllers – InApps 2022

Software Defined Networking (SDN) adds flexibility to control-plane implementation choices, allowing one to choose between points on the implementation design axis: centralized to distributed, micro-flow to aggregated-flow, reactive to proactive, virtual to physical, and fully-consistent to eventually-consistent.

In our previous articles on open source SDN controllers, we have seen that all SDN controllers typically include an open/standards-based interface to the hardware, a network operating system, and well-defined APIs to write various network applications. We have also seen that controllers differ from each other in these three aspects.

In this article, we will provide a not-so-comprehensive comparative analysis of different open source SDN controllers. At the onset, I would to highlight that the problem of comparing SDN controllers is an extremely challenging one, mainly because it is a multi-faceted problem. In addition, comparative analysis typically helps in ‘selecting’ a controller to meet a particular (or a set of) requirement(s). However, in this article we will not be talking about controller selection, and will restrict ourselves to highlighting differences from various aspects.

We will focus on the following:

1. Categorization of important interdependent aspects for controller comparison.
2. Identification of the aspects the current comparative studies have both covered and missed.
3. Comparison of SDN controllers from the perspective of applicability — use cases and application networks.

The Controller Aspects for Comparative Analysis

Figure 1 (below) shows difference aspects of SDN controllers — features, efficacy, use-cases and application networks — that could be considered for comparative analysis. The figure also highlights the fact that the ‘controller features’ form the most important aspect, influencing the various efficiency targets of the controllers, such as scalability, extensibility, programmability and interoperability.

Figure 1

The importance of the controller features also arises from the fact that they decide the applicability and the use cases that a controller can support. For example, if a controller is to support OpenStack-based network virtualization, it needs to have features and services such as Neutron plugins, and port and flow configurability.

In addition, applications also specify the services they want from the network. For example, an application that is delay sensitive expects the controller to include a service that can provide an end-to-end path with the least amount of delay.

Let’s look at different aspects in detail before we provide a comparison of controllers based on applicability.

Controller Features

The SDN controller features can be broadly classified into three different categories as shown in Figure 2 below:

Figure 2

In our previous articles on SDN controllers, we have mostly focused on these controller features from the different perspective of user/administrator, system-developer and application-developer.

Controller Efficacy

Controller efficacy is an umbrella term used to refer to the different performance parameters – performance, scalability, reliability and security. Almost all the existing comparative studies focus on one or more of these parameters. Performance could define various metrics, such as number of interfaces a controller can handle, latency, throughput, etc. Similarly, there are various metrics used in the existing works defining the scalability, reliability and security.

Use Cases and Application Networks

“It is important to realize that few, if any, IT organizations want a SDN,” Jim Metzler argued.

What IT organizations want is to solve current problems and add value. If SDN can enable them to do that better than alternative approaches to networking, then it will be widely adopted.

SDN’s key aspect — providing the freedom of refactoring the network control plane to the network designers — has found its application in various domains, such as network virtualization and network functions virtualization (NFV). In fact, the recent interest in NFV has also triggered renewed interested in SDN.

In the available literature, we will find various use cases that have been proposed for SDN, which we’ll discuss later in detail.  We’ll also see how some researchers and developers talk about the applicability of the controllers to a specific type of network — data center networks, service provider networks and campus networks. Hence, is very useful to compare controllers from the perspective of of use cases and application networks.

What do the Existing Studies Say?

Below, we describe three important comparative studies. Though some comparative analyses provided by the commercial controllers do exist, they are not mentioned here to avoid any ‘marketing’ for a vendor:

1. Tootoonchian, Gorbunov, Ganjali, Casado and Sherwood were among the first to provide the comparative analysis of controllers: “On Controller Performance in Software-Defined Networks.” They covered a limited number of controllers (NOX-MT, Beacon and Maestro) and focused on controller performance only. These controllers have already been superseded by other controllers like POX, Ryu, FloodLight and OpenDaylight.

2. “Feature-based Comparison and Selections of Software Defined Networking (SDN) Controllers” was conducted by Khondoker, Zaalouk, Marx and Bayarou. In this work the authors provide a set of requirements: TLS Support, virtualization, open source, interfaces, GUI, RESTful API, productivity, documentation, modularity, platform support, TLS support, age, OpenFlow support, OpenStack Neutron support – of which the first three they define as mandatory and the remaining 10 (which are in turn prioritized) as optional.  The existing open source controllers (and their properties) are compared based on these requirements.

Additionally, for selecting the best controller based on optional requirements (for example, GUI will be extremely preferred over the age of the controller), a Multi-Criteria Decision Making (MCDM) method named Analytic Hierarchy Process (AHP) has been adapted by a monotonic interpolation/extrapolation mechanism which maps the values of the properties to a value in a pre-defined scale. By using the adapted AHP, the top-most five controllers have been compared, and “Ryu” is selected to be the best controller based on their requirements.

3. “Advanced study of SDN/OpenFlow Controllers” was performed by Shalimov, Zuikov, Zimarina, Pashkov and Smeliansky. The authors claim to do an impartial comparative analysis of the effectiveness of the widely used SDN controllers: NOX, POX, Beacon, Floodlight, MuL, Maestro and Ryu. In this work, the authors define an umbrella term — controller effectiveness — as a collection of efficiency indexes, such as performance, scalability, reliability and security. The conclusions provided by the authors include:

• There were a  number of possible security vulnerabilities of the tested controllers.
• Most of the controllers were capable of coping with an average workload.
• Maximum throughput was demonstrated by Beacon.

Critical Analysis of Existing Studies

• The majority of the work is restricted to the controller features and controller effectiveness, such as performance, security and reliability.
• The applicability of the controller, in terms of supported use cases and application networks (which are dependent on the features of the controller), is not well studied.
• Within controller efficacy, various parameters are not addressed. For example, the controller capacity (in terms of the number of switches/interfaces it can manage) is not well studied. Even the parameters, such as mobility and scalability, are overlooked.
• Some of the controller features, such as support for proactive/reactive flow management, hierarchy/multiplicity of controllers, Southbound protocols supported and interoperability with legacy (non-SDN) networks are totally overlooked.
• Multi-tenancy, an important aspect for multiple application networks (Data Center, Transport, etc.) is not well evaluated.
• The comparison based on reactive and proactive paradigms is also missing. It would be very interesting to see how and what proactive operations are supported by a controller.
• No proper justification is provided for the choice of “mandatory requirements for SDN controllers.”
• Many commercial controllers mostly restrict their comparative analysis to the controller features and rarely talk about the “numbers” — number of interfaces, number of tenants and virtual networks, etc.
• Comparative analysis of both the Northbound APIs and the Southbound protocols is not comprehensive enough to provide significant insight.
• The aspect of popularity among the application developers – meaning the number of applications they developed with the controller — is not well documented.
• Finally, user-friendliness, in terms of visualization options such as GUI and CLIs, are not well compared.

Comparison of Open Source SDN Controllers: Use Cases and Application Networks

Table 1 below describes the important use-cases.

Here’s some use cases that review different SDN environments: Netsocket, Lippis Report, OpenFlow 1,  OpenFlow 2, NFV and Network Virtualization, Network Programmability, Brocade SDN (docx) and Bare Metal SDN.

 Table 1

Before we discuss the comparative analysis of the controllers, it is important to note the following points regarding the use cases, which highlight the challenges, from the point of view of comparative analysis:

1. 1. The use cases covered here are the important and popular ones, and should be considered a complete list. Hence, you may see some insignificant use cases here that some controllers support and some don’t.
   2. The majority of the use cases (legacy network support, campus-networks, multi-layer network optimization, etc.) do not have a clear specification and scope-definition. It would be extremely difficult to say “YES” or “NO” if a controller supports it or not.
   3. Alternatively, there are use cases (edge-overlays, OpenStack Neutron support, hop-by-hop network virtualization, etc.) which have clear specifications, and comparative analysis of those is relatively straightforward as a “YES” or “NO.”
   4. There are use cases (load-balancing, monitoring, policy enforcement, etc.) that have a lot of overlapping in their functionalities. Some controllers may support such use cases partially, and comparison in those cases also becomes challenging.

Table 2 (below) summarizes the comparison of open source controllers considering different use cases.

Table 2

1. YES
   • Supports completely.
   • The majority of the elements exist and can support with minor enhancements.
   • There exists a commercial/proprietary solution(s) developed on top of the open source controller, which helps in supporting the use case.
   • Supports a significant number of use cases within an application network domain.
2. NO
   • Does not support.
   • Only foundational elements exists and they need major enhancements.
   • No commercial/proprietary solution exists on top of the open source controller.
3. PARTIAL
   • Supports the use case partially.
   • Significant number of services/applications exist in the controller to realize the support for the use case.
   • Supports partial set of use cases within an application network domain.
   • The work is in progress.

From Table 2 we can see that ODL’s features make it more suitable to support the majority of use cases. This could be one of the reasons for its immense popularity. Ryu and Floodlight have a similar number of use case supports, with Ryu having support for two of the most important use cases: service insertion and chaining, and transport networks. Similarly, NOX/POX and Trema have similar uses case supports.

Summary

Comparing SDN controllers is both interesting and challenging; however, using such comparative analysis to select a controller is even more difficult. One needs to consider various aspects of the controller, and this article is one such attempt to share different aspects for comparative studies. There is still a strong need for a comprehensive comparative analysis, as mentioned in the preceding critical analysis section. Finally, applicability is an interesting aspect which should be considered when comparing SDN controllers.

Sridhar received his Ph.D. in computer science from the National University of Singapore in 2007; his M.Tech. degree in computer science from KREC, Surathkal, India, in 2000; and his B.E. degree in instrumentation and electronics from SIT, Tumkur, Bangalore University, India, in August 1997. He worked as a Research lead at SRM Research Institute, India; post-doctoral fellow at Microsoft Innovation Center, Politecnico Di Torino, Turin, Italy; and as a research fellow at the Institute for Infocomm Research (I2R) in Singapore. He has worked on various development and deployment projects involving ZigBee, WiFi and WiMax. Sridhar is currently working as the Group Technical Specialist with NEC Technologies India Limited. Sridhar’s research interests lie mainly in the domain of next-generation wired and wireless networking, such as OpenFlow, software defined networking, software defined radio-based systems for cognitive networks, Hotspot 2.0 and the Internet of Things.

Featured image via Flickr Creative Commons.