Controller placement with critical switch aware in software-defined network (CPCSA)

Nura Muhammed Yusuf; Kamalrulnizam Abu Bakar; Babangida Isyaku; Abdelzahir Abdelmaboud; Wamda Nagmeldin

doi:10.7717/peerj-cs.1698

Controller placement with critical switch aware in software-defined network (CPCSA)

Nura Muhammed Yusuf ^1,2, Kamalrulnizam Abu Bakar¹, Babangida Isyaku ^1,3, Abdelzahir Abdelmaboud⁴, Wamda Nagmeldin⁵

1Department of Computer Science, Faculty of Computing, Universiti Teknologi Malaysia, Johor, Johor Bahru, Malaysia

2Department of Mathematical Science, Faculty of Sciences, Abubakar Tafawa Balewa University, Bauchi, Nigeria

3Department of Computer Science, Faculty of Computing and Information Technology, Sule Lamido University, Kafin Hausa, Jigawa State, Nigeria

4Department of Information Systems, King Khalid University, Abha, Saudi Arabia

5Department of Information Systems, College of Computer Engineering and Sciences, Prince Sattam bin Abdulaziz University, Al-Kharj, Saudi Arabia

DOI: 10.7717/peerj-cs.1698

Published: 2023-12-19
Accepted: 2023-10-24
Received: 2023-08-18

Academic Editor: Rowayda Sadek

Subject Areas: Computer Networks and Communications, Emerging Technologies
Keywords: SDN, Controller placement, Controller overhead, Switch role, Network partition

Copyright: © 2023 Muhammed Yusuf et al.
Licence: This is an open access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, reproduction and adaptation in any medium and for any purpose provided that it is properly attributed. For attribution, the original author(s), title, publication source (PeerJ Computer Science) and either DOI or URL of the article must be cited.

Cite this article: Muhammed Yusuf N, Abu Bakar K, Isyaku B, Abdelmaboud A, Nagmeldin W. 2023. Controller placement with critical switch aware in software-defined network (CPCSA) PeerJ Computer Science 9:e1698 https://doi.org/10.7717/peerj-cs.1698

The authors have chosen to make the review history of this article public.

Abstract

Software-defined networking (SDN) is a networking architecture with improved efficiency achieved by moving networking decisions from the data plane to provide them critically at the control plane. In a traditional SDN, typically, a single controller is used. However, the complexity of modern networks due to their size and high traffic volume with varied quality of service requirements have introduced high control message communications overhead on the controller. Similarly, the solution found using multiple distributed controllers brings forth the ‘controller placement problem’ (CPP). Incorporating switch roles in the CPP modelling during network partitioning for controller placement has not been adequately considered by any existing CPP techniques. This article proposes the controller placement algorithm with network partition based on critical switch awareness (CPCSA). CPCSA identifies critical switch in the software defined wide area network (SDWAN) and then partition the network based on the criticality. Subsequently, a controller is assigned to each partition to improve control messages communication overhead, loss, throughput, and flow setup delay. The CPSCSA experimented with real network topologies obtained from the Internet Topology Zoo. Results show that CPCSA has achieved an aggregate reduction in the controller’s overhead by 73%, loss by 51%, and latency by 16% while improving throughput by 16% compared to the benchmark algorithms.

Introduction

Software-defined networking (SDN) is an emerging network paradigm offering simple network management by separating network control logic and data forwarding elements. This way, the control plane (CP) is responsible for providing and enforcing network policies on the switches at the data plane (DP). To achieve this, the controller uses a link layer discovery protocol (LLDP) to identify the OpenFlow switches connected at the DP (Yusuf et al., 2023a). It then continuously monitors them for changes due to events like failures or the arrival of new flows. It collects network statistics concerning traffic arrival patterns, traffic types, and other changes for various applications like routing, congestion control, and security to run their algorithm instances (Isyaku & Bakar, 2023). For any state change at DP, the controller must immediately recalculate updated instructions for the DP switches, sending them as a packet-out message to all edge switches (for ARP) and a flow-mod message to all switches along the same path for installation on their flow tables (Yusuf et al., 2023c). Recently, the controller has been experiencing a substantial increase in communication overhead due to an exponential growth in new flow arrival rates caused by the proliferation of Internet of Things (IoT) devices and the expansion of network size (Firouz et al., 2021). Consequently, the DP may frequently encounter state change events like link failure (Isyaku et al., 2023), requiring the controller to reconfigure new rules (Isyaku et al., 2021).

This process has implications for the workload of the controller. For instance, if a flow traverses an average path length of six switches and the network has 100 edge switches, the controller is estimated to spend around 6 ms to handle each flow (Zhao et al., 2017a). A prior study reports that processing these messages adds an overhead and delay of approximately 0.5 and 0.2 ms, respectively. As a result, the cumulative burden on the controller amounts to (0.5 * 6 + 0.2 * 100) (Zhao et al., 2017a). Moreover, another study highlights a direct correlation between the number of switches in a network and the volume of flow setup requests. According to Curtis et al. (2011), configuring a flow route for a network with N switches incurs an overall cost of approximately 94 + 144N, with an additional 88N byte attributed to flow-removed messages. Thus, CP design is critical to the performance of SDN.

A single controller (csCP) design is widely used for small network sizes. However, it may fail to give the desired performance due to high control message processing overhead. It also exhibits reliability concerns due to a single failure point (SPOF), as the failure tendencies are higher when the network is large. As such researchers leverage multiple controllers (dmCP), which better performance compared to csCP. Figure 1 illustrates the differences between the former and the latter. For example, an extensive network may have switches that can generate up to 750 to 20,000 flow per second (Isyaku et al., 2021); others say it might reach up to 10 million flow requests per second (Ahmad & Mir, 2021; Yan et al., 2021). Unfortunately, this is beyond the capacity of a single controller, as some controllers can only accommodate 6,000 flow requests per second (Hu et al., 2017). On the other hand, designing the CP with multiple controllers opens up a controller placement problem (CPP) challenge. For any given network, the CPP deals with finding and optimising (i) the number of controllers in the network. (ii) The controllers should be placed strategically on the network to minimise congestion, overhead, and Latency between controllers and switches. Heller, Sherwood & Mckeown (2012), who initiated the concept of (CPP), built their solution while considering the impact of Latency. The solution performs well for small-scale networks; however, it ignores the effects of scalability, reliability, and congestion in large networks such as WAN. Assigning controllers to switches in an extensive network can exhibit an imbalance distribution of load among the controllers. Therefore, for a software-defined wide area network (SDWAN), a partitioning algorithm is employed to cluster the network into smaller subnets for controller placement (Killi & Rao, 2019).

Figure 1: Control plane architecture.
Single control plane architecture (A) and multiple controllers (B).

Download full-size image

DOI: 10.7717/peerj-cs.1698/fig-1

Several CPP solutions employ network partitioning techniques in their approaches. For example, methods such as Killi, Reddy & Rao (2019), Kuang et al. (2018), Liu, Liu & Xie (2016), Xiao et al. (2014), Wang et al. (2018), Xiao et al. (2016), Yang et al. (2019a, 2019b) and Zhu et al. (2017) are designed based on k-means. A K-median is used by Liu et al. (2018) and Kobo, Abu-Mahfouz & Hancke (2019), while Xiao et al. (2014, 2016), Aoki & Shinomiya (2015, 2016), Zhao & Wu (2017) used Spectral Clustering. Density-based Clustering, Affinity Propagation, and Partitioning Around Medoids (PAM) are also used in Liao et al. (2017), Zhao et al. (2017b), Bannour, Souihi & Mellouk (2017) and Dvir, Haddad & Zilberman (2018). Others hybridised two techniques in their solution (Yang et al., 2019a, 2019b; Firouz et al., 2021; Manoharan, 2021). All these techniques share the common idea of partitioning the SDWAN into smaller sub-domains, allowing for assigning one or more exclusive controllers to cover each subdomain. The k-means algorithm is one of the common methodologies used to partition a network topology. It uses Euclidean distance as its similarity metric during the partition process. However, computing Euclidean distance in real networks is not always possible due to the lack of physically connected pathways in some instances. Similarly, the strategy has no generally agreed-upon way to determine the first k partitions. The method varies in how it initialises the first set of cluster heads. Hence, the initial cluster head selection significantly affects the solution quality; thus, it is a significant limitation.

On the other hand, PAM is quite similar to k-means, except that it minimises the impact of outliers by selecting a node at the cluster’s centre as the head. Although PAM does not require prior knowledge of k, it has a considerably high complexity to the tune of about cubic time. Additionally, while these approaches may be suitable for initial controller placement, repeatedly segmenting the entire network to adapt to its dynamic nature is unrealistic. At the same time, spectral clustering tends to produce small, isolated components and clusters of skewed sizes. In addition, all the solutions did not quantify the controller’s overhead and response time (RT) in their performance validation.

In the rapidly evolving landscape of SDN, the efficient placement of controllers plays a pivotal role in network performance and reliability. This article addresses this critical challenge by introducing an innovative approach that optimises controller placement and considers the impact on critical switches within the network. The existing solution did not adequately consider the roles of switches in the network. It is important to note that switches have different roles; some switchers are very critical, and others are non-critical. The former can have a significant impact on the efficient controller placement solution. Identifying critical switches is crucial for optimal controller placement during network partitioning decisions. Critical switches possess a high degree and betweenness criticality measures that tend to send higher flow rule requests to the controller. As a result, they often augment the flow setup delay and cause high update operations. This problem results in additional overhead on the controller if multiple critical switches reside in the same partition. Therefore, this article proposes the Controller placement algorithm with network partition based on critical switch awareness (CPCSA) to mitigate these issues. CPCSA identifies critical switch in the SDWAN and then partition the network based on the criticality. Subsequently, a controller is assigned to each partition to improve control messages communication Overhead and other dependent QoS metrics like loss, throughput, and flow setup delay. We itemized the contributions of this article as follows.

We devised a network partitioning model based on the switch role in the network to determine the number of controllers.
A switch to controller placement strategy was introduced based on switch criticality factor to improve the control plane’s performance.
The performance evaluation result of CPCSA using real networks from Internet Topology Zoo in comparison to other relevant CPP algorithms.

The remainder of the article is structured as follows: ‘Related Works’ related works in SDN. ‘Materials and Method’ analyses the problem. Next, Section 4 presents the proposed solution. Then, ‘Results’ describes the experimental setup and performance evaluation. Lastly, ‘Conclusion’ concludes the study and makes recommendations for future research.

Related works

Selecting a suitable position in SDWAN for controller placement is crucial to its performance (Heller, Sherwood & Mckeown, 2012). Inappropriate controller placement can increase communication overhead and flow setup delay. Therefore, several CPP solutions have been proposed (Yusuf et al., 2023b). The CPP solutions presented in Xiao et al. (2014, 2016), Aoki & Shinomiya (2015, 2016) and Zhao & Wu (2017) utilised spectral Clustering to partition the wide-area Network into many subnetworks. Some authors infer the count of subnets by exploiting the concept of eigenvectors, using the Haversine equation to calculate the similarity graph. Each resulting subnetwork is assigned a dedicated controller at a location that minimises the control message latency. Researchers in Zhao & Wu (2017) formulate the CPP as an integer linear programming (ILP) with the optimisation objective of reducing the network cost. They design a heuristic method to solve the ILP. However, spectral clustering tends to produce small, isolated components and clusters of similar sizes. In addition, all the solutions did not quantify the controller overhead and response time (RT) in the performance validation.

In a different approach to formulating a clustering-based CPP (Zhu, Chai & Chen, 2017), researchers utilise integer programming (IP). They reduce the network’s transmission time by employing a modified version of k-means with the shortest path as the similarity metric. In Zhao et al. (2017b), the authors formulate a binary variable model of the CPP and cluster it using an affinity propagation technique (APT). APT maximised similarity across short distances and moderated preference control to a mean value. In another approach, Liao et al. (2017) propose density-based controller placement (DBCP) to partition a network into various sub-networks. The DBCP grouped tightly connected switches within the same subnet and less-connected switches in a different subnet. The value of k and members of each subnet is determined based on the distance to a higher-density node. Each sub-network is assigned a single controller. In other techniques, PAM-B clustering and NSGA-II were utilised by Bannour, Souihi & Mellouk (2017) to solve the Network partitioned-based CPP with the multi-objective problem of optimising Latency, capacity, and availability. In another approach, using the shortest path as the similarity metric (Wang et al., 2018, 2016), partitioned a network for CPP using k-means. Starting with a random centroid, the algorithm iterates continuously until it divides the network into k clusters. In a similar effort, researchers utilised simulated annealing (SA) and the k-median algorithm (Liu et al., 2018) to determine the optimal location for a satellite gateway in a 5G network, aiming to reduce latency. The authors implemented a clustering strategy to improve connectivity reliability between satellites and controller nodes. Also, Kuang et al. (2018) confronts the network partitioning problem by employing the k*-means for a CPP. Initialised the partitioning with more than k clusters and later merged the nodes into the k clusters recursively based on the shortest path distance and cluster load. While in a different approach proposed by Killi, Reddy & Rao (2019), for Network partition-based controller placement to reduce latency, the authors utilise a k-means algorithm with initialisation based on cooperative game theory. Cooperative game with a set of switches as players are used to mimicking the division of the Network into subnetworks. The switches attempt to build alliances with other switches to increase their value. They also suggest two variations of the cooperative k-means technique to create size-balanced partitions. However, these approaches did not consider load balance issues. Dvir, Haddad & Zilberman (2018) formulated the CPP as an IP. The network was divided into partitions using a k-medoid clustering technique. However, the value of k is determined via a brute-force approach. In contrast, CPP was tackled using a k-centre/k-median clustering strategy by Kobo, Abu-Mahfouz & Hancke (2019). The authors suggested creating a local and global controller hierarchy. When a controller fails, it is replaced using the re-election procedure. To assess load balancing (Yang et al., 2019a, 2019b) defines two distinct cost functions regarding the network topology structure and flow traffic distribution. They then hybridise the network partition scheme to tackle the problem of where to locate the load-balancing controller. Each of the numerous sub-domains that comprise the overall Network has one dedicated controller. Finally, a simulated annealing partition-based k-means (SAPKM) to address the placement is proposed. SAPKM incorporates a centroid-based clustering to achieve load-balancing among the controllers. The k-means algorithm uses Euclidean distance as its similarity metric. However, the problem is that it is not always possible to compute the Euclidean distance in real networks due to the lack of physically connected pathways. Similarly, k-means has no agreed-upon way to determine the first k partitions. The method varies in how it initialises the first set of clusters head. Thus, the initial cluster head selection significantly affects the solution quality in k-means; this is considered a significant limitation. On the other hand, PAM is quite like k-means, except that it establishes a node in the cluster’s centre as the head to minimise the effects of the outliers. Although they do not require prior knowledge of k, they have a significantly higher level of complexity to the tune of about cubic time. At the same time, spectral clustering tends to produce small, isolated components and clusters of similar sizes.

Network clustering for CPP using data field theory (DFT) was proposed by Li et al. (2019). The DFT considers the strength of the wireless nodes’ transmissions and reception signal power to determine the controller placement inside each cluster to reduce Latency and energy. While Ali & Roh (2022) and Ali, Lee & Roh (2019) presents an SDN partition strategy for controller placement in IoT environments to reduce latency using the analytical network process (ANP). The authors thoughtfully consider multiple latency-inducing parameters to guide their ranking and selection process with ANP. However, it’s worth noting that one parameter that wasn’t considered in their analysis is the controller’s overhead. This omission is significant as it can impact performance and should ideally be factored into such an optimization strategy.

Another work (Manoharan, 2021) employed a graph theory to identify the number of controllers and their initial location. A Depth-First-Search algorithm is applied to determine Articulation Points (AP) based on two conditions. To obtain the required number of controllers and placement positions, they utilize APs. Additionally, they discretize a supervised machine learning concept using Manta-Ray Foraging Optimization (MRFO) and Salp Swarm Algorithm (SSA) to solve CPP based on network partitioning (Firouz et al., 2021). However, the lack of a standardized and rich dataset for model training has been a serious concern in any AI-based solution for SDN problems (Isyaku et al., 2020; Elsayed et al., 2019). However, privacy and confidentiality issues associated with Networks have made sharing this data difficult and scarce. Additionally, the approaches may be suitable for acquiring the first controller placement. However, it is unrealistic to repeatedly segment the entire Network to meet the evolution of dynamic network changes. Thus, they lack an adaptable CPP that responds to the dynamics of each given network. Therefore, based on the discussed literature, it can be conclude that all the solutions have not adequetely consider the switch's role in the Network to identify and separate a set of critical from non-critical switches. Recognizing the critical switches is crucial during network partition decisions for optimum controller placement. Such sets of switches possess high degree and betweenness criticality measures with many rules in their flow table entries. As a result, they often augment the flow setup delay and cause more update operations. The problem leads to additional overhead on the controller if multiple critical switches are in the same partition. See Table 1 for the summary of these approaches.

Table 1:

Network partitioned-based CPP.

Article	Problem formulation	Partition/solution approach	Network topology properties			Performance metrics considered			Weakness
Article	Problem formulation	Partition/solution approach	Path	Switch role	Metrics	Latency	Overhead	Loss	Partition approach	Performance metrics
Wang et al. (2016)	MILP	Heuristics	✓	X	X	✓	✓	X	Not partitioned	Throughput and loss unaccounted
Killi & Rao (2019), Kuang et al. (2018)	Network partitioning	Spectral clustering	✓	X	Eigen vectors	✓	X	X	Tend to produce small, isolated components and clusters with similar sizes	High CP overhead, Poor load balancing & CP overhead and throughput
Yang et al. (2019b), Zhu et al. (2017)		Spectral clustering	✓	X	Eigen vectors	✓	X	X
Li et al. (2019)		Node Burden	✓	✓	Traversal set	✓	X	X
Liu et al. (2018)	ILP	Spectral clustering	✓	X	Eigen vectors	✓	X	X
Bannour, Souihi & Mellouk (2017)	ILP	K-Means	✓	X	Euclidean distance	✓	X	X	Random centre initialisation stage, the number of cluster determinations
Modified-AP (Aoki & Shinomiya, 2015)	BIP	Affinity propagation	✓	X	Shortest distance	✓	X	X	Not partitioned
Kobo, Abu-Mahfouz & Hancke (2019)	Network partitioning	Density-based clustering	✓	✓	Density	✓	X	X	NA
Aoki & Shinomiya (2016)	MOCO	PAM-B	✓	X	Dijkstra	✓	X	X	Quadratic running time complexity
SACA (Xiao et al., 2016)	Mathematical	K-Median, SA	✓	X	Euclidean distance	✓	X	X	Random centre initialisation, number of cluster determinations, the use of “means” limit its expression level, Euclidean distance might not get a path physically connected path, one size fits it-all effect, outliers, and noise
Hu et al. (2017)	Network partitioning	K-Means	✓	X		✓	X	X
Zhao & Wu (2017)	IP	K-Mediod		X		✓	X	X
Killi, Reddy & Rao (2019), Dvir, Haddad & Zilberman (2018)	Mathematical model	K-Means	✓	X		✓	X	X
Ali & Roh (2022)		Clique-based	✓	X	Shortest distance	✓	X	X	Too rigid to use in practice. It tends to produce maximally cohesive subgraph	The clique property cant guarantee optimum RT
SACKM (Liu, Liu & Xie, 2016; Xiao et al., 2014)		Hybridised SA with K-Means	✓	X	Euclidean distance	✓	X	X	K-means limitation, SA limited memory to track tested solutions, low improvement rate,	Ignore the CP overhead, LB, and throughput
Manoharan (2021)		Data field theory	X	X	Signal strength	✓	X	X	Interference
Yang et al. (2019a)	IP	K-Median	✓	X	Haversine	✓	X	X	Random centre initialisation stage, the number of cluster determinations,
Yan et al. (2021)	Mathematical model	K-means with game theory	✓	X	Euclidean distance	✓	X	X
PHCPA (Yusuf et al., 2023a)	AI	MRFO with Salp Swarm	✓	X	Cosine Haversine	✓	X	X	Lack of sufficient training dataset	Increased PPT, control message overhead
PITS (Liao et al., 2017)	Graph theory,	DFS	--	---	----	✓	X	X	Lack of sufficient training dataset	Increased PPT, control message overhead
GravCPA (Ali, Lee & Roh, 2019)	LP	Louvain algorithms	X	Node Traffic	Euclidean	✓	X	X	LPA and gravitation are vulnerable to oscillations and non-unique results
ECP (Isyaku et al., 2020)	MILP	Linearization & Supermodular	X	X	----	✓	✓	X	The CP overhead will likely resurface due to not partitioning the network into smaller clusters.
Elsayed et al. (2019)	Greedy	None	X	X	X	✓	✓	X	Network properties not considered	No controller placement module

DOI: 10.7717/peerj-cs.1698/table-1

Note:

PITS, Pareto integrated Tabu search; SA, simulated annealing.

Materials and Methods

Analysis of controller overhead

SDN controller overhead refers to the computational and resource requirements imposed on the SDN controller as it manages and controls the network. Although, the controller operates based on either proactive or reactive mode. The former may have lower overhead but may not cope with the real network []. The latter is widely used due to its flexibility in real-time network. However, any newly arrived Flow $n F_{i}$ at switch $s_{i} \in S$ without corresponding forwarding rule entries in its flow table will introduce an overhead of composing and sending a Packet_IN message to its controller $S P r_{o v e r h e a d}$ on the switch. Likewise, on its part, the controller $C$ also suffers the overhead of computing the required forwarding rule and subsequent installation in the switches $s_{i} \in S$ flow Table via Packet_OUT message $C P r_{o v e r h e a d}$ . Due to these overheads, the new flow $n F_{i}$ , will experience a path setup time delay $F S e t U p_{S C}$ , while waiting to be directed by a controller $C$ . The flow/path setup delay emanates from five sources (i) a queue waiting time $w t S$ at the switch $S_{i}$ before being served for duration $s t S$ , (ii) a switch $s_{i}$ to controller $C$ Packet_IN message propagation time $P_{i n} (s_{i}, C)$ (iii) a queue waiting time $w t C$ at controller $C$ before being served for (iv) a duration $s t C$ and (v) controller $C$ to switch $S$ Packet_OUT message propagation time $P_{o u t} (C, S_{i})$ . Therefore, cumulatively, the flow setup time delay is determined by.

(1) $F S e t U p = w t S + s t S + P_{i n} (S_{i}, C) + w t C + s t C + P_{o u t} (C, S_{i})$

Equation (1) above fundamentally comprised the switch $S_{i}$ processing overhead, the controller $C$ processing overhead, and the round-trip time between switch $S_{i},$ and the controller $C$ , given by Eqs. (2)–(4), respectively.

(2) $S_{i} P r_{o v e r h e a d} = w t S + s t S$

(3) $C P r_{o v e r h e a d} = w t C + s t C$

(4) $R_{T T} = P_{i n} (S, C) + P_{o u t} (C, S)$

Considering a network topology with $a n S$ set of switches $s_{i} \in S$ and $E,$ as the communication links between the switches, can be represented as graph $G = (S, E)$ . Any mapping of a set of switches $s_{i} \in S$ with a controller $C$ impose an overhead $C P r_{o v e r h e a d}$ on the controller that is directly proportional to the cost of the flow rule setup request and subsequent rule installation in the flow table.

(5) $C P r_{o v e r h e a d} \propto \sum S P r_{o v e r h e a d}$

The $S P r_{o v e r h e a d}$ at the switch $S_{i}$ is determined by the load of the switch due to the new flow $n F_{i}$ arrival rate from both the external source ( $H o s t)$ and internal source ( $s_{j})$ . As stated in Eq. (5), the overhead $S P r_{o v e r h e a d}$ directly increases the $C P r_{o v e r h e a d}$ . Therefore, if $n F_{h_{0}, S_{i}},$ denote the external new flows arrival rate at the switch $s_{i}$ from host $h_{0}$ . Let $X_{i m} \in {0, 1}$ variables indicate whether the switch $s_{i}$ is under the control of the controller $C_{m}$ or not, using $X_{i a} = {\begin{cases} 1, i f s_{i} \to C_{m} \\ 0, i f s_{i} ↛ C_{m} \end{cases}$ . Thus, the $n F_{i}$ arrival rate at $S_{i}$ from host $h_{0}$ will induce rule computation overhead on the controller equivalent to:

(6) $\sum_{s_{i} \in S} (n F_{h_{0}, S_{i}}) X_{i m}$

Hence if $n F_{h_{0}, S_{i}},$ denote the internal new flows arrival rate at the OpenFlow switch $S_{j}$ from host $S_{i}$ . The arrival rate will induce rule computation overhead at the SDN controller $C_{m}$ equals to

(7) $\sum_{s_{i} \in S} (n F_{S_{i}, S_{j}}) X_{i m}$

Therefore, for all the OpenFlow switches controlled by the controller $C_{m}$ , The total overall overhead on the controller for rules installation in the OpenFlow switch $S_{i}$ is equal to:

(8) $C P r_{o v e r h e a d} = \sum_{s_{i} \in S} (n F_{h_{0}, S_{i}}) X_{i m} + \sum_{s_{i} s_{j} \in S} (n F_{S_{i}, S_{j}}) X_{i m} + \sum_{s_{i} s_{j} \in S} (n F_{S_{i}, S_{j}}) X_{i m} + \sum_{s_{i} \in S} (n F_{S_{i}, h_{0},}) X_{i m}$

The objective is to minimize the $C P r_{o v e r h e a d}$ to improve the overall $F S e t U p$ and other QoS metrics. High controller overhead directly increases flow setup time which consequently causes performance retardation, especially for traffic with deadline violation constraints.

Design of the proposed solution

The proposed controller placement algorithm with critical switch awareness (CPCSA) for software-defined wide area network partitioned the network based on the switch role and assigned the required number of controllers to each partition. The operational procedure of CPCSA consists of three phases, with the output of each phase serving as input to the next phase. (i) The critical switch identification phase (CSIP) for reading the network topology to identify critical switches. (ii) Network partition phase (NPP) for partitioning the discovered topology based on the number of critical switches identified in (CSIP) and (iii) controller placement and assignment phase (CPAP), which uses the mathematical concept of facility location method to select a strategic position to place an SDN controller for each of the partitions formed in (NPP). This way, CPCSA placed an SDN controller in each partition formed based on the distance between the critical and non-critical switches within the partition to minimize the communication overhead and delay. ‘Network topology read phase’, ‘Switch role and critical switch identification phase (CSIP)’, ‘Network partition based on switch criticality’ and ‘Critical switch aware controller placement (CSACP)’ provide a detailed description of each phase. At the same time, the flowchart shown in Fig. 2 presents the overall procedure of the proposed algorithm (CPCSA).

Figure 2: CPCSA flow chart.

Download full-size image

DOI: 10.7717/peerj-cs.1698/fig-2

Network model and placement metrics

Consider an SDWAN topology modelled as a graph $G = (V, E)$ , with $V$ representing a set of nodes and $E$ the communication links between the nodes. The network node $V$ comprised a group of OpenFlow switches $S$ and an SDN Controllers $C,$ i.e., $i . e ., S, C \in V$ . The collection of the OpenFlow Switches $S$ includes critical switches $(C S)$ and non-critical switches $(n C S)$ . For controller placement, the technique partitions $G$ into multiple sub-nets $S D W A N_P a r t i t i o n s_{i}$ to improve latency performance and reduce a Controller’s overhead. In this study, we formulate the network partition problem by considering the switch’s role in the Network. This help in identifying the critical and non-critical switches in the Network. We defined the set of critical switches $(S C S)$ as:

(9) $S C S = \sum_{i = 1}^{k} C S_{i}$ where $k$ represents the Network’s total number of critical switches and gives us the number of subnets to partition the Network G. At the same time, we can obtain the set of non-critical switches from

(10) $S n C S = S ∖ S C S$

Therefore, by partitioning the OpenFlow switches $S \in G$ into $k$ sub-nets, namely, $S D W A N_P a r t i t i o n s_{i} \forall i = 1, 2, . ., k$ according to the number of critical switches $C S \subset V$ . The resulting $S D W A N_P a r t i t i o n s_{i}$ can be defined as:

(11) $S D W A N_P a r t i t i o n s_{i} = (V_{i}, E_{i})$

Such that:

(12) $S D W A N_P a r t i t i o n s_{i} i s a c o m p o n e n t$

(13) $\sum_{i = 1}^{k} C S_{i} = 1$

(14) $\forall i \neq j \in k; S D W A N_P a r t i t i o n s_{i} \cap S D W A {N_{P a r t i t i o n s}}_{j} = {⌀}$

(15) $⋃_{i = 1}^{k} V_{i}, ⋃_{i = 1}^{k} E_{i}$

Equation (12) indicates that the sub-net of any of the $S D N_p a r t i t i o n_{i}$ is made up of connected OpenFlow switches with links. Equation (13) ensures only one critical switch $C S_{i}$ is assigned to each partition. Equation (14) implies that an OpenFlow switches $s_{i}$ can only be allocated to a single domain, while Eq. (15) ensures all the network switches are in one of the subnets. See Table 2 for the summary and description of symbols and notation used in our model.

Table 2:

Notations and symbols.

Notation	Description
$G$	SDWAN
$E$	Set of communication links in the network
$V$	Set of network nodes (comparison of both controllers and switches)
$C$	Set of SDN controllers
$C P r_{o v e r h e a d}$	Controller overhead
$S$	Set of OpenFlow switches
$S P r_{o v e r h e a d}$	Switch overhead on the controller
$C S$	Critical switches
$n C S$	Non-critical switches
$S C S$	Set of critical switches
$S n C S$	Set of non-critical switches
$S D W A N_P a r t i t i o n s_{i}$	Sub-net of OpenFlow Switches
$d i s t (s_{i} c_{j})$	Shortest distance between the controller $c_{j}$ and switch $s_{i}$ in $S d o m a i n$
$k$	An integer representing the number of $C S$ , $S D W A N_P a r t i t i o n s,$ and $C$
$n F_{i}$	New flow
$(n F_{S_{i}, S_{j}})$	Number of flow between source and destination
$X_{i m}$	${0, 1}$ binary variables indicating whether the switch $s_{i}$ is under the control of the controller $C_{m}$

DOI: 10.7717/peerj-cs.1698/table-2

Network topology read phase

Algorithm 1 reads a GraphML file containing a network topology of SDWAN located at graphml_path. An empty graph object stores the network topology as $G = (V, E)$ created in line 1 of the algorithm. V represents a set of switches in the Network, and $E$ the physical communication links between the nodes. The network switch $V$ comprised some OpenFlow switches $S$ and SDN controllers’ $C,$ $i . e ., S, C \in V$ . However, the OpenFlow switches $S$ consist of critical $C S$ and non-critical switches $n C S$ . The study defines a set of critical switches $S C S$ in Eq. (9). Algorithm 1 reads the file to generate a graph object representing the network topology in line 2. Then, the algorithm returns the graph object in line 3 to identify these critical switches. The read_graphml function is a pre-existing function that reads and parses GraphML files.

Algorithm 1:

ReadNetworkGraphTopology graph

C_{m}

Input: - graphml_path: the path to the GraphML file containing the network topology

Output: - G: a graph object representing the network topology

STAT of Algorithm

1. G ← new Graph()

2. G ← read_graphml(graphml_path)

3. For each

s_{i}

s_{j} \in G

4. Compute

N_{s p}

shortest path,

N_{s p} (s_{i} s_{j})

5. Return,

G, a n d N_{s p} (s_{i} s_{j})

END of Algorithm

DOI: 10.7717/peerj-cs.1698/table-4

Switch role and critical switch identification phase (CSIP)

CSIP distinguishes between switches based on their roles to identify critical switches within a network. Because some switches within the network have a significantly higher frequency of communication with the SDN controller for rule installation than others. These switches are called critical switches because they impact the responsiveness of the SDN controller within the network. Therefore, a switch $s_{i} \in V_{i}$ with high communication frequency with SDN controller for rule installation is considered more critical $C_{s_{i}}^{I}$ compared to an ordinary switch.

To establish the criticality of a switch $s_{i}$ , we used the switch criticality metrics in a network, and the switch flow rule requests overhead on the controller. We assume that information in the network $G_{i}$ from different sources $s_{i} \forall i = 1, 2.., N$ is propagated in parallel from the source $s_{i}$ to the destination $s_{j}$ along the shortest path (geodesic), denoted as $d_{i j}$ . Based on these assumptions, a switch $s_{i} \forall i = 1, 2.., N$ in a communication network $G_{i} = (V_{i}, E)$ is critical to the extent of its criticality factor $s_{i} C r_{f}$ . Therefore, we use the switch’s connectivity in the network and its flow rule request overhead on the controller to model the switch criticality factor $s_{i} C r_{f}$ .

To determine the switch connectivity in the network, CSIP uses Algorithm 1 to return the number of shortest paths $N_{s p}$ passing through the switch starting at $s_{i} \in V$ and ending at $s_{j} \in V$ . Thus, we calculate the metric using the formula Eq. (16). On the other hand, to compute the switch traffic overhead on a controller, we consider the weighted new flow rule request sent from the source switch to the controller due to a new flow arrival based on Eq. (6) using Eq. (17). Following that, we compute the switch criticality factor $s_{i} C r_{f}$ using the formula presented in Eq. (18) using these parameters. Finally, we demonstrate the procedure for critical switch identification in Algorithm 2.

Algorithm 2:

Critical switch identification.

Input: -

G, a n d N_{s p} (s_{i} s_{j})

Output-

{S C S, S n C S, C S_n e i g h b o u r s, d i s t a n c e}

STAT of Algorithm

S C S

← {}

S n C S

← {}

3. FOR

s_{i} \in V :

s_{i} B C

← calculate switch connectivity in

G

using Eq. (16)

s_{i} n F_{i}

← calculate switch flow rule request using Eq. (17)

s_{i} C r_{f}

← calculate the switch criticality factor using Eq. (18)

t o t a l_s_{i} C r_{f}

← sum_of_values

(s_{i} C r_{f})

a v e_s_{i} C r_{f}

←

t o t a l_s_{i} B C

/length_of_values

(s_{i} C r_{f})

9. FOR each

s_{i}

, in

(s_{i} C r_{f})

10. IF

(s_{i} C r_{f})

a v e_s_{i} C r_{f}

11. add

s_{i}

and

s_{i} C r_{f}

S C S

12. ELSE:

13. add

s_{i}

and

s_{i} C r_{f}

S n C S

14.

C S_n e i g h b o r s

← {}

15. FOR each

s_{i}

, in

s_{i} C r_{f}

16. add a list of

C S

’s neighbours to

C S

_neighbours.

17.

d i s t a n c e

← {}

18. FOR each

C S

S C S

19. For

s_{i}

, distance in shortest_path_length from

C S

in G:

20. add (

s_{i}

C S

) and distance to

d i s t a n c e

21. return SCS, SnCS, CS_neighbours, distance

END of Algorithm

DOI: 10.7717/peerj-cs.1698/table-5

(16) $s_{i} B C = \sum_{s_{i} s_{j} \in V, s_{i} \neq s_{j}} \frac{N_{s p} (s_{i} s_{j} | V)}{N_{s p} (s_{i} s_{j})}$

(17) $s_{i} n F_{i} = \sum_{s_{i} \in S} (n F_{S_{i}, c_{m}})$

(18) $s_{i} C r_{f} = s_{i} B C + s_{i} n F_{i}$

In (lines 1–2), Algorithm 2 initializes two empty dictionaries, $S C S a n d S n C S$ . The dictionaries are used to store critical-switch and non-critical-switch information, respectively. For each switch $s_{i} \in V$ in the SDWAN $G$ , Algorithm 2 determines whether the switch $s_{i}$ is critical or non-critical using Eq. (9) and by calculating its criticality factor $(s_{i} C r_{f})$ using Eq. (18). The total $(t o t a l_s_{i} C r_{f})$ and average $(a v e_s_{i} C r_{f})$ criticality factors for all switches in the network are also computed (lines 3–8). Algorithm 2 then checks the criticality factor $(s_{i} C r_{f})$ of each switch $s_{i}$ in the network topology G against the average criticality factor value $(a v e_s_{i} C r_{f})$ (lines 10–11). If $(s_{i} C r_{f})$ is greater than $(a v e_s_{i} C r_{f})$ , the switch is classified as critical and added to the set of critical_switch $S C S$ containers along with its criticality factor. Otherwise, it is classified as non-critical and added to the collection of non_critical_switch $n S C S$ containers (lines 12–13).

Next, for each critical switch (CS) in the $S C S$ container, Algorithm 2 retrieves the list of its neighbours and calculates its shortest path distance to all other switches in the network topology. The resulting information is added to the CS_neighbors and distances containers (lines 14–20). Finally, Algorithm 2 returns the sets of critical_switch, non_critical_switch, critical_switch_neighbors, and distances in (line 21).

Network partition based on switch criticality

The study designed a CSANP to partition the SDWAN $(G$ ) into smaller networks based on the number of critical switches ( $n u m_C S)$ . The CSANP collects inputs from Algorithm 2, where the critical switches of $G$ are identified. The input parameters include the set of critical switches $(S C S)$ , non-critical switches $(S n C S)$ . The procedure is as shown in Algorithm 3. CSANP starts by initializing the number of Critical Switches (num_CS) and non-critical switches (num_nCS) on lines 1 and 2. It then calculates the average number of non-Critical Switches to be associated to each critcal switch and the remaining non-critical switches (num_CS_plus) on lines 3 and 4. The SDWAN_Partitions list is initialized with empty lists, where each list represents a partition associated with a critical switch (CS), on line 5. The algorithm then iterates through each non-critical switch (s_j) in SnCS (line 6) and determines its closest critical switch (CS) based on the minimum distance (lines 7 to 14). The non-critical switch is then assigned to the corresponding partition in SDWAN_Partitions (line 14). Next, the algorithm iterates through each non-critical switch again (s_j) (line 15) and assigns it to the appropriate partition in SDWAN_Partitions based on balancing criteria (lines 17 to 29). If a partition has fewer than avr_num_nCS, the current non-critical switch is added to it (line 24). If the partition has avr_num_nCS and there are remaining non-critical switches (num_CS_plus), one of them is added to the partition (lines 26 to 28). If the partition has avr_num_nCS, and there are no remaining non-critical switches, a new partition is created for the current non-critical switch (line 30). The process continues until all non-critical switches are assigned to partitions, and the resulting SDWAN_Partitions list contains the partitions, each associated with its respective critical switch. Finally, the algorithm returns the list of SDN $[{S D W A N_P a r t i t i o n s}, {S D W A N_P a r t i t i o n s} \dots \dots \dots | n u m_C S |]$ in line 31. Refer to the network partition formation phase of Fig. 2 for the flowchart for the algorithm.

Algorithm 3:

Critical switch aware network partition (CSANP).

Input: (G, SCS, SnCS)

Output: SDWAN_Partitions

STAT of Algorithm

1. num_CS = len(SCS)

2. num_nCS = len(SnCS)

3. avr_num_nCS = num_nCS // num_CS

4. num_CS_plus = num_nCS % num_CS

# Add all Critical Switches to SD-WAN partitions

5. SDWAN_Partitions = [[] for _ in range(num_CS)]

# Assign non-Critical Switch to Critical Switch based on minimum distance

6. For s_j in SnCS:

7. closest_CS = None

8. min_distance = float(‘inf’)

9. For i, si in enumerate(SCS):

10. dist = distance[s_i][s_j]

11. If dist < min_distance:

12. min_distance = dist

13. closest_CS = i

14. SDWAN_Partitions[closest_CS] = SDWAN_Partitions[closest_CS] + [s_j]

# Balance partitions and assign non-Critical Switches to Critical Switch

15. For i, s_j in enumerate(SnCS):

16. closest_CS = None

17. min_distance = float(‘inf’)

18. For j, s_i in enumerate(SCS):

19. dist = distance[s_i][s_j]

20. If dist < min_distance:

21. min_distance = dist

22. closest_CS = j

23. cluster_index = closest_CS

24. If len(SDWAN_Partitions[cluster_index]) < avr_num_nCS:

25. SDWAN_Partitions[cluster_index] = SDWAN_Partitions[cluster_index] + [sj]

26. Elif len(SDWAN_Partitions[cluster_index]) < avr_num_nCS + 1 and num_CS_plus > 0:

27. SDWAN_Partitions[cluster_index] = SDWAN_Partitions[cluster_index] + [s_j]

28. num_CS_plus -= 1

29. Else:

# If no condition is met, create a new partition for the non-Critical switches

30. SDWAN_Partitions = SDWAN_Partitions + [[s_j]]

31. return SDWAN_Partitions

END of Algorithm

DOI: 10.7717/peerj-cs.1698/table-6

Critical switch aware controller placement (CSACP)

The proposed Critical Switch Aware Controller Placement (CSACP) algorithm is responsible for placing an SDN controller in each of the resulting network partitions (subnets) produced by CSANP. This placement problem is a variant of a facility location problem. Therefore, for each of the resulting subnets $[{S D W A N_P a r t i t i o n s_{1}}, \dots {S D W A N_P a r t i t i o n s_{| n u m_C S |}}]$ obtained from the CSANP, we designed a CSACP algorithm to place the SDN controller on each $S D W A N_P a r t i t i o n s_{i} = (V_{i}, E_{i})$ within the shortest distance of each demand point in the subnets. We assigned $C$ to represent the set of controllers $c_{j} \in C \forall j = 1, 2…, m$ for the $k$ sub-nets. Next, for each, $\forall S D W A N_P a r t i t i o n s_{i}$ , our placement model maps the controller $c_{j} \in C \forall j = 1, 2…, m$ to the demand points $s_{i} \in V,$ which are the OpenFlow switches, in a way that the $d i s t (s_{i} c_{j})$ is the shortest distance between the candidate controller locations $j \in S D W A N_P a r t i t i o n s_{i}$ and the mapped controller $c_{j} \in C$ . Thus, the proposed CSACP algorithm finds a suitable position in each resulting partition to place the controller. Algorithm 4 provides a detailed description of the proposed controller placement method.

Algorithm 4:

Critical switch aware controller placement (CSACP).

Input:

{S C S, S n C S}

[{S D W A N_P a r t i t i o n s_{1}}, \dots {S D W A N_P a r t i t i o n s_{| n u m_C S |}}]

Output- controller_positions

STAT of Algorithm

1. controller_positions = {}

2. For SDWAN_Partitions_num, partition in enumerate(SDWAN_Partitions) Do

3. max_critical_switch = null

m a x_s_{i} C r_{f}

= -1

5. For switch in partition, Do

6. If switch in critical_switch and critical_switch[switch] >

m a x_s_{i} C r_{f}

Then

7. max_critical_switch = switch

m a x_s_{i} C r_{f}

= critical_switch[switch]

9. End If

10. End For

11. distances_within_partition = {}

12. For a node in partition, Do

13. If the node in non_critical_switch, Then

14. distances_within_partition[node] = distances[(node, max_critical_switch)]

15. End If

16. End For

17. min_distance_node = null

18. min_distance = infinity

19. For a node in distances_within_partition, Do

20. If distances_within_partition[node] < min_distance, Then

21. min_distance_node = node

22. min_distance = distances_within_partition[node]

23. End If

24. End For

25. controller_positions[SDWAN_Partitions_num] = (max_critical_switch, min_distance_node)

26. End For

27. return controller_positions.

END of Algorithm

DOI: 10.7717/peerj-cs.1698/table-7

(19) $M i n \frac{1}{| S D W A N_P a r t i t i o n s_{i} |} \sum_{s_{i} \in S D W A N_P a r t i t i o n s_{i}} d i s t (s_{i} c_{j})$

Such that

(20) $s_{i}, c_{j} \in S D W A {N_{P a r t i t i o n s}}_{i}$

The proposed CSACP algorithm takes inputs from CSANP (Algorithm 2), which includes the SDWAN partitions, critical and non-critical switches, and their criticality factors. Each partition is a set of switches within the SDWAN network. The algorithm initializes an empty dictionary called controller_positions to store the controller positions for each SDWAN partition in line 1. Then, for each partition in the input set of partitions, the algorithm identifies the critical switch with the highest criticality factor $m a x_s_{i} C r_{f}$ . In (lines 2–11), Algorithm 4 calculates the distance to the identified critical switch using a pre-computed distance metric stored in a distance dictionary for each non-critical switch in the partition. Next, the algorithm finds the non-critical switch within the partition that has the minimum distance to the identified critical switch and assigns it as the controller position for that partition. The algorithm then stores the controller position for that partition in the controller_positions dictionary in (lines 12–26). Finally, the algorithm returns the controller_positions dictionary as the algorithm output in line 27.

Experimentation setup and performance evaluation of CPCSA

In this section, the performance of CPCSA is evaluated and compared with other representative solutions in the literature. The study utilizes three (3) real network topologies obtained from the Internet Topology Zoo (ITZ) (A. G. University of Adelaide, 2023) and randomly generates topologies for conducting the experiments. The database provides researchers access to hundreds of real network topologies from various service providers. Thus, the study selects AsnetAm, Arpanet19728, and ARNES networks for the experiments. Table 3 gives additional information on other aspects of the chosen network topologies, which vary in size and structure. The partitioning phase is performed offline with a script written in Python 3.8.0 and NetworkX components. The experiment uses Mininet version 2.3.0 to build the topologies of these partitions with an OpenvSwitch for interaction with a Ryu SDN controller in each partition based on OpenFlow v1.5.1 specifications. The article borrows traffic matrix scenarios in the GÉANT network (Uhlig et al., 2006) for understanding traffic patterns. The traffic matrix of (Uhlig et al., 2006) describes the traffic between nodes and its transfer speed, highlighting what constitutes a new flow. A D-ITG utility injects a TCP/UDP flow on 1,024 Mbps transmission lines of the Mininet architecture to generate the traffic. Hence, the study model, one new flow for every 100,000 KB, exchanged, according to Poisson traffic distribution in terms of Packet Inter Departure Time (PIDT). The reliance of the packet_IN message on whether the switch piggybacked the first packet of a flow to a controller (Yusuf et al., 2023c). The article considers its size and Packet count as in Obadia et al. (2015) to account for it. Additionally, as proved in Obadia et al. (2015), there must be a packet OUT message (flow_mod Packet) for every packetIN message; thus, the study considers their sizes and packet count equal.

Table 3:

Topologies information and traffic information.

Topologies information					Traffic information
Topology	Number switches	Number of links	Density	Ave SBF	New flow	Packet_IN msg size	Packet_OUT msg size
Arpanet19728	29	32	0.0788	0.136	For every 100,000 Kb	80 bytes	80 bytes
ARNES	34	47	0.0837	0.076	For every 100,000 Kb
AsnetAm	65	79	0.0380	0.044

DOI: 10.7717/peerj-cs.1698/table-3

We start off the evaluation of CPCSA by providing a visual representation of its controller placement result in Fig. 3. We then presented the overhead incurred by the controller placed in a network using the proposed CPCSA compared to other related CPP solutions in Fig. 4. While in Fig. 5, the study investigates the impact of CPCSA on fault tolerance by evaluating the rate of control packet loss. Lastly, the evaluation of Throughput and average switch-to-controller Latency is done in Figs. 6 and 7, respectively. We conduct all the experiments on a machine with Intel(R) Core (TM) i7-10750H CPU @ 2.60 GHz, 2.59 GHz, and 16.0 GB memory.

Figure 3: (A–D) Arpanet topology; (E–H) Arnes topology; (I–L) AsnetAm topology.

Download full-size image

DOI: 10.7717/peerj-cs.1698/fig-3

Figure 4: (A–D) Overhead.
Effect of flows installation cost on the overhead on the number of controllers.

Download full-size image

DOI: 10.7717/peerj-cs.1698/fig-4

Figure 5: (A and B) Packet loss result.
Comparison of packet loss.

Download full-size image

DOI: 10.7717/peerj-cs.1698/fig-5

Figure 6: (A and B) Throughput.
Comparison of throughput.

Download full-size image

DOI: 10.7717/peerj-cs.1698/fig-6

Figure 7: (A and B) Latency.
Relationship between switch to controller latency.

Download full-size image

DOI: 10.7717/peerj-cs.1698/fig-7

Results

Network partitions and controller placement positions

The diagrams presented in Figs. 3A–3I illustrate the network partitions and selected positions for controller placement as determined by the proposed CPCSA algorithm. Figure 3 depicts the outcomes of the controller placement output when applied to the Arpanet19728, ARNES, and AsnetAm topologies. As demonstrated in Figs. 3A, 3E, and 3I, before network partitioning, node 4, node 7, and node 22 are designated as the controller positions. This selection occurs based on the switch criticality factors $s_{i} C r_{f}$ ranging from 0.25, 0.50–0.61, to 0.59–0.66 in the respective topologies. Conversely, as shown in Figs. 3B, 3F and 3J, when the switch criticality factors are 0.25, 0.18–0.49, and 0.27–0.55 in the corresponding networks, the networks are partitioned into two subnets. Consequently, in Arpanet19728, nodes 4 and 13 are chosen as the controller positions, while in ARNES, nodes 7 and 30 are selected. In the AsnetAM topology, the controller positions are nodes 22 and 7. Furthermore, by reducing the switch criticality factors $s_{i} C r_{f}$ to 0.22, 0.14–0.15, and 0.15–0.25, the respective networks experienced partitioning into four subnets. This resulted in the inclusion of nodes 23 and 28 as additional controller positions in the Arpanet19728 topology. Similarly, in the case of ARNES, nodes 23 and 29 were selected as new placements, while for AsnetAM topology, CPCSA chooses nodes 8 and 26 to place the new controllers. Please refer to Figs. 3D, 3H, and 3L for visualization

Controller overhead

Figure 4 shows the accumulated controller’s rule installation overhead in the Arpanet19728, ARNES, and AsnetAm network topologies with SPDA (Guo et al., 2022), gravCPA (Wang, Ni & Liu, 2022), and the proposed CPCSA, respectively. The experiment results show that CPCSA incurred lower rule installation overhead than SPDA (Guo et al., 2022) and gravCPA (Wang, Ni & Liu, 2022) in all the topologies. As shown in Fig. 4A, the proposed CPCSA had reduced the SDN controller’s overhead compared to SPDA and gravCPA in the AsnetAM topology by 63% and 49%, respectively. Meanwhile, in Fig. 4B, with the Arnes topology, the proposed technique is shown to cut the overhead by 54% and 36%. Lastly, CPCSA minimizes the overhead of SPDA (Guo et al., 2022) and gravCPA (Wang, Ni & Liu, 2022) by 63% and 51% in the Arpanet19728 topology, as revealed in Fig. 4C. The achievement of the overhead reduction is attributable to the control of the number of critical switches CPCSA assigns to a single SDN controller. A switch is critical if it continually appears along the shortest path of many dissimilar host-to-destination communicating pairs. This type of switch receives an augmented number of rule installation instructions from the controller on what to do with the flow. Because, by default, flows are usually routed along the shortest path from the source to the destination host in most networks. Thus, the controller with a higher number of critical switches in a partitioned SDWAN incurs higher overhead. The additional controller overhead will amount to the number of switches assigned to the controllers by a factor of their generated control traffic.

Control packet loss

In this section, this study measures the impact of control packet loss during switch-to-controller communication to verify CPCSA’s fault-tolerance benefits. High control plane overhead can induce a network problem, which can cause some switches to lose connections with their controllers, resulting in dropped packets. The study expects CPCSA to reduce the possibility of Network failures owing to excessive controller overhead, which can lead to substantial packet loss. Because, by design, the CPCSA differentiates among network switches and restricts the number of critical switches for each partition. We use Python 3.8.0 with NetworkX and Matplotlib library components for simulation. However, unlike the previous experiments with real network topologies, fully connected networks are randomly generated using Barabási–Albert (BA) model. After 50 repeated experiments, the average results findings in comparison to alternative approaches are shown in Fig. 5. The y and x-axis in Fig. 5 display the average control packet loss as a function of the x-axis representation of the total network nodes, n. As expected, CPCSA has the lowest average packet loss rate of the four routing algorithms due to minimising the controller’s overhead. On DBCB, the proposed CPCSA reduced packet loss by 31%, while on SPDA and gravCPA, it reduced it by 61%. The minimum controller’s overhead correlates better with preventing network failure and lower control packet loss. Therefore, a low average control packet loss indicates the technique’s ability to avoid network faults due to high overhead.

Throughput

Figure 6 displays the network throughput evaluation result between the proposed CPCSA and the benchmark algorithms. The Throughput metric gives information about the performance of the techniques regarding the number of control data packets sent from a source host and successfully delivered at the destination host during a transmission period (Guo et al., 2022). The throughput metric is relevant in assessing CPCSA performance about how it reacts to network-changing events that can trigger flow setup requests or failure. Figure 6A shows the result of CPCSA’s throughput with different numbers of controllers. Figure 6B shows the CPCSA’s Throughput vs that of gravCPA (Ali, Lee & Roh, 2019) and SPDA (Obadia et al., 2015). As can be seen from Fig. 6B, CPCSA outperformed the benchmarked reference algorithms. Comparatively, the algorithm improved the throughput achieved by gravCPA and SPDA by 16% and 18%, respectively. This improvement indicates that the methodology adopted by CPCSA to minimise the controller’s overhead significantly influenced the control packet delivery rate. Thus, this analysis affirms the research question: “Can controlling the number of critical switches under the control of an SDN controller improve the Quality of Service in a network?”

Switch to controller average latency

In this subsection, the study demonstrates how the average switch-controller latencies respond when a controller is appropriately placed in the subnets of the network partitioned while considering critical switches. For validation and revelation of results, the study compares the performance of CPCSA with that of other controller placement solutions that incorporate a network partitioning strategy and allocation of a controller to each subnetwork. In the experiments, we ensure that all the benchmarked algorithms deploy the same number of controllers as CPCSA in the network for a fair evaluation. Therefore, given a controller $c_{j} \in C$ and the switches $s_{i} \in S D W A N_P a r t i t i o n s_{i}$ in the sub-network, the CPCSA uses the relation in Eq. (17) to measure the latency metrics. Based on the result obtained, Fig. 7 displays the relationships between the average switch-controller latencies with the number of controllers and partitions varying from 1 to 4 on three (3) topologies. As shown in Fig. 7, the result exhibits a monotonic decreasing trend in the switch-controller Latency with an increasing number of partitions and controllers. We observed this pattern throughout all four (4) algorithms under study. i.e., Increasing the number of controllers and partitions causes all the compared algorithms to behave identically regarding average switch-controller control packet processing delay. However, CPCSA performs significantly better when compared to SPDA, DBCP, and gravCPA algorithms. As shown in Fig. 7A, the proposed CPCSA reduces the average switch-to-controller Latency by 27%, 12%, and 3%, respectively, compared to SPDA (Guo et al., 2022), DBCP (Liao et al., 2017), and gravCPA (Wang, Ni & Liu, 2022) algorithms when the Algorithms partitioned the network into 4.

Conclusions

The controller placement algorithm with network partition based on critical switch awareness (CPCSA) is a novel approach to address the challenge of transient congestion due to controllers’ overhead in the existing controller placement problems (CPP) solutions in SDN. CPCSA identifies the set of critical switches in a network to guide the network partition procedure for finding the optimal number of controllers and placement in the network. The algorithm has been implemented and evaluated in a laboratory testbed in a series of comparative experiments with similar solutions using multiple Real life network topologies from ITZ. The comparative experiments demonstrate CPCSA’s effectiveness in reducing control message overhead, control packet loss, switch-to-controller latency, and improved throughput. The results show that the proposed solution has achieved an aggregate reduction in the controller’s overhead by 73%, loss by 51%, and latency by 16% while improving throughput by 16% compared to the benchmark algorithms. However, the proposed scheme does not support heterogeneous controllers and has no defense mechanism against vulnerabilities such as DDOS, common-mode fault, etc.

For future research, we plan to update the CPCSA controller placement model with traffic flow behavioural quality of service requirements for consideration. It would be intriguing to employ machine learning techniques such as deep learning to study flow behaviour based on flow history for the classification. Considering this would support designing a controller placement with traffic dynamics awareness. The aim is to partition the network and place a controller while considering the traffic pattern in the network. Another exploration avenue could be integrating the algorithm with heterogeneous controllers’ support. We can see the motivation for these from many perspectives. First, a homogeneous CP provides a potential security risk due to the controllers’ common-mode fault, often known as a common vulnerability point. Assume enemies are aware of the vulnerability of one controller; in this instance, they can easily knock down the entire network by exploiting the controller’s shared vulnerability. Second, interoperability between various controller platforms and traditional IP networks can encourage and facilitate the commercial adoption of SDN globally. Very little research has examined this direction thus far. Therefore, undertaking further research in this direction will be a valuable contribution.

Supplemental Information

CPCSA Main Code.

Source code of the main file that import the CPCSA as a module.

DOI: 10.7717/peerj-cs.1698/supp-1

Download

CPCSA code.

DOI: 10.7717/peerj-cs.1698/supp-2

Download

Raw Data results.

DOI: 10.7717/peerj-cs.1698/supp-3

Download

[1] A. G. University of Adelaide. 2023. The Internet topology zoo—dataset.

[2] Ahmad S, Mir AH. 2021. Scalability, consistency, reliability and security in SDN controllers: a survey of diverse SDN controllers. Journal of Network and Systems Management 29(1):1-59

[3] Ali J, Lee S, Roh BH. 2019. Poster: using the analytical network process for controller placement in software defined networks.

[4] Ali J, Roh BH. 2022. An effective approach for controller placement in software-defined internet-of-things (SD-IoT) Sensors 22(8):2992

[5] Aoki H, Shinomiya N. 2015. Network partitioning problem for effective management of multi-domain SDN networks. International Journal on Advances in Networks and Services 8(3 & 4):171-181

[6] Aoki H, Shinomiya N. 2016. Controller placement problem to enhance performance in multi-domain SDN networks.

[7] Bannour F, Souihi S, Mellouk A. 2017. Scalability and reliability aware SDN controller placement strategies.

[8] Curtis AR, Mogul JC, Tourrilhes J, Yalagandula P, Sharma P, Banerjee S. 2011. DevoFlow: scaling flow management for high-performance networks. Computer Communication Review 41(4):254-265

[9] Dvir A, Haddad Y, Zilberman A. 2018. Wireless controller placement problem.

[10] Elsayed MS, Le-Khac NA, Dev S, Jurcut AD. 2019. Machine-learning techniques for detecting attacks in SDN.

[11] Firouz N, Masdari M, Sangar AB, Majidzadeh K. 2021. A novel controller placement algorithm based on network portioning concept and a hybrid discrete optimization algorithm for multi-controller software-defined networks. Cluster Computing 24(3):2511-2544

[12] Guo J, Yang L, Rincon D, Sallent S, Chen Q, Liu X. 2022. Static placement and dynamic assignment of SDN controllers in LEO satellite networks. IEEE Transactions on Network and Service Management 19(4):4975-4988

[13] Heller B, Sherwood R, Mckeown N. 2012. The controller placement problem. Computer Communication Review 42(4):473-478

[14] Hu T, Guo Z, Baker T, Lan J. 2017. Multi-controller based software-defined networking: a survey. IEEE Access 99:1

[15] Isyaku B, Bakar KBA. 2023. Managing smart technologies with software-defined networks for routing and security challenges: a survey. Computer Systems Science and Engineering 47(2):1839-1879

[16] Isyaku B, Bin Abu Bakar K, Nagmeldin W, Abdelmaboud A, Saeed F, Ghaleb FA. 2023. Reliable failure restoration with Bayesian congestion aware for software defined networks. Computer Systems Science and Engineering 46(3):3729-3748

[17] Isyaku B, Bin Abu Bakar K, Yusuf MN, Mohd Zahid MS. 2021. Software defined networking failure recovery with flow table aware and flows classification.

[18] Isyaku B, Mohd Zahid MS, Bte Kamat M, Abu Bakar K, Ghaleb FA. 2020. Software defined networking flow table management of OpenFlow switches performance and security challenges: a survey. Future Internet 12(9):147

[19] Killi BPR, Rao SV. 2019. Controller placement in software defined networks: a comprehensive survey. Computer Networks 163(3):106883

[20] Killi BR, Reddy EA, Rao SV. 2019. Game theory based network partitioning approaches for controller placement in SDN. Lecture Notes in Computer Science 11227:245-267

[21] Kobo HI, Abu-Mahfouz AM, Hancke GP. 2019. Efficient controller placement and reelection mechanism in distributed control system for software defined wireless sensor networks. Transactions on Emerging Telecommunications Technologies 30(6):1-19

[22] Kuang H, Qiu Y, Li R, Liu X. 2018. A hierarchical K-means algorithm for controller placement in SDN-based WAN architecture.

[23] Li F, Xu X, Han X, Gao S, Wang Y. 2019. Adaptive controller placement in software defined wireless networks. China Communications 16(11):81-92

[24] Liao J, Sun H, Wang J, Qi Q, Li K, Li T. 2017. Density cluster based approach for controller placement problem in large-scale software defined networkings. Computer Networks 112(4):24-35

[25] Liu J, Liu J, Xie R. 2016. Reliability-based controller placement algorithm in software defined networking. Computer Science and Information Systems 13(2):547-560

[26] Liu J, Shi Y, Zhao L, Cao Y, Sun W, Kato N. 2018. Joint placement of controllers and gateways in SDN-enabled 5G-satellite integrated network. IEEE Journal on Selected Areas in Communications 36(2):221-232

[27] Manoharan GRR. 2021. Enhanced optimal placements of multi‐controllers in SDN. Journal of Ambient Intelligence and Humanized Computing 12(7):8187-8204

[28] Obadia M, Bouet M, Rougier JL, Iannone L. 2015. A greedy approach for minimizing SDN control overhead.

[29] Uhlig S, Quoitin B, Lepropre J, Balon S. 2006. Providing public intradomain traffic matrices to the research community. Computer Communication Review 36(1):83-86

[30] Wang C, Ni H, Liu L. 2022. GravCPA: controller placement algorithm based on traffic gravitation in SDN. Journal of Control Science and Engineering 2022(9):1-12

[31] Wang G, Zhao Y, Huang J, Duan Q, Li J. 2016. A K-means-based network partition algorithm for controller placement in software defined network.

[32] Wang G, Zhao Y, Huang J, Wu Y. 2018. An effective approach to controller placement in software defined wide area networks. IEEE Transactions on Network and Service Management 15(1):344-355

[33] Xiao P, Li Z, Guo S, Qi H, Qu W, Yu H. 2016. A K self-adaptive SDN controller placement for wide area networks. Frontiers of Information Technology & Electronic Engineering 17(7):620-633

[34] Xiao P, Qu W, Qi H, Li Z, Xu Y. 2014. The SDN controller placement problem for WAN.

[35] Yan B, Liu Q, Shen J, Liang D, Zhao B, Ouyang L. 2021. A survey of low-latency transmission strategies in software defined networking. Computer Science Review 40(6):100386

[36] Yang K, Guo D, Zhang B, Zhao B. 2019a. Multi-controller placement for load balancing in SDWAN. IEEE Access 7 167278–167289

[37] Yang K, Zhang B, Guo D, Lin M, de Cola T. 2019b. Partitioned controller placement in SDWANs for reliability maximization with latency constraints.

[38] Yusuf MN, Bakar Kbin A, Isyaku B, Osman AH, Nasser M, Elhaj FA. 2023a. Adaptive path selection algorithm with flow classification for software-defined networks. Mathematics 11(6):1404

[39] Yusuf MN, Bin Abu Bakar K, Isyaku B, Mukhlif F. 2023b. Distributed controller placement in software-defined networks with consistency and interoperability problems. Journal of Electrical and Computer Engineering 2023:1-33

[40] Yusuf MN, Bin Abu Bakar K, Isyaku B, Saheed AL. 2023c. Review of path selection algorithms with link quality and critical switch aware for heterogeneous traffic in SDN. International Journal of Electrical and Computer Engineering Systems 14(3):345-470

[41] Zhao G, Huang L, Yu Z, Xu H, Wang P. 2017a. On the effect of flow table size and controller capacity on SDN network throughput.