Examining the Quality Metrics of a Communication Network with Distributed Software-Defined Networking Architecture

1  Introduction

In today’s advanced technological environment, internet service providers increasingly manage demands for ultra-high-speed connectivity across different remote networks. By the end of 2023, approximately 29.3 billion different remote networks should be connected via modern network resources [1]. Optimizing the performance of any network mostly involves increasing its throughput, ensuring that it can process large amounts of data concurrently, improving data transfer rates, and minimizing latency. Software-defined networking (SDN) can ease the optimization process with a unique centralized control arrangement for managing data traffic and the ability to overcome the challenges associated with traditional networks in terms of scaling, controllability, and reliability [2]. SDN architectural framework has a three-layered structure (1-application layer, 2-control layer, and 3-data layer). Using a northbound Application Program Interface (API), the programmable logic is easily transferred to the controller at the control layer from the application layer. SDN controller updates routing tables of various networking devices in the data plane and coordinates and manages the data flow over various topologies via the southbound interface. SDN is becoming a key component of modern network infrastructures because of its two programmable properties that greatly enhance network scalability: (1) The segregation of the data plane from the control plane, augmenting network controllability, as illustrated in Fig. 1. (2) The instructions can easily be forwarded to the SDN controller that can effectively process data traffic management over the whole network architecture [3], providing augmented controllability. Due to centralized control arrangements, congestion in SDN-based networks can easily be managed compared to traditional networks [4]. In an SDN-based network, the segregation of control and data planes means all the flow management functionality of network devices (routers, switches, etc.) is managed by the SDN controller. The unified controller is used for small to medium-sized networks and multiple controllers (logically distributed/logically centralized). This functionality enhances the Quality of Service (QoS) parameters; the logical reasons are as follows:

➢   The separation of control and data planes with all flow management control is with an SDN controller, which can have dynamic flow control ability in an SDN-based network by managing network traffic flow based on real-time conditions.

➢   The separation of planes with the controller incharge provides reconfiguration of network paths, avoidance of congestion, application of prioritization of network traffic, enhanced throughput, greater data transfer, maximum available bandwidth, and ensuring low latency. These factors result in enhanced network performance and greater QoS parameter values.

➢   The segregation of control and data planes in an SDN-based network provides additional facilities to optimize resource allocation based on the current demands of users by modifying the controller operation mode.

➢   The programmability of the control plane allows quick implementation of new applications and services based on the QoS demands of any network environment.

➢   The segregation of data and control planes in SDN provides an agile, responsive, and dynamically manageable network, resulting in enhanced QoS parameters.

Figure 1: Difference between the traditional and SDN-based networks’ operational models

There are two configuration options for the SDN controller: (a) centralized mode and (b) distributed mode [5]. The SDN controller operates best in centralized mode for small- to medium-sized networks. However, there can be significant delays in data transmission when large, multi-component Data Center Networks (DCNs) use a single, centralized model-based SDN controller, which provides slower controller operation and causes traffic congestion and delay. This delay can exacerbate network issues by creating backlogs of data that need to be processed [6]. The study was conducted in [7] to evaluate the performance of a single NOX controller for processing a large amount of data to pass through a large DCN. To mitigate latency issues within large-scale SDN-based DCNs using a single controller, the SDN controller must be framed in either logically centralized or distributed [8,9] control mode. The research articles [10,11] suggest the resource management issue and its mitigation in the SDN network.

1.1 A Centralized Controlled System Using an SDN Controller

This controller design distributes Hypertext Transfer Protocol (HTTP) requests from different hosts equally by deploying numerous high-performance SDN controllers across DCNs with exact synchronization. In comparison to the single SDN controller mode, this logically centralized SDN controller configuration, as shown in Fig. 2, improves QoS characteristics in bigger DCNs. On the other hand, maintaining strict synchronization between these controllers may cause compatibility issues. The arrangement’s primary drawback is the difficulty of synchronization between various controllers. Under some circumstances, synchronizing these controllers with un-versioned third-party programs may cause unpredictable and unstable network behavior, ultimately leading to system failure.

Figure 2: Logically centralized SDN controller configuration

1.2 Distributed Controlled Arrangement with an SDN Controller

This SDN control architecture uses a decentralized method that eliminates the need for controller synchronization in a distributed network configuration. The vast network of Large DCNs is separated into smaller domains, in contrast to the use of separate controllers in master and slave versions, as explained in Section 1.1. Every controller stores vital flow information inside its Storage Area Network (SAN) and controls flow within its assigned domain. The network administrator can use this data to receive more instruction, which improves localized flow control inside each domain. Due to this solution, the strict synchronization requirement of distributed controllers is removed, which is necessary for global control of the distributed SDN network, as outlined in Section 1.1. Comparing this SDN controller configuration to a centralized SDN control framework, one can get higher efficiency, faster response rates, and more versatility. Fig. 3 outlines the structure for logically distributed SDN control mode.

Figure 3: SDN controller set up in a control mode

This SDN control configuration is frequently used by software-defined wide-area networks (SD-WANs). The research articles [12,13] demonstrate how SDN is used in distributed controlled structures regarding Google and Microsoft’s network development. These employ distributed network devices to offer their users services. Compared to typical networking systems, the quality characteristics with a hierarchical distributed control arrangement are significantly superior. Fig. 4 shows the hierarchical distributed control configuration. The controller of each domain in the network is in charge of it. Under the supervision of a global controller, each route controller controls its local controller. That local domain controller manages the data flow inside a domain. When data travels outside the local controller’s controlling area, the route controller will take control of the flow. The research papers [14–16] raise attention to the issue with the “east-west” bound interface between multiple controllers.

Figure 4: SDN controller arranged in hierarchical, logically distributed mode

1.3 Research Objectives

The main goal of this study is to implement the suggested method (ISSLM) to control network server loads effectively and improve the QoS. Many HTTP servers can handle HTTP queries within the SDN architecture. However, server overload may occur if all HTTP request flows are directed toward a single server without considering network server load management. Consequently, this results in (a) overcrowded links, (b) HTTP queues, and (c) end-to-end delays. In the end, this decrease in the QoS characteristics of the network may cause the network to collapse due to total network failure. The following are the main objectives of this research project.

1.3.1 To Deploy SDN in Large DCNs

In this method, the large DCN network is divided into smaller domains, and every controller is responsible for flow control inside its domain and storing necessary flow data in its SAN for the network administrator to instruct the controller further to manage the flow inside that local domain better as compared to the logically centralized method.

1.3.2 To Enhance QoS (Bdmax, Th, DTransfer, etc.) Parameters

A. Self-Adapting Configuration:

The Request Per Second (RPS) load on each server is calculated by adaptation of the following procedure:

➢   Firstly, the APACHE program must be installed on every HTTP server.

➢   Then, the GRAFANA program is started on every server. PROMETHEUS is a data source, making collecting HTTP server data logs possible.

➢   Prom_QL queries are written to control the RPS matrices for every server, considering settings like RAM and default time.

➢   Installing and integrating the POX controller with the PSUTIL Python library function.

➢   Using PSUTIL, endpoints are created so that the POX controller may access all of the servers’ RPS matrix values.

➢   These RPS matrices are used to determine the load on every HTTP server.

B. Adaptive Optimization:

To balance server loads, the ISSLM algorithm takes three factors into account: (1) Comparing each server’s RPS values to a benchmark server load (Sload) measurement. When a server’s load exceeds the reference server load (Sload) in an SDN network, it is considered overloaded and is removed from the server list. When this occurs, HTTP flows are diverted to the server with the lowest server load value among the servers accessible on the network, within the acceptable range of the reference server load (Sload) value. (2) HTTP flows are routed to the server in the SDN network with the fewest active connections if the criterion mentioned above is not satisfied. (3) The server with the fastest response time.

1.4 Work Contribution

The main goal of this study is to apply a suggested load balancing algorithm, called ISSLM, for network servers to improve the QoS metrics, which include maximum bandwidth (Bdmax), throughput, data transfer, and delay in a chosen or parameterized SDN based DCN. The suggested working model, which uses the ISSLM algorithm to accomplish the study goals, is shown in Fig. 5.

Figure 5: A proposed working model for obtaining research objectives by the proposed algorithm (ISSLM)

A large-scale SDN-based virtual network was created in the Mininet environment to study network quality factors to achieve the previously indicated goal. According to this research study, the chosen or parameterized network is simulated in three steps:

➢   In the first step, we configured an SDN network with only one controller—the POX controller—to manage the data flow over the network. The Mininet environment is used to set up this network configuration. In particular, this configuration does not include a server load management algorithm.

➢   In the second step, we keep the SDN network operational using a single controller (POX) set up in the Mininet environment, which controls data traffic flow within the network. We integrate a server load management algorithm into this design to efficiently balance the load among network servers.

➢   In the third case, we build a user-defined distributed network that several controllers oversee. The controllers are responsible for monitoring data flow inside their designated domains. Moreover, the suggested ISSLM algorithm influences how these controllers function. This strategic approach aims to improve the large-scale network’s network quality metrics.

1.5 Paper Arrangement

Section 2 explains the literature review and provides a comparison table of traditional server load management algorithms with the proposed technique of the ISSLM algorithm. In Section 3, we have discussed the working model of (ISSLM) algorithm and problem statement. In Section 4, the SDN network (in this research article) is simulated in three stages: (1) An SDN network with only one controller (POX) to manage the data traffic flow of the network (established on the Mininet environment) without the server load management algorithm. (2) An SDN network with only one controller to manage the data traffic flow of the network (established on the Mininet environment) with a server load management algorithm. (3) A user-defined network is now established in distributed network domains with multiple controllers managing data traffic flow under the proposed ISSLM algorithm. As a result of this approach, the network quality parameters in the large-scale network are augmented. In Section 5, we conclude the simulation results along with future research directions.

2  Literature Review

This section provides an overview of study findings about distributed SDN control configurations divided into two groups. As shown in Fig. 6, there are two research strategies: (1) logically centralized SDN configuration research techniques and (2) logically distributed SDN configuration research techniques.

Figure 6: Classification of the literature review into two portions

2.1 Research Methodology for Linking Large DCNs in SDN Centralized Controlled Structure

The Hyperflow protocol [17], which uses the WheelFS application to synchronize controllers, is covered in an article [18]. A broker-oriented distributed file system is used in this technique, which could lead to network Denial of Service (DOS) attacks. The Online Information Exchange (ONIX) program, which controls flow characteristics in the Network Information Database (NIDB) database, is presented in a research study [19]. While this method is appropriate for medium-sized networks, NIDB exchange may cause network overload in larger Data Center Networks (DCNs), resulting in worse quality parameters. A research paper [20] shows an Open Daylight (ODL) cluster that utilizes the AKKA (derived from a Swedish mountain and the choice of name symbolizes stability, resilience, and the ability to handle heavy loads, much like a mountain) framework [21,22] to synchronize controllers. Still, many control frames are used, making big DCNs slow. The Open Network Operating System (ONOS) is presented in a research article [23], which uses the Reliable, Available, and Fault-Tolerant (RAFT) algorithm [24] to map data between controllers. An active standby controller configuration is used to provide fault tolerance. According to a research paper [25], Atomix, a Java-based program, helps with fault tolerance in SDN networks. Similarly, Smart-Light uses an active-standby controller topology for fault tolerance with centralized data storage (CDS) [26,27]. A research article [28] discusses Ravenna, built on the Replicated State Machine (RSM) method for network device interconnections. As explained in another study [29], Manta’s and Rama’s methods aim to emulate Ravana’s traits without changing the OpenFlow protocol. Compared to Ravana, the open flow-based algorithm Kandos provides better quality parameters, as shown in a study publication [30]. Furthermore, research papers [31,32] include white documents from the Google project, which show that when used in logically centralized control mode setups, practical efficiency can reach up to 90%.

2.2 Research Methodology for Linking Large DCNs in SDN Distributed Controlled Structure

The functioning of controllers in the SDN distributed controlled plane (DISCO) is explained in a research study [33]. For intra- and inter-domain applications, this controller uses a variety of network-based agents to enable information flow. A revised protocol for managing queue messages (AMQP), specifically for inter-domain data transfers, is suggested by the authors in a research study [34]. The outcomes are noticeably better with the application of this technique. The Distributed Control Plane Interface (DCPI) program, which functions as an east-west bound interface, is also introduced in a research study [35]. It makes sharing and synchronizing network flow status easier for several domains. Based on the OpenFlow protocol, the Route Flow Partial (RFP) application is used to manage applications related to inter-domain flow. It is covered in more detail in another article [36]. A research article [37] discusses an application created by INRIA to improve fault tolerance and security in distributed SDN (D-SDN) configurations. Novel techniques for implementing SDN across internet exchange points, or SDX, are explored in several research articles [38–42]. Among these, research articles [43–45] cover fault tolerance techniques and DOS attack detection techniques within SDX. Furthermore, a study [46] describes enhancements to the SDN network’s Border Gateway Protocol (BGP). As demonstrated in a different study publication [47–48], the Distributed Flow Architecture for Networked Enterprises (DIFANE) application, when implemented in an SDN network, yields better QoS parameters.

2.3 A Comparison between Traditional Server Load Balancing Algorithms and the Proposed (ISSLM) Algorithm for Efficient Server Load Balancing

The differences between the suggested ISSLM algorithm and traditional load-balancing techniques are shown in Table 1. This section also details how the ISSLM algorithm overcomes the drawbacks of conventional load-balancing methods.

3  Problem Statement

When a single SDN controller controls the data traffic flow of a large SDN-based DCN, even how efficient the proposed method is, the network quality parameters are derailed. In the research article [47], the server load was balanced using a dynamic server load algorithm but using a single controller, which could result in a large processing delay of control instruction to the underlying switch in large DCNs. This research article uses multiple controllers in a logically distributed scenario to overcome the tight synchronization problem, as happens in the logically centralized control environment. Many research ideas to address this practical issue are mentioned in Section 2. But there are some significant issues related to this worthwhile issue that are following:

➢   The SDN controller manages the data traffic flow of all networking devices inside a network. Suppose another controller is incorporated inside a network to share the load of flow control. The transfer of control information among controllers inside the network requires tight synchronization. The open flow protocol will connect them to transmit control information regarding network controllability, which could also lead to vulnerabilities in DOS attacks. The problem of synchronization arises in the logically controlled arrangement.

➢   However, suppose the synchronization condition is somehow fulfilled. In that case, there is a problem when the network is a large DCN, and sharing necessary control files among controllers in case of heavy data traffic flow could make the controller loaded, enhancing the processing delays and latency and further derailing network quality parameters.

➢   Normally, there are two types of data flow inside a network: (1) data traffic requests to be transferred from one host and (2) control data flow from one controller to another. Sharing every flow information among different controllers has the advantage that if one controller fails, another controller takes responsibility for flow control in addition to its commitments. This requires additional spaces and programming to sport multiple control data flow inside a network.

However, this research article proposed a more efficient method: to balance server load as compared to the research methods suggested in Table 1 that is, instead of using different controllers in the master and slave version, the large DCNS network is divided into smaller domains, and every controller is responsible for flow control inside its domain and storing necessary flow data in its SAN for the network administrator to instruct the controller further to manage the flow inside that local domain better.

Solution Proposed by Implementing the Proposed Algorithm

Logically distributed use of SDN controllers is recommended when working with big networks with hundreds of thousands of network components. This method divides the large DCNs into smaller domains and assigns each controller to control flow control inside its assigned domain. These controllers also store important flow data in their SANs, which makes it easier for network administrators to give additional instructions for better flow management in each local domain. As seen in Fig. 3, this logically distributed technique has advantages over the logically centralized approach.

4  Methodology of the Proposed Technique (ISSLM)

The methodology of the proposed algorithm, the ISSLM algorithm, is divided into three procedural steps that are as follows.

4.1 Procedural Step#1

The SDN controller mode of operation is defined before forming an SDN-based network. If the network to be managed is small (comprising a few networking devices), then a single SDN controller is sufficient to control the flow. However, if the network is large (comparing hundreds of thousands of network components), the SDN controller should be used in a logically distributed manner. In this method, the large DCNS network is divided into smaller domains, and every controller is responsible for flow control inside its domain and storing necessary flow data in its SAN for the network administrator to instruct the controller further to manage the flow inside that local domain better as compared to the method adopted in research article [49]. The procedure of Step 1 is shown in Fig. 7.

Figure 7: Illustration of the suggested technique’s initial procedural step in a flow diagram

4.2 Procedural Step#2

The SDN controller determines each server’s HTTP request load (RPS) to prevent network server overload carried by HTTP requests. The Grafana application is launched on the HTTP server and configured to modulate the data source in Prometheus format; to accomplish this, Grafana gives the required server logs access to the SDN controller when combined with Prometheus as the data source. Each server’s RPS and active connection details are automatically retrieved every 10 milliseconds by designing a server load module at the POX controller using core and Psutil as Python library functions to fetch data by eliminating the need for lengthy calculation and Python coding. The following is the summary algorithm shown in Table 2.

4.3 Procedural Step#3

After forming the SDN network on the Mininet tool, the controller calculates the HTTP request load (RPS) for each server in the network. If the RPS value for any request severing sever is greater than the reference load threshold value (S_Load), the following conditions are met in the proposed algorithm:

if (Request load of requested server > = Server load)

   {

   Remove the requested server from the available servers list;

   For five times:

       If (Server search with lesser request load value = Successful)

       {

           Move the load of HTTP requests to that server;

           break the loop;

       }

       else if (Server search with the fewest connections active = Successful)

       {

           Move the load of HTTP requests to that server;

           break the loop;

       }

       else if (Server search with slowest response time = Successful)

       {

           Move the load of HTTP requests to that server;

           break the loop;

       }

       else

       {

           Print “The optimal server was not found”;

        }

     }

else

     {

        The requested server is given a new HTTP flow;

     }

The procedure of Step 3 is illustrated in Fig. 8.

Figure 8: The second and third procedural steps of the suggested technique are represented in a flow diagram

4.4 A Comparison between Traditional Server Load Balancing Algorithms and the Proposed (ISSLM) Algorithm for Efficient Server Load Balancing

This portion includes an algorithm, as shown in Table 3, to perform server load balancing with the research technique (ISSLM) algorithm.

4.4.1 Algorithm for Segregating the Control Plane of Large SDN-Based DCN

This portion includes an algorithm, as shown in Table 4, to segregate the control plane of large SDN-based DCN with the research technique (ISSLM) algorithm.

5  Results and Discussion

For the evaluation of the quality metrics parameters (maximum available bandwidth: Bd(max), Throughput: Th, Data transfer: DTransfer, and end-to-end delay: DE-E, etc.), the SDN-based network is simulated in three different configurations: (1) A single POX controller-based SDN controller arrangement designed on Mininet without any server load management algorithm for managing network data traffic. (2) A single POX controller-based SDN controller arrangement designed on Mininet with a proposed server load management algorithm (ISSLM) for managing network traffic. (3) Deployment of SDN in logically distributed controlled framework arrangement designed on Mininet with proposed server load management algorithm (ISSLM) for managing network data traffic. Fig. 9 represents the virtual network configurations designed on the Mininet tool for the first two cases of simulations.

Figure 9: Network topology selected for obtaining QoS parameter results in the first portion of the simulation

5.1 Case-A: Evaluation of the Quality Metrics Parameters (Bd(max), Th, DTransfer, D E-E, etc.) in a Single POX Controller-Based SDN Controller Arrangement Designed on Mininet without Any Server Load Management Algorithm for Managing Network Data Traffic

The user-defined network designed on Mininet, as shown in Fig. 9, comprises thirty HTTP request-generating hosts (Hst-1 to Hst-30), three OpenFlow switches (Sw1, Sw2, Sw3), four servers (Ser-1, Ser-2, Ser-3, and Ser-4), and single POX controller (CPs) that is responsible for managing the HTTP request load that is directed towards the servers. In this virtualized network environment, the servers are accordingly assigned the IP addresses 100.0.0.1, 100.0.0.2, 100.0.0.3, and 100.0.0.4. The QoS metrics (Bd(max), Th, DTransfer, DE-E, etc.) obtained under normal working conditions (200 randomly generated HTTP requests from hosts Hst-1–Hst-30 in our test case) include a maximum bandwidth (Bd(max)) of 6.5 Gb/s, a throughput (Th) of 5.6152 Gb/s, and a data transfer (DTransfer) volume of 7.019 Gbytes. However, during the simulation time of 10 s, a high volume of HTTP requests of 20,000 are made from randomly available Hosts (Hst-1 to Hst-30), and every request is exclusively sent to Ser-2 only. Because in this scenario there is no server load management technique applied on the Controller (CPs), it makes the Ser-2 get overloaded and reach a bottleneck state. As a result, QoS parameters (Bd(max), Th, DTransfer, DE-E, etc.) deteriorate. Fig. 10 shows the QoS parameters for maximum bandwidth (Bd(max)) and data transfer (DTransfer) related to the link between Ser-2 and the initiating hosts using the Iperf tool. Equations (Eq. (1)–(4)) are used to obtain the values of throughput (Th), the percentage drop in data transfer (%DTransfer), the percentage increase in server load (%ISL), and end-to-end Delay (DE-E). Where the Round-Trip Delay (RTD) is obtained from the Iperf utility by using its hping directory.

Th=Data_Transferin(Gbytes)Time(s)(1)

%ISL=100−(100∗(Bd(max)underloadedconditions)Bd(max)undernormalconditions)(2)

%DTransfer=100−(100∗(Data_Transferunderloadedconditions)Data_Transferundernormalconditions)(3)

DE−E=(RTD2)(4)

Figure 10: Results of quality parameters obtained through Iperf utility using a single controller (CPs) without load management

Table 5 represents the QoS parameters (Bd(max), Th, DTransfer, DE-E, etc.) for Case A with integration of Iperf utility with the Mininet environment over 10 s. When all 20,000 requests are sent to a Ser-2 without the use of load balancing, there is a noticeable increase in the server load (%ISL) as compared to the normal conditions. The percentage of data transfer (%DTransfer) is also drastically decreased compared to normal conditions (i.e., 200 randomly generated HTTP requests from hosts Hst-1–Hst-30).

Line graphs of QoS parameters (Bd(max) and DTransfer) for Ser-2 using the Gnu Plot tool are represented in Fig. 11a,b.

Figure 11: Line graphs of (Bd(max) and DTransfer) for Server_2 without load management. (a) Bd(max) using a single controller (CPs) without load management. (b) DTransfer using a single controller (CPs) without load management

5.1.1 Summarizing QoS Parameters (Bd(max), Th, DTransfer, DE-E, etc.) Result of Case A

When a network topology shown in Fig. 9 is simulated to obtain the QoS parameters (Bd(max), Th, DTransfer, DE-E, etc.) results with only a single controller without a load management algorithm, the overall network QoS is drastically decreased. The Bd decreased to the value (from 6.5 to 1.449 Gb/s). The Th value is declined from (5.612 to 1.322 Gb/s). The DTransfer is also reduced from (7.019 to 1.652 Gbytes), and a Delay of (262.5 ms) is induced in the selected network. The percentage load on the network servers (%ISL) is increased to (77.70%). The overall percentage reduction in data transfer (%DTransfer) is (76.49%).

5.2 Case-B: Evaluation of the Quality Metrics Parameters (Bd(max), Th, DTransfer, DE-E, etc.) in a Single POX Controller-Based SDN Controller Arrangement Designed on Mininet with Proposed Server Load Management Algorithm (ISSLM) for Managing Network Data Traffic

In this section, the proposed algorithm (ISSLM) in the form of Python script is loaded on the POX controller, which performs server load management under the direction of (the ISSLM) algorithm. In this mode, all the HTTP requests generated from randomly available hosts (Hst-1 to Hst-30) are first countered by an SDN controller that performs load balancing on network servers (Ser1, Ser2, Ser3, and Ser4) with the aid of the ISSLM algorithm. In ten second simulation period, 20,000 HTTP requests are directed only toward the POX controller. Using the Iperf utility, the QoS parameters for Case B are obtained and shown in Fig. 12.

Figure 12: Results of quality parameters obtained through Iperf utility using a single controller (CPs) with ISSLM algorithm

Table 6 represents the QoS parameters (Bd(max), Th, DTransfer, DE-E, etc.) for Case B with integration of Iperf utility with Mininet environment over 10 s. As it is evident from Table 6 and Fig. 12, the network quality parameters (Bd(max), Th, DTransfer, DE-E) are greatly increased as compared to Case A when all 20,000 HTTP requests are controlled by the controller equipped with a proposed algorithm (ISSLM). The (Bd(max)) increases to 5.561 from 1.449 Gb/s. The Th improves to 4.854 from 1.322 GB/s. There is also significant increase in DTransfer, going from 1.652 G-bytes to 6.068 G-bytes. Regarding Eqs. (2) and (3), the (%DTransfer) and (%ISL) drop from 76.49% to 13.55% and 77.70% to 14.44%, respectively.

Line graphs of QoS parameters (Bd(max) and DTransfer) for Case B using the Gnu Plot tool are represented in Figs. 13 and 14.

Figure 13: Bd(max) using a single controller (CPs) with load management algorithm (ISSLM)

Figure 14: DTransfer using a single controller (CPs) with load management algorithm (ISSLM)

5.2.1 Summarizing QoS Parameters (Bd(max), Th, DTransfer, DE-E, etc.) Result of Case B

When a network topology shown in Fig. 9 is simulated to obtain the QoS parameters (Bd(max), Th, DTransfer, DE-E, etc.) results with only a single controller with the proposed load management algorithm (ISSLM), the overall QoS of the network is increased as compared to Case A. The Bd is maximized to the value (from 1.449 to 5.561 Gb/s). The Th value is increased from (1.322 to 4.854 Gb/s). The DTransfer is also incremented from (1.652 to 6.068 Gbytes), and Delay is reduced to (513.5 to 36.7 ms) in the selected network. The percentage load on the network servers (%ISL) is decreased up to (from 77.70% to 14.44%). The overall percentage reduction in data transfer (%DTransfer) is also less in Case B (76.49% to 13.55%).

5.3 Case-C: Evaluation of the Quality Metrics Parameters (B d(max), Th, DTransfer, DE-E, etc.) with Deployment of SDN in Logically Distributed Controlled Framework Arrangement Designed on Mininet with Proposed Server Load Management Algorithm (ISSLM) for Managing Network Data Traffic

In this case, the SDN architecture is framed in a logically distributed controlled arrangement, as shown in Fig. 15. Thirty hosts (Hst-1 to Hst-30) are divided into four logically distributed SDN-based sub-networks (Ld1, Ld2, Ld3, and Ld4), each of which is overseen by a separate dedicated controller (Cd1, Cd2, Cd3, and Cd4). Now, instead of handling 20,000 HTTP requests by the single controller (CPs), the Cd1 and Cd3, handle 6000 HTTP requests apiece that come from network devices in sub-networks Ld1 and Ld3, respectively, using a proposed algorithm (ISSLM). Similarly, 4000 HTTP requests apiece are managed by Cd2 and Cd4 and directed from network devices inside Ld2 and Ld4 using the ISSLM algorithm with the help of logic presented in Table 4. Higher-level controllers Cp1 and Cp2 are responsible for overall network flow control management and fault tolerance.

Figure 15: The proposed network configuration for deploying SDN in large DCNs

The subnetwork controllers (Cd1, Cd2, Cd3 and Cd4) have an IP address as (11.0.1.1, 12.0.1.1, 13.0.1.1, and 14.0.1.1), respectively. For subnetworks (Ld1, Ld2, Ld3 and Ld4), the corresponding IP addresses are (11.0.1.2, 12.0.1.2, 13.0.1.2 and 14.0.1.2), respectively. Fig. 16 illustrates the values of (Bd(max), Th, and DTransfer) in all sub-divided networks (Ld1, Ld2, Ld3, and Ld4) using the Iperf utility.

Figure 16: QoS parametric values of four subdivided networks (Ld1, Ld2, Ld3, and Ld4) using Iperf utility. (a): Displays the QoS parametric values for (Ld1) using Iperf utility. (b): Displays the QoS parametric values for (Ld2) using the Iperf utility. (c): Displays the QoS parametric values for (Ld3) using Iperf utility. (d): Displays the QoS parametric values for (Ld4) using the Iperf utility

As evidenced by Table 7 and Fig. 16, the QoS parametric values in the proposed framework (logically distributed controlled arrangement) by implementing the proposed algorithm (ISSLM) are far greater than the quality requests obtained from the Case (A and B).

It is the dividend from Table 7 that (Bd(max)) for (Ld1, Ld2, Ld3, and Ld4) has increased to (5.901, 6.101, 5.901, 6.101 Gb/s), respectively, from (5.561 Gb/s), as recorded under QoS parameters in Case B. Similarly (Th) for each subnetwork has increased from 4.854 Gb/s (throughput as QoS parametric value in Case B) to (5.072, 5.201, 5.072, 5.201 Gb/s) for (Ld1, Ld2, Ld3 and Ld4), respectively. (DTransfer) for each subnetwork has increased from 6.068 Gbytes (Data transfer as QoS parametric value in Case B) to (6.340, 6.501, 6.340, 6.501 Gbytes) for (Ld1, Ld2, Ld3 and Ld4), respectively. Moreover, the (%ISL) has dropped throughout the corresponding sub-networks from 14.44% (QoS parametric value in Case B) to (9.21%, 6.14%, 9.21%, 6.14%), for (Ld1, Ld2, Ld3, and Ld4), respectively. The (%DTransfer) has dropped throughout the corresponding subnetworks from 13.55% (QoS parametric value in Case B) to (9.67%, 7.38%, 9.67%, 7.38%), for (Ld1, Ld2, Ld3, and Ld4), respectively. These differences in Bd(max)and DTransfer across the segmented networks (Ld1, Ld2, Ld3, and Ld4) are graphically represented in line graph format using the Gnu plot in Fig. 17.

Figure 17: Line Graphs of QoS parametric values of four local domains (Ld1, Ld2, Ld3, and Ld4) using Gnu-plot. (a): Bd(max) for (Ld1 and Ld3) with the proposed algorithm (ISSLM). (b): Bd(max) for (Ld2 and Ld4) with the proposed algorithm (ISSLM). (c): DTransfer for (Ld1 and Ld3) with the proposed algorithm (ISSLM). (d): DTransfer for (Ld2 and Ld4) with the proposed algorithm (ISSLM)

5.3.1 Summarizing QoS Parameters (Bd(max), Th, DTransfer, DE-E, etc.) Result of Case C

When a network is framed in a logically distributed controlled environment, as shown in Fig. 15, the QoS parameters (Bd(max), Th, Dtransfer, DE-E, etc.) results are far more superior as compared to QoS parameters of Case (A & B). The Bd is maximized from (5.561 Gb/s) in Case B to (5.901, 6.101, 5.901, 6.101 Gb/s) for (Ld1, Ld2, Ld3 and Ld4), respectively. The Th value is increased from (4.854 Gb/s) in Case B to (5.072, 5.201, 5.072, 5.201 Gb/s) for (Ld1, Ld2, Ld3 and Ld4), respectively. The Dtransfer is also incremented from (6.068 Gbytes) in Case B to (6.340, 6.501, 6.340, 6.501 Gbytes) for (Ld1, Ld2, Ld3 and Ld4) respectively and Delay is reduced from (36.7 ms) in Case B to (3.57, 0.87, 3.57, 0.87 ms) for (Ld1, Ld2, Ld3 and Ld4) respectively in the selected network. The percentage load on the network servers (%ISL) decreased from (14.44%) in Case B to (9.21%, 6.14%, 9.21%, 6.14%) for (Ld1, Ld2, Ld3 and Ld4), respectively. The overall percentage reduction in data transfer (%DTransfer) is also less in Case C (9.67%, 7.38%, 9.67%, 7.38%) for (Ld1, Ld2, Ld3, and Ld4), respectively.

5.4 Case-D: Evaluating the Performance in Terms of QoS Parameters of the Proposed Framework (Logically Distributed Controlled Environment) under ISSLM in Comparison with Traditional Load Balancing Methods

In Case D, we tested and gathered the QoS parameter values (Bd(max), Th, Dtransfer, D_Transmission_Delay) result with the application of the following latest and widely used load balancing techniques mentioned in Table 1 one by one on the user-defined network to compare it with the proposed method (ISSLM) as they also based on Mininet environment as our proposed technique.

• Dynamic Weight Random Selection Method (DWRS) in [50]

• Multiple Regression Based Search Algorithm (MRBS) in [51]

• Adoptive Multiple Objective Load Balancing (AMLOB) in [55]

• Shortest Time Calculation Method (SRT) in [63]

• Conventional Round Robin Method (CRRM) in [64]

The results of Case D are summarized in Table 8. The network QoS parameters are tested for all the above methods, including the proposed technique in two load conditions (normal flow: 200 HTTP requests to be managed by the SDN controller and heavy flow: 20,000 HTTP requests to be managed by the SDN controller). The Delay_Transmission is calculated by Eq. (5) in both modes (heavy flow mode: M2 and normal flow mode: M1). The differential transmission Delay (D_Transmission_Delay), as shown in Eq. (6), is a difference in milliseconds of transmission delay in (Heavy flow mode to normal flow mode: Transmission delay in M2–Transmission Delay in M1). The main reason for finding this parameter, in addition to the transmission delay, is to see how much delay is produced in ms when the load shifts from normal to heavy mode. The last column of Table 8 explains the difference in transmission delay in ms when the load shifts from normal mode to heavy flow mode. The QoS metrics (Bd(max), Th, DTransfer) obtained under normal loaded conditions include a maximum bandwidth (Bd(max)) of 4.02 Gb/s and a data transfer (DTransfer) volume of 7.02 Gbytes for 15 s.

Delay_Transmission=[DTransfer(Gbytes)]×8Bdmax(Gb/s)(5)

Overall(D_Transmission_Delay)=Delay_Transmission(M2)−Delay_Transmission(M1)(6)

where (M1 = Normal data traffic mode) and M2 = (Heavy data traffic mode).

Figs. 18–20 show the contrast of QoS variable (Bd(max), DTransfer, D_Transmission_Delay) results obtained from the Iperf utility under the proposed framework (logically distributed) using the Gnu plot.

Figure 18: Contrasting the QoS variable (Bd(max)) results from different traditional methods with the research technique (ISSLM)

Figure 19: Contrasting QoS variable (DTransfer) results from different traditional methods with the research technique (ISSLM)

Figure 20: Contrasting QoS variable (D_Transmission_Delay) results from different traditional methods with the research technique (ISSLM)

5.4.1 Summarizing QoS Parameters (Bd(max), Th, DTransfer, D_Transmission_Delay, etc.) Result of Comparative Analysis

When a network is framed in a logically distributed controlled environment, as shown in Fig. 15, the QoS parameters (Bd(max), Th, DTransfer, D_Transmission_Delay, etc.) results with the proposed algorithm ISSLM are far more superior as compared to QoS parameters obtained from the traditional methods namely: SRT, CRRM, DWRS, MRBS and AMLOB. The Bd value in the selected network with the proposed algorithm-based framework is (3.649 Gb/s) as compared to (1.499, 1.449, 3.229, 3.025, 2.796 Gb/s) for (SRT, CRRM, DWRS, MRBS, and AMLOB), respectively. The Th value in the selected network with the proposed algorithm-based framework is (3.232 Gb/s) as compared to (1.40, 1.386, 3.013, 2.82, 2.6133 Gb/s) for (SRT, CRRM, DWRS, MRBS, and AMLOB), respectively. The Dtransfer value in the selected network with the proposed algorithm-based framework is (6.059 Gbytes) as compared to (2.629, 2.599, 5.649, 5.299, 4.899 Gbytes) for (SRT, CRRM, DWRS, MRBS, and AMLOB) respectively and D_Transmission_Delay in the selected network with proposed algorithm based framework is (2.80 ms) as compared to (60.58, 379.10, 25.564, 43.78, 47.06 ms) for (SRT, CRRM, DWRS, MRBS and AMLOB), respectively.

6  Conclusion

In this research article, we have accomplished our goal of magnifying the network quality parameters (maximum available bandwidth, greater throughput, and higher data transfer) in large DCNs by applying the proposed algorithm, ISSLM on SDN controllers arranged in logically distributed arrangement with the utilization of two new methods (1) A large SDN based DCN is divided into sub-networks with independent controllers to overcome the bottleneck issues of the unified controller and also nullifying the compatibilities issues with use of multiple controllers in single large network. (2) Each local controller manages the load by adopting the ISSLM algorithm that performs the desired task of shifting load to the most suitable controller based on three conditions (A-server have less RPS value (OR) B-server with fewer concurrent requests (OR) C-server with less response time). For testing, the virtual network (with many network devices) is formed on Mininet, and simulation is performed in three different configurations: (1) A single POX controller-based SDN controller arrangement designed on Mininet without any server load management algorithm for managing network traffic. (2) A single POX controller-based SDN controller arrangement designed on Mininet with a proposed server load management algorithm (ISSLM) for managing network traffic. (3) Deployment of SDN in logically distributed controlled framework arrangement designed on Mininet with proposed server load management algorithm (ISSLM) for managing network data traffic. Case C’s QoS parametrized values (Bd(max), Th, DTransfer, D_Transmission_Delay, etc.) showed that the proposed framework with ISSLM algorithm performed better server load management in Large DCNs. The comparative analysis results of the proposed algorithm ISSLM are far more superior as compared to QoS parameters obtained from the traditional methods, namely: SRT, CRRM, DWRS, MRBS and AMLOB. The Bdmax value in the selected network with the proposed algorithm-based framework is (3.649 Gb/s) as compared to (1.499, 1.449, 3.229, 3.025, 2.796 Gb/s) for (SRT, CRRM, DWRS, MRBS and AMLOB), respectively. The Th value in the selected network with the proposed algorithm-based framework is (3.232 Gb/s) as compared to (1.40, 1.386, 3.013, 2.82, 2.6133 Gb/s) for (SRT, CRRM, DWRS, MRBS, and AMLOB), respectively. The Dtransfer value in the selected network with the proposed algorithm based framework is (6.059 Gbytes) as compared to (2.629, 2.599, 5.649, 5.299, 4.899 Gbytes) for (SRT, CRRM, DWRS, MRBS and AMLOB), respectively and D_Transmission_Delay in the selected network with proposed algorithm based framework is (2.80 ms) as compared to (60.58, 379.10, 25.564, 43.78, 47.06 ms) for (SRT, CRRM, DWRS, MRBS and AMLOB), respectively. However, one possible limitation of this research study is that it has been conducted in a controlled or simulated environment; the obtained results can show slight variation when the proposed technique is made functional in real-world conditions and is strongly tied to the performance and reliability of the SDN controllers.

Acknowledgement: Special thanks to Shahid Atiq, Muhammad Majid Hussain, and Intisar Ali Sajjad for guiding and supporting the implementation of the QoS Enhancement Method ISSLM Algorithm. Also, special thanks to Malik Muhammad Abdul Basit for manuscript preparation.

Funding Statement: The authors received no specific funding for this study.

Author Contributions: The author’s contributions to this paper are as follows: study conception and design: Khawaja Tahir Mehmood, Shahid Atiq; data collection: Khawaja Tahir Mehmood, Shahid Atiq; analysis and interpretation of results: Khawaja Tahir Mehmood, Shahid Atiq; draft manuscript preparation: Khawaja Tahir Mehmood, Shahid Atiq, Intisar Ali Sajjad, Muhammad Majid Hussain, Malik M. Abdul Basit. All authors reviewed the results and approved the final version of the manuscript.

Availability of Data and Materials: The supporting data related to the algorithm and simulation material technical details are with the corresponding author and can be provided upon appropriate request.

Ethics Approval: Not applicable.

Conflicts of Interest: The authors declare that have no conflicts of interest to report regarding the present study.

References

1. Cisco. Annual internet report (2018–2023) white paper. Cisco; 2020. Available from: https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.html. [Accessed 2020]. [Google Scholar]

2. Sloane T. Software-defined networking: the new norm for networks. Open Networking Foundation; 2013. Available from:https://opennetworking.org/sdn-resources/whitepapers/software-defined-networking-the-new-norm-for-networks/. [Accessed 2020]. [Google Scholar]

3. Gomez-Rodriguez JR, Sandoval-Arechiga R, Ibarra-Delgado S, Rodriguez-Abdala VI, Vazquez-Avila JL, Parra-Michel R. A survey of software-defined networks-on-chip: motivations, challenges and opportunities. Micromachines. 2021 Feb 12;12(2):183. doi:10.3390/mi12020183. [Google Scholar] [PubMed] [CrossRef]

4. Jenabzadeh MR, Ayatollahitafti V, Mollakhalili MR, Mollahoseini Ardakani MR. VNR_CCP: a new approach to congestion control using virtualization technique and switch migration in SDN. J Model Eng. 2024 May;22(76):85–98. [Google Scholar]

5. Kaur S, Sandhu AK, Bhandari A. Investigation of application layer DDoS attacks in legacy and software-defined networks: a comprehensive review. Int J Inf Secur. 2023 Aug 7;22(6):1949–88. doi:10.1007/s10207-023-00728-5. [Google Scholar] [CrossRef]

6. Salti IA, Zhang N. An effective, efficient and scalable link discovery (EESLD) framework for hybrid multi-controller SDN networks. IEEE Access. 2023 Jan;11:140660–86. doi:10.1109/ACCESS.2023.3339381. [Google Scholar] [CrossRef]

7. Imran Hussain S, Yesvanth R, Yuvarajapathi V. Implementing OpenFlow, exploring the present and future software-defined networks ecosystem. In: International Conference on Sustainable Communication Networks and Application (ICSCNA), 2023; Theni, India; p. 280–5. [Google Scholar]

8. Sezer S, Scott-Hayward S, Chouhan P, Fraser B, Lake D, Finnegan J, et al. Are we ready for SDN? Implementation challenges for software-defined networks. IEEE Commun Mag. 2013;51(7):36–43. doi:10.1109/MCOM.2013.6553676. [Google Scholar] [CrossRef]

9. Karakus M, Durresi A. A survey: control plane scalability issues and approaches in Software-Defined Networking (SDN). Comput Netw. 2017 Jan;112:279–93. doi:10.1016/j.comnet.2016.11.017. [Google Scholar] [CrossRef]

10. Javadpour A, Wang G, Rezaei S. Resource management in a peer-to-peer cloud network for IoT. Wirel Pers Commun. 2020 Aug;115(3):2471–88. doi:10.1007/s11277-020-07691-7. [Google Scholar] [CrossRef]

11. Javadpour A, Wang G. cTMvSDN: improving resource management using combination of Markov-process and TDMA in software-defined networking. J Supercomput. 2021;Jul;78(3):3477–99. doi:10.1007/s11227-021-03871-9. [Google Scholar] [CrossRef]

12. Manzoor S, Kayani MA, Ali N, Ratyal NI, Mohamed HG. TiWA: achieving tetra indicator Wi-Fi associations in software defined Wi-Fi networks. IEEE Access. 2023 Jan;11:89520–34. doi:10.1109/ACCESS.2023.3307476. [Google Scholar] [CrossRef]

13. Kalafatidis S, Demiroglou V, Mamatas L, Tsaoussidis V. Experimenting with an SDN-Based NDN deployment over wireless mesh networks. In: IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), 2022; New York, NY, USA; p. 1–6. [Google Scholar]

14. Kobo HI, Abu-Mahfouz AM, Hancke GP. A survey on software-defined wireless sensor networks: challenges and design requirements. IEEE Access. 2017;5:1872–99. doi:10.1109/ACCESS.2017.2666200. [Google Scholar] [CrossRef]

15. Kreutz D, Ramos FMV, Esteves Verissimo P, Esteve Rothenberg C, Azodolmolky S, Uhlig S. Software-defined networking: a comprehensive survey. Proc IEEE. 2015 Jan;103(1):14–76. doi:10.1109/JPROC.2014.2371999. [Google Scholar] [CrossRef]

16. Shah N, Giaccone P, Rawat DB, Rayes A, Zhao N. Solutions for adopting software defined network in practice. Int J Commun Syst. 2019 May 1;32(17):e3990. doi:10.1002/dac.3990. [Google Scholar] [CrossRef]

17. Zuo QY, Chen M, Zhao GS, Xing CY, Zhang GM, Jiang PC. Research on OpenFlow-based SDN technologies. J Softw. 2013 Dec 1;24(5):1078–97. doi:10.3724/SP.J.1001.2013.04390. [Google Scholar] [CrossRef]

18. Stribling J, Sovran Y, Zhang I, Pretzer X, Li J, Kaashoek MF, et al. Flexible, wide-area storage for distributed systems with WheelFS. Netw Syst Des Implement. 2009 Apr;4:43–58. [Google Scholar]

19. Koponen T, Casado M, Gude N, Stribling J, Poutievski L, Zhu M, et al. Onix: a distributed control platform for large-scale production networks. Proc OSDI. 2010;10:1–6. [Google Scholar]

20. Medved J, Varga R, Tkacik A, Gray K. OpenDaylight: towards a model-driven SDN controller architecture. In: Proceeding of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks, 2014; Sydney, NSW, Australia; p. 1–6. [Google Scholar]

21. Akka. Build concurrent, distributed, and resilient message-driven applications for java and scala. Available from: https://akka.io/. [Accessed 2020]. [Google Scholar]

22. Suh D, Jang S, Han S, Pack S, Kim T, Kwak JY. On performance of OpenDaylight clustering. In: IEEE NetSoft Conference and Workshops (NetSoft), 2016; Seoul, Republic of Korea; p. 407–10. [Google Scholar]

23. Berde P, Gerola M, Hart J, Higuchi Y, Kobayashi M, Koide T, et al. ONOS: towards an open, distributed SDN OS. In: Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, 2014; Chicago, IL, USA; p. 1–6. [Google Scholar]

24. Sakic E, Kellerer W. Response time and availability study of RAFT consensus in distributed SDN control plane. IEEE Trans Netw Serv Manag. 2018 Mar;15(1):304–18. doi:10.1109/TNSM.2017.2775061. [Google Scholar] [CrossRef]

25. Atomix. A reactive java framework for building fault-tolerant distributed systems. Available from: https://atomix.io/ [Accessed 2020]. [Google Scholar]

26. Hunt P, Konar M, Junqueira FP, Reed B. ZooKeeper: wait-free coordination for internet-scale systems. In: USENIX Annual Technical Conference, 2010; Boston, MA, USA; p. 11. [Google Scholar]

27. Rehman AU, RuiL A, Barraca JP. Fault-tolerance in the scope of software-defined networking (SDN). IEEE Access. 2019;7:124474–90. doi:10.1109/ACCESS.2019.2939115. [Google Scholar] [CrossRef]

28. Katta N, Zhang H, Freedman M, Rexford J. Ravana: controller fault-tolerance in software-defined networking. In: Proceedings of the 1st ACM SIGCOMM Symposium on Software Defined Networking Research, 2015; Santa Clara, CA, USA; p. 1–13. [Google Scholar]

29. Mantas A, Ramos FMV. Consistent and fault-tolerant SDN with unmodified switches. Cornell University: USA; 2016 Jan. [Google Scholar]

30. Yeganeh S, Ganjali Y. Kandoo: a framework for efficient and scalable offloading of control applications. In: Proceedings of the First Workshop on Hot Topics in Software Defined Networks, ACM SIGCOMM, 2012; Helsinki, Finland; p. 19–24. [Google Scholar]

31. Jain S, Zhu M, Zolla J, Hölzle U, Stuart S, Vahdat A, et al. B4: experience with a globally-deployed software defined WAN. ACM SIGCOMM Comput Commun Rev. 2013 Aug;43(4):3–14. doi:10.1145/2486001.2486019. [Google Scholar] [CrossRef]

32. Hong CY, Kandula S, Mahajan R, Zhang M, Gill V, Nanduri M, et al. Achieving high utilization with software-driven WAN. In: Proceedings of the ACM SIGCOMM, 2013 Conference on SIGCOMM, 2013; Hong Kong, China; p. 15–26. [Google Scholar]

33. Phemius K, Bouet M, Leguay J. DISCO: distributed multi-domain SDN controllers. In: 2014 IEEE Network Operations and Management Symposium (NOMS), 2014; Krakow, Poland. [Google Scholar]

34. Basavaraju N, Alexander N, Seitz J. Performance evaluation of advanced message queuing protocol (AMQP): an empirical analysis of AMQP online message brokers. In: International Symposium on Networks, Computers and Communications (ISNCC), 2021; Dubai, United Arab Emirates; p. 1–8. [Google Scholar]

35. Benamrane F, Ben Mamoun M, Benaini R. An East-West interface for distributed SDN control plane: implementation and evaluation. Comput Electr Eng. 2017 Jan;57:162–75. doi:10.1016/j.compeleceng.2016.09.012. [Google Scholar] [CrossRef]

36. Esteve Rothenberg C, Trindade Nascimento M, Teixeira Godoy H, Carlos S, Raszuk R. Revisiting routing control platforms with the eyes and muscles of software-defined networking. In: Proceedings of the First Workshop on Hot Topics in Software Defined Networks, ACM SIGCOMM, 2012; Helsinki, Finland; p. 13–8. [Google Scholar]

37. Santos MAS, Nunes BAA, Obraczka K, Turletti T, de Oliveira BT, Margi CB. Decentralizing SDN’s control plane. In: 39th Annual IEEE Conference on Local Computer Networks, 2014; Edmonton, AB, Canada; p. 402–5. [Google Scholar]

38. Stringer J, Pemberton D, Fu Q, Lorier C, Nelson RE, Bailey JJ, et al. Cardigan: SDN distributed routing fabric going live at an Internet exchange. In: 2014 IEEE Symposium on Computers and Communications (ISCC), 2014; Funchal, Portugal; p. 1–7. [Google Scholar]

39. Lapeyrade R, Bruyère M, Owezarski P. OpenFlow-based migration and management of the TouIX IXP. In: IEEE/IFIP Network Operations and Management Symposium, 2016; Istanbul, Turkey; p. 1131–6. [Google Scholar]

40. Malboubi M, Wang L, Chuah CN, Sharma P. Intelligent SDN based traffic (de)aggregation and measurement paradigm (iSTAMP). In: IEEE INFOCOM 2014—IEEE Conference on Computer Communications, 2014; Toronto, ON, Canada; p. 934–42. [Google Scholar]

41. Endeavour. Project. Available from: https://www.h2020-endeavour.eu/. [Accessed 2024]. [Google Scholar]

42. Morgan H. Atlantic wave-SDX: a distributed intercontinental experimental software defined exchange for research and education networking; 2015. Available from: https://itnews.fiu.edu/wp-content/uploads/sites/8/2015/04/AtlanticWaveSDX-Press-Release_FinalDraft.pdf [Accessed 2020]. [Google Scholar]

43. Lin P, Bi J, Wolff S, Wang Y, Xu A, Chen Z, et al. A west-east bridge based SDN inter-domain testbed. IEEE Commun Mag. 2015 Feb;53(2):190–7. doi:10.1109/MCOM.2015.7045408. [Google Scholar] [CrossRef]

44. Mehmood KT, Atiq S, Hashmi MW. Predictive analysis of telecom system quality parameters with SDN (Software Define Networking) controlled environment. Elem Educ Online. 2021 Jan;20(3):2342–55. [Google Scholar]

45. Advanced Layer 2 System, Internet2. Ann Arbor, MI, USA: Advanced Technology Community Founded by the U.S. Research and Education Communit; Dec. 2014. Available from: https://www.internet2.edu/products-%20services/advanced-networking/layer-2-services/. [Accessed 2024]. [Google Scholar]

46. Kotronis V, Gämperli A, Dimitropoulos X. Routing centralization across domains via SDN: a model and emulation framework for BGP evolution. Comput Netw. 2015 Dec;92:227–39. doi:10.1016/j.comnet.2015.07.015. [Google Scholar] [CrossRef]

47. Yu M, Rexford J, Freedman MJ, Wang J. Scalable flow-based networking with DIFANE. In: SIGCOMM’10: Proceedings of the ACM SIGCOMM, 2010; New Delhi, India; p. 351–62. [Google Scholar]

48. Aly WHF. Generic controller adaptive load balancing (GCALB) for SDN networks. J Comput Netw Commun. 2019 Dec;2019:1–9. doi:10.1145/1851182.1851224. [Google Scholar] [CrossRef]

49. Mehmood KT, Atiq S, Hussain MM. Enhancing QoS of telecom networks through server load management in software-defined networking (SDN). Sensors. 2023 Jan;23(23):9324. doi:10.3390/s23239324. [Google Scholar] [PubMed] [CrossRef]

50. Chiang ML, Cheng HS, Liu HY, Chiang CY. SDN-based server clusters with dynamic load balancing and performance improvement. Cluster Comput. 2020 May;24(1):537–58. doi:10.1007/s10586-020-03135-w. [Google Scholar] [CrossRef]

51. Begam GS, Sangeetha M, Shanker NR. Load balancing in DCN servers through SDN machine learning algorithm. Arab J Sci Eng. 2021 Jul;47(2):1423–34. doi:10.21203/rs.3.rs-277161/v1. [Google Scholar] [CrossRef]

52. Malbašić T, Bojović PD, Bojović Ž., Šuh J, Vujošević D. Hybrid SDN networks: a multi-parameter server load balancing scheme. J Netw Syst Manag. 2022 Jan;30(2):1–29. doi:10.21203/rs.3.rs-383737/v1. [Google Scholar] [CrossRef]

53. Liang S, Jiang W, Zhao F, Zhao F. Load balancing algorithm of controller based on SDN architecture under machine learning. J Syst Sci Inform. 2020 Dec;8(6):578–88. doi:10.21078/JSSI-2020-578-11. [Google Scholar] [CrossRef]

54. Ahmad S, Jamil F, Ali A, Khan E, Ibrahim M, Keun Whangbo T. Effectively handling network congestion and load balancing in software-defined networking. Comput Mater Contin. 2022;70(1):1363–79. doi:10.32604/cmc.2022.017715. [Google Scholar] [CrossRef]

55. Saxena MC, Sabharwal M, Bajaj P. Review of SDN-based load-balancing methods, issues, challenges, and roadmap. Int J Electr Comput Eng Syst. 2023 Nov;14(9):1031–49. doi:10.32985/ijeces.14.9.8. [Google Scholar] [CrossRef]

56. Haidi AM, Au TW, Shah H. Single cluster load balancing using SDN: performance comparison between floodlight and POX. In: IEEE 19th International Conference on Communication Technology (ICCT), 2019; Xi’an, China. [Google Scholar]

57. Ejaz S, Iqbal Z, Azmat Shah P, Bukhari BH, Ali A, Aadil F. Traffic load balancing using software defined networking (SDN) controller as virtualized network function. IEEE Access. 2019;7:46646–58. doi:10.1109/ACCESS.2019.2909356. [Google Scholar] [CrossRef]

58. Gasmelseed H, Ramar R. Traffic pattern-based load-balancing algorithm in software-defined network using distributed controllers. Int J Commun Syst. 2018 Nov;32(7):e3841. doi:10.1002/dac.3841. [Google Scholar] [CrossRef]

59. Xu Y, Cello M, Wang IC, Walid A, Wilfong G, Wen CHP, et al. Dynamic switch migration in distributed software-defined networks to achieve controller load balance. IEEE J Sel Areas Commun. 2019 Mar;37(3):515–29. doi:10.1109/JSAC.2019.2894237. [Google Scholar] [CrossRef]

60. Gao Y, Zhang Z, Zhao D, Zhang Y, Luo T. A hierarchical routing scheme with load balancing in software defined vehicular ad hoc networks. IEEE Access. 2018 Jan;6:73774–85. doi:10.1109/ACCESS.2018.2884708. [Google Scholar] [CrossRef]

61. Vyakaranal SB, Naragund JG. Weighted round-robin load balancing algorithm for software-defined network. In: Emerging Research in Electronics, Computer Science and Technology, 2019; Singapore; p. 375–87. [Google Scholar]

62. Sathyanarayana S, Moh M. Joint route-server load balancing in software defined networks using ant colony optimization. In: International Conference on High Performance Computing and Simulation, 2016; Innsbruck, Austria; p. 156–63. [Google Scholar]

63. Zhong H, Fang Y, Cui J. LBBSRT: an efficient SDN load balancing scheme based on server response time. Future Gener Comput Syst. 2017 Mar;68:183–90. doi:10.1016/j.future.2016.10.001. [Google Scholar] [CrossRef]

64. Hamed MI, ElHalawany BM, Fouda MM, Eldien AST. Performance analysis of applying load balancing strategies on different SDN environments. Benha J Appl Sci. 2017 Mar;2(1):91–7. doi:10.21608/bjas.2017.163983. [Google Scholar] [CrossRef]

65. Hai NT, Kim DS. Efficient load balancing for multi-controller in SDN-based mission-critical networks. In: IEEE 14th International Conference on Industrial Informatics (INDIN), 2016; Poitiers, France; p. 420–5. [Google Scholar]