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.

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.

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.

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.

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 (B_dmax), 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.

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.

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.

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%.

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.

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.

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.

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.

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.

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

The user-defined network designed on Mininet, as shown in Fig. 9, comprises thirty HTTP request-generating hosts (H_st-1 to H_st-30), three OpenFlow switches (S_w1, S_w2, S_w3), four servers (S_er-1, S_er-2, S_er-3, and S_er-4), and single POX controller (C_Ps) 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 (B_d(max), T_h, D_Transfer, D_E-E, etc.) obtained under normal working conditions (200 randomly generated HTTP requests from hosts H_st-1–H_st-30 in our test case) include a maximum bandwidth (B_d(max)) of 6.5 Gb/s, a throughput (T_h) of 5.6152 Gb/s, and a data transfer (D_Transfer) 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 (H_st-1 to H_st-30), and every request is exclusively sent to S_er-2 only. Because in this scenario there is no server load management technique applied on the Controller (C_Ps), it makes the S_er-2 get overloaded and reach a bottleneck state. As a result, QoS parameters (B_d(max), T_h, D_Transfer, D_E-E, etc.) deteriorate. Fig. 10 shows the QoS parameters for maximum bandwidth (B_d(max)) and data transfer (D_Transfer) related to the link between S_er-2 and the initiating hosts using the Iperf tool. Equations (Eq. (1)–(4)) are used to obtain the values of throughput (T_h), the percentage drop in data transfer (%D_Transfer), the percentage increase in server load (%I_SL), and end-to-end Delay (D_E-E). Where the Round-Trip Delay (RTD) is obtained from the Iperf utility by using its h_ping directory.

(1)Th=Data_Transferin(Gbytes)Time(s) (2)%ISL=100−(100∗(Bd(max)underloadedconditions)Bd(max)undernormalconditions) (3)%DTransfer=100−(100∗(Data_Transferunderloadedconditions)Data_Transferundernormalconditions) (4)DE−E=(RTD2)

Table 5 represents the QoS parameters (B_d(max), T_h, D_Transfer, D_E-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 S_er-2 without the use of load balancing, there is a noticeable increase in the server load (%I_SL) as compared to the normal conditions. The percentage of data transfer (%D_Transfer) is also drastically decreased compared to normal conditions (i.e., 200 randomly generated HTTP requests from hosts H_st-1–H_st-30).

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

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 (H_st-1 to H_st-30) are first countered by an SDN controller that performs load balancing on network servers (S_er1, S_er2, S_er3, and S_er4) 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.

Table 6 represents the QoS parameters (B_d(max), T_h, D_Transfer, D_E-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 (B_d(max), T_h, D_Transfer, D_E-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 (B_d(max)) increases to 5.561 from 1.449 Gb/s. The T_h improves to 4.854 from 1.322 GB/s. There is also significant increase in D_Transfer, going from 1.652 G-bytes to 6.068 G-bytes. Regarding Eqs. (2) and (3), the (%D_Transfer) and (%I_SL) drop from 76.49% to 13.55% and 77.70% to 14.44%, respectively.

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

In this case, the SDN architecture is framed in a logically distributed controlled arrangement, as shown in Fig. 15. Thirty hosts (H_st-1 to H_st-30) are divided into four logically distributed SDN-based sub-networks (L_d1, L_d2, L_d3, and L_d4), each of which is overseen by a separate dedicated controller (C_d1, C_d2, C_d3, and C_d4). Now, instead of handling 20,000 HTTP requests by the single controller (C_Ps), the C_d1 and C_d3, handle 6000 HTTP requests apiece that come from network devices in sub-networks L_d1 and L_d3, respectively, using a proposed algorithm (ISSLM). Similarly, 4000 HTTP requests apiece are managed by C_d2 and C_d4 and directed from network devices inside L_d2 and L_d4 using the ISSLM algorithm with the help of logic presented in Table 4. Higher-level controllers C_p1 and C_p2 are responsible for overall network flow control management and fault tolerance.

The subnetwork controllers (C_d1, C_d2, C_d3 and C_d4) 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 (L_d1, L_d2, L_d3 and L_d4), 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 (B_d(max), T_h, and D_Transfer) in all sub-divided networks (L_d1, L_d2, L_d3, and L_d4) 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 (B_d(max)) for (L_d1, L_d2, L_d3, and L_d4) 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 (T_h) 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 (L_d1, L_d2, L_d3 and L_d4), respectively. (D_Transfer) 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 (L_d1, L_d2, L_d3 and L_d4), respectively. Moreover, the (%I_SL) 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 (L_d1, L_d2, L_d3, and L_d4), respectively. The (%D_Transfer) 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 (L_d1, L_d2, L_d3, and L_d4), respectively. These differences in B_d(max)and D_Transfer across the segmented networks (L_d1, L_d2, L_d3, and L_d4) are graphically represented in line graph format using the Gnu plot in Fig. 17.

In Case D, we tested and gathered the QoS parameter values (B_d(max), T_h, D_transfer, D_T_ransmission_D_elay) 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 D_elay_T_ransmission is calculated by Eq. (5) in both modes (heavy flow mode: M₂ and normal flow mode: M₁). The differential transmission Delay (D_T_ransmission_D_elay), as shown in Eq. (6), is a difference in milliseconds of transmission delay in (Heavy flow mode to normal flow mode: Transmission delay in M₂–Transmission Delay in M₁). 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 (B_d(max), T_h, D_Transfer) obtained under normal loaded conditions include a maximum bandwidth (B_d(max)) of 4.02 Gb/s and a data transfer (D_Transfer) volume of 7.02 Gbytes for 15 s.(5)Delay_Transmission=[DTransfer(Gbytes)]×8Bdmax(Gb/s) (6)Overall(D_Transmission_Delay)=Delay_Transmission(M2)−Delay_Transmission(M1)

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

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