The controller in software-defined networking (SDN) acts as strategic point of control for the underlying network. Multiple controllers are available, and every single controller retains a number of features such as the OpenFlow version, clustering, modularity, platform, and partnership support, etc. They are regarded as vital when making a selection among a set of controllers. As such, the selection of the controller becomes a multi-criteria decision making (MCDM) problem with several features. Hence, an increase in this number will increase the computational complexity of the controller selection process. Previously, the selection of controllers based on features has been studied by the researchers. However, the prioritization of features has gotten less attention. Moreover, several features increase the computational complexity of the selection process. In this paper, we propose a mathematical modeling for feature prioritization with analytical network process (ANP) bridge model for SDN controllers. The results indicate that a prioritized features model lead to a reduction in the computational complexity of the selection of SDN controller. In addition, our model generates prioritized features for SDN controllers.
The software-defined networking (SDN) [1–5] premise separates the data and the control planes. The data plane comprises of forwarding devices such as switches and routers. The control plane is implemented via centralized controllers which manage the underlying network. Hence, the implementation of rules and policies are orchestrated through a programmable control plane. On the other hand, traditional networks architecture do not entail these functions. As such, the SDN has become a suitable choice for the next generation networks such as 5G [6,7], heterogeneous networks for quality-of-service provisioning [8], tactical networks [9], and the Internet-of-Things (IoT) [10].
A controller is the main pillar in the SDN; therefore, it plays a significant role. There are different types of controllers such as the TREMA [11], the POX [12], the RYU [13,14], the open network operating system (ONOS) [15], the OpenDaylight (ODL) [16], and the Floodlight [17]. Each controller has various features which include platform support, OpenFlow protocol [18], graphical user interface (GUI), clustering, synchronization, modularity, and support for the quantum application programming interface (API) etc. However, each controller does not have a similar support for these features. For instance, if we evaluate the platform component, we will find that POX supports three platforms i.e., Linux, Mac, and Windows, while TREMA supports Linux only. Similarly, the support for OpenFlow version (e.g., 1.0, 1.1, 1.2) varies among each.
Due to the significance of the features in the SDN controllers, they have been considered in several studies, including [19,20], as part of the controller selection process. However, none of these studies has investigated, their impact on performance. The controller with support for the latest features will affect the SDN performance, for instance, the higher versions protocols of the OpenFlow version 1.3, support metering. Facilitating the metering function on a switch can help in load balancing, resulting in lowering congestion.
Moreover, the fast-failover (FF) group is supported in the OpenFlow protocols with latest versions; this helps the recovery from link failures. GUIs affect how quickly a program runs. Parallel processing, clustering, and multi-threading become possible in the support for multiple platforms. The end-to-end (E2E) delay is reduced when clustering is used, which also enables better scalability and performance. Modularity directly affects the controller performance. More in-depth information on features and their relationship with performance can be found in [21].
In this paper, we propose a methodology for the SDN controller feature prioritization, and perform computations in two stages. In the first stage, we identify the controller features influencing the performance of the SDNs. In the second stage, we use an analytical network process (ANP) bridge model to prioritize the features of these controllers. We used the ANP as it prioritizes the features and their corresponding controllers.
The remainder of this paper is organized as follows. In Section 2 the motivation for feature analysis and its importance are discussed. The proposed ANP bridge model for the features and the controllers is discussed in Section 3. Results are discussed in Section 4. Finally, in Section 5 we conclude the paper and offer directions for future works.
Literature Review
The available features play a significant role in functioning of SDN controllers. This means that numerous criteria must be considered when selecting controllers for SDN applications [22,23]. In [21], it was demonstrated that the operation of SDN controllers was influenced by the incorporation of the best features. For example, performance is enhanced by newer versions of OpenFlow protocol such as 1.3, through enabling metering functions, that can reduce network traffic congestion. Similarly, the FF group is supported in OpenFlow-capable switches, which is useful for overcoming link failures. Therefore, a controller supporting higher versions of the OpenFlow protocol can be configured to avoid network congestion. GUIs are also an important feature, because they influence the speed at which a program runs, as well as the number of platforms on which it executes. Similarly, support for clustering ensures better scalability, reduced E2E delay, and improved performance. For similar reasons, the modularity feature directly influences a controller’s performance.
Moreover, the experimental analysis conducted in [24] showed that a controller selected based on the optimum feature set improves the SDN QoS. The controller is a central pillar in SDN; therefore, selecting a controller with the optimum feature set guarantees effective network utilization and improves the QoS. The significance of features in SDN controller selection was discussed in [25,26], in which the authors selected the controllers based on comparison of the feature set.
The 10 features considered for SDN controller selection in the aforementioned studies included OpenFlow, GUI, modularity, and platform support. However, during the selection process, the priority of one feature over another was determined intuitively. For example, the platform support feature was given five times more importance than the GUI feature, and equal importance to OpenFlow, modularity, and quantum API features. Moreover, an analytical hierarchy process (AHP) MCDM was used for controller selection. The AHP prioritized only alternatives (controllers) However, the prioritization of features was subject to the preferences of the decision-makers. For example, the user determined the priority of one feature over another. The priority or importance of a feature over another influences the controller selection approach. In contrast, our proposed ANP bridge model prioritizes the controllers and the features based on pairwise comparisons and feedback mechanisms provided by the ANP. Hence, in this study, we propose a method to prioritize features using this ANP bridge model. To the best of our knowledge, our proposed scheme is the first on features prioritization for SDN controllers.
Proposed Methodology
In the following subsections, we explain the problem formulation, system model for features prioritization of SDN controllers using the ANP bridge model, and relevant mathematical equations.
Problem Formulation and System Model
There are several SDN controllers, each having several features. Here, we consider the features that influence the performance of the SDN, i.e., (H_{1}–H_{8}) in [21]: OpenFlow, GUI, representational state transfer (REST) API, clustering, quantum API, synchronization, platform support, and modularity. The controllers considered in this study include Floodlight, ODL, ONOS, POX, RYU, and TREMA, which are denoted by M_{1}, M_{2}, M_{3}, M_{4}, M_{5}, and M_{6}, respectively. We consider the features as the criteria for prioritizing the alternatives (controllers). Hence, the problem is formulated using the ANP bridge model, as shown in Fig. 1. Tab. 1 lists the notations and symbols used in our proposed model. Tab. 2 presents the features and their notations considered for the SDN controllers. The next subsection details the prioritization of controllers features with the ANP bridge model in a step-by-step manner.
ANP bridge model for prioritization of SDN controllersSummary of notations
Notation
Explanation
N
Feature number
K
Controller number
R
Rows
L
Columns
CI
Consistency index
RI
Ratio index
H = H_{N} }
Features
M = M_{K} }
Controllers
χ
Eigenvector
Y
Consistency measure
CR
Consistency ratio
a_{ij}
Relative value of importance for an alternative/criteria corresponding to the i^{th} row of the j^{th} column
M_{1}
Floodlight
M_{2}
ODL
M_{3}
ONOS
M_{4}
POX
M_{5}
RYU
M_{6}
TREMA
Summary of notations for features of controllers
Scale
Explanation
H_{1}
OpenFlow
H_{2}
GUI
H_{3}
REST API
H_{4}
Clustering
H_{5}
Quantum API
H_{6}
Synchronization
H_{7}
Platform support
H_{8}
Modularity
Analytical Network Process
The ANP [27,28] is a generalized form of the AHP [29]. The AHP prioritizes alternatives based on a user’s subjective preferences for various criteria elements. However, the ANP models the problem as a network, and the criteria and alternatives elements are compared pairwise with respect to each other. Therefore, the ANP ranks the alternatives (controllers) and the criteria parameters (features). Fig. 1 shows our ANP model; the arrows indicate that features and controllers are compared using a pairwise method. The following is a step-by-step explanation of our ANP bridge model.
A hierarchical ANP model is constructed for alternatives and criteria clusters. Then, the elements in the clusters are connected by arrows, as shown in Fig. 1. The features and controllers of the two clusters are depicted in Eqs. (1) and (2), respectively.
H=(H1,H2,H3,…,HN)
M=(M1,M2,M3,…,MK)
Next, a pairwise comparison matrix, as expressed in Eq. (3), is formed, showing the relative importance of one feature (H) in row R over another feature in the corresponding column, L, with respect to a given controller, M. Similarly, the pairwise comparison matrix is also constructed, showing the priority of one controller over another. The quantitative value of the relative importance is derived from a scale, as shown in Tab. 3. A value of 1 in Tab. 3 indicates that the features are equally supported by the controller. A value of 2 denotes that a feature is equally to moderately more important than others in the controller for which the comparison matrix is to be computed. Tab. 3 shows the values that are incorporated corresponding to each feature when creating comparison matrices with respect to each controller.
Then, the pairwise comparison matrix is normalized to obtain the local priorities of the alternatives and criteria parameters in the form of eigenvectors, as shown in Eqs. (4) and (5). To validate the precision of judgments in constructing the pairwise comparison matrices, an important factor known as the consistency index (CI) is calculated. The CI ≤ 0.1 implies that pairwise judgments are consistent. The prerequisites for the CI are the consistency measure (Y_{j}) and λmax, which are calculated using Eqs. (6) and (7), respectively. Fig. 2 shows the calculation of λmax, and the consistency measure. Subsequently, the CI is calculated according to Eq. (8). The value of the ratio index (RI) is set according to the number of criteria or alternatives, and is then substituted in Eq. (9). Hence, Eq. (9) shows the final CI value.
Scale of relative significance for controllers and features
Scale
Illustration
1
Two criteria or features with equal importance
2
Moderately significant
3
Moderately more significant than the other
4
Comparatively more important than defined in the third row
5
Substantially more important
6
Substantially to extraordinarily more important
7
Extraordinarily more important
8
Extraordinarily to extremely important
9
Extremely more important
Calculation of the consistency measure (<italic>Y</italic>) for eigenvectors
In addition, the eigenvectors for each criterion are arranged in an unweighted super-matrix, showing the local priorities for criteria or alternatives. Finally, a limit super-matrix is obtained by calculating the power of the weighted super-matrix until its convergence, and this denotes the stable prioritized values for the features. In the following subsection, we calculate the comparison matrices and CR using Eqs. (1)–(9) and Tab. 2. Matrices (10)–(15) show the incorporated values for the features with respect to M_{1}–M_{6}. These equations also show the CR values.
Pairwise Comparison of Features
The pairwise comparison matrices of eight features with respect to controllers M_{1}–M_{6} and the CR are shown in Eqs. (10)–(15). Moreover, eigenvectors χ1−χ6 are computed for each controller (M_{1}–M_{6}). These eigenvectors show the priorities of the feature elements with respect to six controllers. In Eq. (10), the values of a_{(1,1)}, a_{(1,3)}, a_{(1,4)}, a_{(1,6)}, and a_{(1,8)} are equal to 1 because all of these features have the same importance for controller M_{1}. Similarly, the values for a_{(1,5)} = 9 and a_{(1,7)} = 5 indicate that H_{5} and H_{7} are nine and five times more important regarding controller M_{1}, respectively. The value of a_{(1,2)} = 1/5 show that the importance of H_{2} over H_{1} is five times. The relative importance values are input into the matrix for all features. Then, the CI is calculated using Eqs. (3)–(9). For consistent judgments, the CI value is verified using the condition (CI ≤ 0.1). Eqs. (10)–(15) reveal that the judgments are consistent. The relative importance values in the comparison matrices are adopted from Tab. 2.
Matrix (10) shows a feature comparison with respect to the M_{1} controller. It also shows the corresponding eigenvector, χ1, and the CR values. The CR value indicate that the judgments are consistent. Matrices (11)–(13) compare the features of controllers M_{2}, M_{3}, and M_{4} along with their eigenvectors and CR values.
Matrices (14) and (15) compare the features of the M_{5} and M_{6} controllers along with their eigenvectors and CR values. The CR for M_{5} is 0.09 and that for M_{6} is 0.02. Hence, both satisfy the CR condition for consistent judgments.
The values of χ7−χ14 are calculated, and the CI values are verified to be less than 0.1. These eigenvectors and CI values are calculated according to Eqs. (3)–(9), and the resultant CR values are presented in Matrices (16)–(23).
Moreover, the eigenvectors χ9−χ14 are computed, and CI value is validated for the judgments of each matrix. We used Eqs. (3)–(9) to obtain the eigenvectors and CI parameters. Finally, the CR parameters are computed and validated, as shown in Matrices (18)–(23).
After the comparisons, the eigenvectors are grouped in a non-weighted matrix, known as a super-matrix. This matrix shows the priorities of the controllers and their features. Then, the unweighted super-matrix as made column stochastic, and the resultant matrix is called a weighted super-matrix. The final stable values are obtained by calculating the k^{th} power of the weighted super-matrix until the values in the matrix converge. This matrix with stable values is known as the limit matrix. The summarized results of the limit matrix are listed in Tabs. 4 and 5. The results show the final priorities of the six controllers and eight features. According to Tab. 5, OpenFlow has a high importance weight, among other features. Intuitively, OpenFlow is the most commonly used protocol in SDN; therefore, almost all SDN controllers include a support for it. Similarly, the priority weights of the other features, i.e., H_{2}–H_{8}, are listed in Tab. 5. Moreover, Tab. 4 shows the priorities of the controllers; ODL and ONOS have higher weights than the others. Hence, these controllers include support for the latest features.
Eigenvectors of controllers based on comparison of features
Controller
Eigenvector
Weights for the weighted super-matrix
CR
M_{1}
χ_{ 1}
0.07
0.09
M_{2}
χ_{ 2}
0.13
0.02
M_{3}
χ_{ 3}
0.12
0.05
M_{4}
χ_{ 4}
0.05
0.06
M_{5}
χ_{ 5}
0.09
0.09
M_{6}
χ_{ 6}
0.04
0.02
Eigenvectors of features
Feature
Eigenvector
Weights of weighted super-matrix
CR
H_{1}
χ_{ 7}
0.42
0.01
H_{2}
χ_{ 8}
0.14
0.09
H_{3}
χ_{ 9}
0.049
0.00
H_{4}
χ_{ 10}
0.07
0.00
H_{5}
χ_{ 11}
0.033
0.09
H_{6}
χ_{ 12}
0.05
0.00
H_{7}
χ_{ 13}
0.09
0.00
H_{8}
χ_{ 14}
0.11
0.004
Thus, during controller selection, the relative importance of this feature should be higher than the others. The feature with the next highest importance weight is the GUI. The switches can be configured, and the global statistics of the underlying network topology can be obtained by using the GUI. The remaining features in order of their importance weight are modularity support, platform support, clustering support, synchronization, REST, and quantum APIs. Figs. 3 and 4 shows the stable ranking weights for controllers and features.
Final weights of the controllers based on the limit super-matrixFinal weights of the features based on the limit super-matrixConclusion
The controller is the most important entity in SDN. However, the selection of a controller becomes a challenging task because of multiple controllers with diverse features. In this study, we proposed a mathematical model to prioritize the eight features of SDN controllers by employing an ANP bridge model. The model generates prioritized weights for the SDN controllers and their features. During the calculation for selecting preferred controllers, the feature priorities were determined using this model. The ANP bridge model generated a list of controllers with priority values, and the most significant features were selected. Therefore, the computational complexity of this task was reduced by selecting features with high weights, whereas features with low priority were neglected. This should facilitate the rapid selection of controllers compared to selection with more features.
Funding Statement: This research was supported partially by LIG Nex1. It was also supported partially by the MSIT (Ministry of Science and ICT), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2021-2018-0-01431) supervised by the IITP (Institute for Information & Communications Technology Planning Evaluation).
Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.
ReferencesS.Ahmad and A. H.Mir, “Scalability, consistency, reliability and security in SDN controllers: A survey of diverse SDN controllers,” D.Sarmiento, A.Lebre, L.Nussbaum and A.Chari, “Decentralized SDN control plane for a distributed cloud-edge infrastructure: A survey,” S.Singh and R. K.Jha, “A survey on software defined networking: Architecture for next generation network,” C. N.Tadros, M. R.Rizk and B. M.Mokhtar, “Software defined network-based management for enhanced 5G network services,” Q.Long, Y.Chen, H.Zhang and X.Lei, “Software defined 5G and 6G networks: A survey,” A. A.Barakabitze, A.Ahmad, R.Mijumbi and A.Hines, “5G network slicing using SDN and nfv: A survey of taxonomy, architectures and future challenges,” S.Khan, H. A.Khattak, A.Almogren, M. A.Shah, I. UdDinet al., “5G vehicular network resource management for improving radio access through machine learning,” J.Ali and B. H.Roh, “An effective hierarchical control plane for software-defined networks leveraging TOPSIS for end-to-end QoS class-mapping,” J.Ali, G. M.Lee, B. H.Roh, D. K.Ryu and G.Park, “Software-defined networking approaches for link failure recovery: A survey,” A. K.Tran and M. J.Piran, “SDN controller placement in IoT networks: An optimized submodularity based approach,” “Trema Controller,” [Online]. Available: https://trema.github.io/trema/[Accessed on April 09, 2020].“Pox controller,” [Online]. Available: https://github.com/noxrepo/pox[Accessed on May 20, 2020].“Ryu controller,” [Online]. Available: https://ryu-SDN.org/[Accessed on June 10, 2020].J.Ali, S.Lee and B. H.Roh, “Performance analysis of pox and ryu with different SDN topologies,” in Proc. of the 2018 Int. Conf. on Information Science and System, pp. 244–249, 2018. “Open network operating system (ONOS),” [Online]. Available: https://www.opennetworking.org/onos/[Accessed on June 28, 2020].“Opendaylight (ODL),” [Online]. Available: https://www.opendaylight.org/[Accessed on July 17, 2020].“Floodlight controller,” [Online]. Available: https://floodlight.atlassian.net/wiki/spaces/floodlightcontro- ller/overview[Accessed on July 10, 2020].S. J.Vaughannichols, “OpenFlow: The next generation of the network,” H.Shiva and C.G.Philip, “A comparative study on software defined networking controller feature,” A. A.Semenovykh and O. R.Laponina, “Comparative analysis of SDN controllers,” J.Ali, B. H.Roh and S.Lee, “QoS improvement with an optimum controller selection for software-defined networks,” V. R. S.Raju, “SDN controllers comparison,” in Proc. of Science Globe Int. Conf., Bengaluru, India, 2018. D.Sakellaropoulou, “A qualitative study of SDN controllers,” 2017. [Online]. Available: https://mm.aueb. gr/master_theses/xylomenos/Sakellaropoulou_2017.pdf.J.Ali and B.Roh, “Quality of service improvement with optimal software-defined networking controller and control plane clustering,” O.Belkadi and Y.Laaziz, “A systematic and generic method for choosing a SDN controller,” R.Khondoker, A.Zaalouk, R.Marx and K.Bayarou, “Feature-based comparison and selection of software defined networking (SDN) controllers,” in World Congress on Computer Applications and Information Systems, 2014. T. L.Saaty, “The analytical network process,” H.Farman, B.Jan, Z.Khan and A.Koubaa, “A smart energy-based source location privacy preservation model for internet of things-based vehicular ad hoc networks,” A.Ishizaka and A. A.Labib, “Analytic hierarchy process and expert choice: Benefits and limitations,”