DOI:10.32604/cmc.2021.017813
| Computers, Materials & Continua DOI:10.32604/cmc.2021.017813 | |
| Article |
A Novel Features Prioritization Mechanism for Controllers in Software-Defined Networking
1Department of Computer Engineering and Department of AI Convergence Network, Ajou University, Suwon, 16499, Korea
2LIG Next1 Co. Ltd., Seongnam, 13488, Korea
3Department of Software and Computer Engineering, Ajou University, Suwon, 16499, Korea
*Corresponding Author: Byeong-hee Roh. Email: bhroh@ajou.ac.kr
Received: 12 February 2021; Accepted: 29 March 2021
Abstract: 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.
Keywords: Software-defined networking; controllers; feature-based selection; quality-of-service; analytical network process; analytical hierarchy process
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.
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.
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.
3.1 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., (H1–H8) 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 M1, M2, M3, M4, M5, and M6, 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.
Figure 1: ANP bridge model for prioritization of SDN controllers
Table 2: Summary of notations for features of controllers
3.2 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.
• 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 (Yj) and
Table 3: Scale of relative significance for controllers and features
Figure 2: Calculation of the consistency measure (Y) 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 M1–M6. These equations also show the CR values.
3.3 Pairwise Comparison of Features
The pairwise comparison matrices of eight features with respect to controllers M1–M6 and the CR are shown in Eqs. (10)–(15). Moreover, eigenvectors
Matrix (10) shows a feature comparison with respect to the M1 controller. It also shows the corresponding eigenvector,
Matrices (14) and (15) compare the features of the M5 and M6 controllers along with their eigenvectors and CR values. The CR for M5 is 0.09 and that for M6 is 0.02. Hence, both satisfy the CR condition for consistent judgments.
3.4 Pairwise Comparison of Controllers
The values of
Moreover, the eigenvectors
4 Results of the Final Priorities
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 kth 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., H2–H8, 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.
Table 4: Eigenvectors of controllers based on comparison of features
Table 5: Eigenvectors of features
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.
Figure 3: Final weights of the controllers based on the limit super-matrix
Figure 4: Final weights of the features based on the limit super-matrix
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.
1. S. Ahmad and A. H. Mir, “Scalability, consistency, reliability and security in SDN controllers: A survey of diverse SDN controllers,” Journal of Network and Systems Management, vol. 29, no. 1, pp. 1–59, 2021. [Google Scholar]
2. D. Sarmiento, A. Lebre, L. Nussbaum and A. Chari, “Decentralized SDN control plane for a distributed cloud-edge infrastructure: A survey,” IEEE Communications Surveys & Tutorials, vol. 23, no. 1, pp. 256–281, 2021. [Google Scholar]
3. S. Singh and R. K. Jha, “A survey on software defined networking: Architecture for next generation network,” Journal of Network and Systems Management, vol. 25, no. 2, pp. 321–374, 2017. [Google Scholar]
4. C. N. Tadros, M. R. Rizk and B. M. Mokhtar, “Software defined network-based management for enhanced 5G network services,” IEEE Access, vol. 12, no. 8, pp. 53997–54008, 2020. [Google Scholar]
5. Q. Long, Y. Chen, H. Zhang and X. Lei, “Software defined 5G and 6G networks: A survey,” Mobile Networks and Applications, pp. 1–21, 2019. [Google Scholar]
6. 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,” Computer Networks, vol. 167, pp. 1–40, 2020. [Google Scholar]
7. S. Khan, H. A. Khattak, A. Almogren, M. A. Shah, I. Ud Din et al., “5G vehicular network resource management for improving radio access through machine learning,” IEEE Access, vol. 8, pp. 6792–6800, 2020. [Google Scholar]
8. J. Ali and B. H. Roh, “An effective hierarchical control plane for software-defined networks leveraging TOPSIS for end-to-end QoS class-mapping,” IEEE Access, vol. 8, pp. 88990–89006, 2020. [Google Scholar]
9. J. Ali, G. M. Lee, B. H. Roh, D. K. Ryu and G. Park, “Software-defined networking approaches for link failure recovery: A survey,” Sustainability, vol. 12, no. 1, pp. 1–28, 2020. [Google Scholar]
10. A. K. Tran and M. J. Piran, “SDN controller placement in IoT networks: An optimized submodularity based approach,” Sensors, vol. 19, pp. 1–12; 2019. [Google Scholar]
11. “Trema Controller,” [Online]. Available: https://trema.github.io/trema/ [Accessed on April 09, 2020]. [Google Scholar]
12. “Pox controller,” [Online]. Available: https://github.com/noxrepo/pox [Accessed on May 20, 2020]. [Google Scholar]
13. “Ryu controller,” [Online]. Available: https://ryu-SDN.org/ [Accessed on June 10, 2020]. [Google Scholar]
14. 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. [Google Scholar]
15. “Open network operating system (ONOS),” [Online]. Available: https://www.opennetworking.org/onos/ [Accessed on June 28, 2020]. [Google Scholar]
16. “Opendaylight (ODL),” [Online]. Available: https://www.opendaylight.org/ [Accessed on July 17, 2020]. [Google Scholar]
17. “Floodlight controller,” [Online]. Available: https://floodlight.atlassian.net/wiki/spaces/floodlightcontro-ller/overview [Accessed on July 10, 2020]. [Google Scholar]
18. S. J. Vaughannichols, “OpenFlow: The next generation of the network,” Computer, vol. 44, no. 8, pp. 13–15, 2011. [Google Scholar]
19. H. Shiva and C. G.Philip, “A comparative study on software defined networking controller feature,” International Journal of Innovative Research in Computer and Communication Engineering, vol. 4, pp. 5354–5358, 2016. [Google Scholar]
20. A. A. Semenovykh and O. R. Laponina, “Comparative analysis of SDN controllers,” International Journal of Open Information Technologies, vol. 6, no. 7, pp. 50–56, 2018. [Google Scholar]
21. J. Ali, B. H. Roh and S. Lee, “QoS improvement with an optimum controller selection for software-defined networks,” PloS One, vol. 14, no. 5, pp. e0217631, 2019. [Google Scholar]
22. V. R. S. Raju, “SDN controllers comparison,” in Proc. of Science Globe Int. Conf., Bengaluru, India, 2018. [Google Scholar]
23. D. Sakellaropoulou, “A qualitative study of SDN controllers,” 2017. [Online]. Available: https://mm.aueb.gr/master_theses/xylomenos/Sakellaropoulou_2017.pdf. [Google Scholar]
24. J. Ali and B. Roh, “Quality of service improvement with optimal software-defined networking controller and control plane clustering,” Computers, Materials & Continua, vol. 67, no. 1, pp. 849–875, 2021. [Google Scholar]
25. O. Belkadi and Y. Laaziz, “A systematic and generic method for choosing a SDN controller,” International Journal of Computer Networks and Communications Security, vol. 5, no. 11, pp. 239–247, 2017. [Google Scholar]
26. 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. [Google Scholar]
27. T. L. Saaty, “The analytical network process,” Iranian Journal of Operations Research, vol. 1, pp. 1–27, 2008. [Google Scholar]
28. 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,” Transactions on Emerging Telecommunications Technologies, pp. 1–14, 2020. [Google Scholar]
29. A. Ishizaka and A. A. Labib, “Analytic hierarchy process and expert choice: Benefits and limitations,” OR Insight, vol. 22, no. 4, pp. 201–220, 2009. [Google Scholar]
 | This work is licensed under a Creative Commons Attribution 4.0 International License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. |