A Reliable Load Balancing Fault Tolerant Multi-SDN Controller approach in a typical Software Defined Network

INTRODUCTION: In the 21 st Century, we have an emerging, modernized networking approach for efficient transfer of data in the form of packets i.e Software defined Networking (SDN). It is often recognized as the network paradigm acquired by an isolated independent control plane by the means of the underlying networking interface. As the communication medium is getting rapidly increased, the usage of the number of resources are also increasing in the same ratio, this results to connectivity problem in communication networks as well. If the development in technology is gaining more interest, the resource utilization will also increase. OBJECTIVES : In the proposed work here, we need to establish the connection between the client (or the end user) and the server by calculating the network performance using the parameters such as server response time and the throughput of the network by the method of load balancing. METHODS: T his paper aims to identify the new methods or techniques to improve the performance of SDN with the increase in reliability, specifically required to improve the real-time data delivery. Alternatively, a reliable disjoint, distributed Multi-SDN controller will be used, to collect the updated network information like packet size, connectivity, packet flow etc. The methods involved are ideal controller optimization technique, distruption acquiscent technique and Maximum flow shortest route technique. RESULTS: From the results obtained by the simulation, the Reliable Load balancing Fault Tolerant Multi-SDN Controller(RLFTMS) approach is more reliable, fault tolerant compared to the other existing traditional mechanisms. CONCLUSION: Load balancing based on the server response time, throughput is being compared , this improves the server workload ditribution among various datacenters. Ultimately the customers or clients will have a great experience in terms of the reducing response time and increase in the throughput.


Introduction
In recent years, computer networks plays an important role in the communication system and that too in Internet of Things (IoT) [11]. It is gaining more attention among the young and dynamic researchers to a large extent. The advanced features in communication are taking place in this modern era, users are gaining interest in the field of communication networks. Overall, the growth done in the field of research and development has reached its glory. This mechansim is getting popularity and lot of people are showing interest to do research under the area of Wireless Networks and in particular about SDN, since the growth in network traffic is reaching its glory and in particular future networks like 5 th Generation (5G) and 6 th Generation (6G) networks.
This motivates the researchers to build an efficient networking architecture named SDN which should be easily managed, programmable and having centralized accessibilty. This allows all the applications or the network operators to get the control of the whole network and make easy to understand the behaviour of the entire network as well. SDN makes the network software more useful [12].
In order to change the distributed approach of keeping control plane and data plane together, the SDN approach will make it centralized i.e making one controller acting in the control plane and all the other devices in the data plane are connected to it , so that the network programmability becomes simple and we can have separate data traffic and control traffic. In other words a centralized controller acting at the control layer will take care of the end users in the form of hosts depicted in the data plane. This helps in easy and simple programming ability of SDN [13].
Here, we focus on one of the important concept called fault tolerance. In the context of fault tolerance, SDN provides important opportunities with its central view on the whole network. Therefore, a fault tolerance mechanism is required which reduce single point of failure in the network by using multiple controllers. In SDN, considering all the three layers or planes, the fault tolerance is acting in all these layers , we need to take care about how to handle the fault in all the planes of SDN. The problem existing in data plane includes link failures and switch failures whereas the control plane takes care of the failure in connection between switch and controller or controller failures. The main function of the application plane is to detect the failure in an application which in turn will affect the connectivity established through northbound Application Program Interface (API) and it will spread to the other applications gradually [14].
As a significance, this mechanism also increases the scalability, reliability and high availability of services in the network.
Further, controllers are categorized into two types: centralized and distributed [1]. We need to understand the respective architectures of both types of the controllers. According to the survey done until now, the distributed controller approach where the control plane and data plane are coupled together faces the synchronization problem, connectivity issues, no proper fault management activities etc. In the centralized approach, the remote SDN controller is used to act as a centralized system and connects all the networking devices and will achieve complete access. This approach decouples the control plane and data plane, where in a single controller is acting like a master and the networking devices as slave. The principle resembles the masterslave approach. But, there is a limitation in SDN or centralized controller approach i.e they suffer from a single point of failure and also they will face the problem of resource utilization, scalability issues. In order to avoid this limitation, we make use of the multi-controllers as a backup controller and work cooperatively.
Further, the control plane consists of a suitable SDN controller in a typical SDN environment. The controller situated in the middle layer of this architecture consist of network operating system (NOS), helps to provide any network applications and also software-based services [15]. Further, single centralized controller, which is responsible for managing the entire network system is situated in the control plane. This can be both advantage and disadvantage for a network. One centralized network will monitor the whole network, this solves the scalability problem. Futher, there is a drawback in SDN [16], if a single point of failure occurs then the entire network fails. To overcome this, an updated mechanism should be proposed by having a Network Information Base (NIB) which is used to store all the switches acting in the data plane in order to handle the packets and also through the ingress port of the switch the packets will be arriving and they are matched to the flow accordingly [17].
Here we are making use of the Mininet tool and SDN controller named RYU [8][9] a free source and was developed by a telecommunication company in Japan named Nippon Telegraphy and Telephone(NTT). The word "RYU" means "flow" in their language. The main function of this controller is to provide easy and controlled flow of data, so that we can get a interactive networking platform. This controller supports some protocols like Netconf, Openflow and even managed properly as well. The language used and developed in RYU controller is python and it is the most efficient and EAI Endorsed Transactions on Internet of Things 04 2021 -02 2022 | Volume 7 | Issue 26 | e4 useful coding language for implementation of any required work related to SDN.
Further, due to the structural characteristics of SDN, the function of the switch is simpler and it is only responsible for data forwarding, makes the switch design simple [18]. The essence of the SDN concept is to separate the control layer from the data layer, which simplifies network management, improves network flexibility and scalability. In large networks, the good placement of the controllers makes the best use of the existing structure of links between the network nodes. One centralized controller is not enough to control all the nodes in a large SDN, as its performance is limited, and synchronization between the controller and every clients or nodes in SDN will not be in real time and there exits a signal propogation delay [19]. Because, single controller works for a small network, it is not suitable for the large networks, in order to improve the scalability in the network multiple controllers can be used in the entire network. In the multiple SDN controller scenario, either there can be a replication of network state information or it may be shared among all the controllers existing in the network. We should achieve synchronization among the controllers as per the periodic time to finally get consistency in the network [20].
In spite of applying various methods like testing, decoding, verification, validation, certification the rate of large-scale failures is more in the production networks and remain less suspectible [21]. The availability of resources to a load balanced network [2] is obtained by the method of optimization using the various process by reducing the response time, gradual raise or increase of throughput and reduce in the overloading of resources in the intended network. Multiple controllers are reserved for backup but we should take care about the scalability and availability issues in this mechanism. If there is any failure in the controller, the failed controller is replaced with an alternative controller which is already there in the queue. In order to achieve more reliability, we require many instances of the controllers and also have a well stock of alternative controllers in the form of backup and have the clear information about where to install the alternative controllers available [22]. Distributed controller handles the whole network, while maintaining complex tasks such as quality of service, security and load balance [23]. Here, in order to fullfil the available demands of the next generation networks, a logically centralized network is used, this even gives the backup for the network administrators to enable and regulate the network-wide traffic flows. Through this centralized approach we can create the dynamic network topologies defined as in the data centers and also policy based routing can be implemented in service providers or enterprise networks [24].
As shown in [3] [4] the motivation should be to implement the architecture of SDN using a RYU SDN controller which is a free source, mainly used for the analysis of the network and to evaluate in deep, performance analysis of SDN architecture for various parameters like the number of packets transmitted, packets received, throughput, bandwidth, round trip time etc.
In this paper, for a SDN network a proposed method for load balancing is explained in a new way by optimally load balancing the network by reducing the duration of time in response of the server. We define the metric for load balancer i.e the server response time, it is the time or duration of the requests commenced that means end users accepts the request and gets the response in the form of reply from server. If the load is heavy or high, then the server response time will take long time. Our approach should be efficiently help to calculate the server response time by using the load balancing method.
The main work carried out by this paper includes, • Using the SDN architecture, the performance metric like real time server response time is calculated w.r.t specified controller to design an efficient, load balancing scheme in the network.
• Realize the network traffic for the potential implementation of load balancing scheme using the suitable SDN Controller.
• Compare the performance metrics like the server response time , throughput and provide the effectiveness of the proposed scheme over the existing traditional approaches.
Finally, a reliable, disjoint and fault tolerant multi SDN controller has to be developed.

Related Works
In this section, we review the other researches related to the work we propose.
In [1], the work mainly focuses on Data center Networking and uses floodlight controller, uses load balancing algorithmic approach, but mainly it fails to use other controllers and no response time is considered with no dynamic methodology adopted to calculate the throughput of the system.
As in [2], SDN flexibility is used for load balancing describing real-time measurement of server response and it is not considering the energy saving issues and the balanced load is not achieved. In [3] [5], the comparison of round-robin, random etc. Startegies are considered but no server load and no real hardware is used and the controller is limited to POX alone.
In [4], Intercloud manager (ICM) in SDN is used to allocate network flows in cloud for monitoring and decision making in cloud network. This method fails to improve the performance of the SDN network and also the energyawareness is restricted to small scale.
A dynamic server load balancing technique is proposed using RYU controller in [6], with Mininet and Raspberry pi switch compared with Random, Round-robin load balancing strategies. But the testing of code done only for reliability and resource utilization, throughput and server response time is not considered here.
The performance test analysis on SDN controller is done in [7]. Parameters considered are throughput, Round Trip Time (RTT) using Mininet, RYU controller, and performance on bandwidth, throughput, RTT, jitter, packet loss using RYU are calculated. But the restriction here is only adopted to default topology and other topologies like linear, single, tree topologies are not taken into consideration.
RYU controller alone is used considering the bandwidth, throughput and RTT for custom topology between any 2 nodes in [8]. Comparison with other controllers the work carried out here is by considering the other networking parameters as well.
Deployment of Low-cost high performance open testbeds are carried out in [9] considering controllers like ONOS, floodlight, RYU etc. with low-cost open switch. But the networking functions like Quality of service (QoS), dynamic flow installation, server response time, throughput is not considered.
The SDN architecture is centralized, focus is on traffic engineering load balancing in data plane. In [10],bayesian network scheme is used to choose alternate path but no multi-controller scenario is used considering the standard network topologies to reduce the SDN controller overhead.
Sminesh et al [25], in their work partitioned the network using a modified-Affinity Propogation (AP) clustering algorithm and provides the input by calculating the distance between switch and other components, as well as uses link bandwidth between each .There is no mechanism of load balancing w.r.t server or the response time.No involvement of any external controllers like Mininet is involved, so the network traffic, performance could be analyzed. No efficient solution for placement of controllers and optimality is achieved w.r.t to the placement. Only the distance and bandwidth are considered as the input and no other parameters are considered. The major work involved here is about clustering and there is no other methods used for the load balancing of SDN controllers.

Failure of internal controllers is not been involved and no solution for the fault recovery and management.
Alenazi et al [26], developed a new nodal metric, nodal disjoint path (NDP), which measures a node's importance in terms of its diverse connectivity to other nodes. NDP determines the locations of the k-controllers to increase network robustness against targeted attacks by using USbased fiber-level networks and evaluate centralitybased attacks and random failures. The NDP-global algorithm evaluated here provides better network resilience in the face of centrality-based attacks and random failures. The results also indicate that the NDP-cluster algorithm has a delay performance comparable to that of the k-median algorithm and provides higher network resilience. There is no work carried out w.r.t the placement of software-defined SDNs.
Ruaro et al [27] proposed a multi-objective management based on a distributed SDN (D-SDN) architecture (SELF-SDN). Fault-tolerance experiments highlight the simplicity of the SDN paradigm to recover from faults in the NoC, not requiring additional hardware. Results related to multi-objective management demonstrate the fast reaction time of SELF-SDN to recover the communication latency faced to QoS loss and faults. But the work is not satisfied and no work is carried out in respect to extending management objectives by addressing power and energy by turning off unused CS routers and security.
Phemius et al [28], proposed DISCO, an extensible DIstributed SDN COntrol plane able to synchronize with the distributed and heterogeneous nature of modern overlay networks. A DISCO controller manages its own network domain and communicates with other controllers to provide endto-end network services by using AMQP protocol and evaluates inter-domain topology disruption cases. But more techniques helpful to extension for additional resilient and recovery mechanisms can be done so that a controller can take the control of switches from a neighbor domain on the fly in case of failure.
Yang et al [29], developed the SDN controller placement problem for single-link and multilink failures, respectively. For single-link failures, we develop a heuristic algorithm to address the controller placement problem. For multi-link failures, an efficient method Monte Carlo Simulation is being used to reduce the computational overhead. We conduct experiments with real network topologies, and the simulation results show that the heuristic algorithm can save significantly more time than the optimal algorithm, while achieving good performance and ultimately improves the time complexity of the algorithm. However, with a larger scale failure analysis, and a need for more precise prediction mechanism for those vulnerable links, nodes, and controllers are required.
Satheesh et al [30], developed a priority-based model using SDN to control the flow of data packets over the network, gives assurance to the bandwidth enforcement, and reallocation is made through virtual circuits. The network behavior of the system is continuously monitored through the machine learning model for normal and abnormal traffic data transmission to detect anomaly intruders. Flow-based machine learning (FML) model with SDN act as an intelligent system to limits the throughput virtually through the flow of reserved bandwidth and make use of extra bandwidth, which presents more than the utilization bandwidth for priority-based applications with minimal cost while compared with the traditional methods. However, steps have to be taken to improve network traffic in a real SDN environment.
In [25], a solution for controller load balancing, considering the dynamic load of each controller by developing an external SDN controllers has to be defined. As of [26] the proposed algorithms are to be applied to the placement of software-defined SDNs. In the paper [27] the concept where the requirement on extending management objectives by addressing power and energy by turning off unused CS routers and security is discussed. In [28], the technique has to be extended for additional resilient and recovery mechanisms so that a controller can take the control of switches from a neighbor domain on the fly in case of failure, in [29] a larger scale failure analysis, and provide a more precise prediction mechanism for those vulnerable links, nodes, and controllers are required and as of [30] some mechanism w.r.t steps has to be taken to improve network traffic in a real SDN environment.
Hence to overcome the above mentioned issues, a fault tolerant, multi SDN controller has to be developed.

System Architecture
RYU controller provides software components by making use of well-defined API's, this makes developers or the network admin to create new network management and control applications. RYU supports the well defined protocol named OpenFlow and with versions of 1.0,1.2,1.3,1.4 and 1.5 and the controller is implemented in the python language.
RYU SDN Controller consists of three layers or 3 planes. The lowest layer is the infrastructure or physical layer which consists of various physical and virtual devices interconnected via internet for the purpose of communication. It also consists of different devices placed within the same plane.
The middle layer or the 2 nd Layer known as control layer or the network lyer consists of network devices and hosts ,both connected via Northbound API's and Southbound API's.
Further, this layer is used for flow control mechanism i.e data traffic from one device to another device to provide the stability in the network without any network traffic overhead.
The interface between physical and control layer is done with the guidance of Application programming interfaces (API) i.e southbound API's like OpenFlow, OF-config etc.
The topmost layer is the application layer usually consists of network logic applications and business applications. The interface acting between the application layer and network layer is issued with the consultation of API's known as Northbound interfaces like OFREST, Firewall, Quantum etc.
The RYU Controller used here, make use of OpenFlow protocol to interact with the forwarding plane consisting of switches and routers for handling the traffic flows. The testing process is carried out using Openvswitch and also supported by some companies such as Centec, HP, IBM etc.
All these layers have the similar goal or target to collect the network intelligence at one fixed area or the place named the centralized controller. The objectives gathered here by the controller runs the algorithms and orchestras the new rules used by the controller. infrastructure layer, a middle Control layer and the above Application layer.

General System Architecture
Various topologies and the devices are constituted by the lowest layer which is formed of OpenFlow switches and connecting devices in any network. It is also known as forwarding plane or data plane and it's main responsibility is data packet handling initiated by the client or the user via any linked devices to obtain the network traffic and get forwarding information based on instructions from the control plane.
The control plane's main responsibility is decision making that is handling of packets and forwarding of the data at the linked devices properly across the network. The SDN controller is present or included in the middle control layer and it is used for the overall operation management of the entire system. The controller used here is RYU. All kind of network services related to the packet flow, data transmission, synchronization and updating of forwarding tables and even packet handling policies also reside in this layer.
To establish the connection and the transfer of data in between control layer and infrastructure layer is done via Southbound API and uses a well known protocol called OpenFlow protocol, which is used to maintain flow rules for forwarding of packets from controller. There is a fair independence between the controllers used to overcome any network issues or transmission issues and also resilience of the network in the control layer.
Finally, the application layer contains the information of any network services used and accessed in the entire network via the useful network operator. Additionally, this plane consists of the network behavioural information in terms of its applications and services. Some of the routing processes acting in the control layer where no applications are considered directly or even support this kind of operation are not considered to be the part of this layer. The connection or communication between the control layer and Application layer is achieved by Open Northbound API and the RESTful API.

Proposed Working Model
The working model of a typical RYU SDN framework architecture is depicted as shown in the figure 3.2.
The first (Topmost) layer is the Application layer. In this layer the testing and logical design of the application programs is thoroughly checked and made implemented. All the applications are acting in this layer including the End user applications, the Operator used and the OpenStack cloud orchestration. This layer is connected with the Network layer or the control layer through RESTful API, Northbound API, RestAPI and User defined API. Programming system arrangements, administrations and even the switch packet processing, brings numerous new potential outcomes to the system administration The topmost approach is the novel ideal controller optimization approach where the sub controllers used in the approach should be optimal and also it should take care of the controller load by checking the maximum capacity it can handle for any process to happen so that no problem should happen in the connectivity and also check the ping connectivity so that to verify whether all the connections are up to date and end to end connection can be done smoothly.
The middle layered approach in the Figure  3.2 is the novel disruption acquiescent technique. This technique is majorly used for checking the connectivity between the sub controllers and switches and in turn connected to the hosts. Further, to check the behaviour of the network i.e. normal or not especially the nodes in IoT networks. This approach uses Micro-cluster Outlier detection method which is based on the conditional entropy approach that is used for incorporating the network traffic flows, separation of the data traffic and control traffic using a deep packet inspection where the network behaviour can be easily judged and also we can check any security lapse has happened like the DDOS attack has happened or not. It helps us to eliminate the vulnerability of attacks as well. Ultimately, the unnecessary link failures in the network can be eliminated. This solves both the single link and multi-link failures by using distribution decision scheme containing load information and using the nearest switch which has lowest active nodes. In the multi-link failures, the controller cannot do it single-handed, so it will allow the nodes to migrate to the neighbouring switch linked with the respective sub controller.
Finally, the lower layered approach which is the Maximum flow shortest technique is used to determine the secured and fastest route of the network and also to overcome the overlapping of data in the network path. This technique is developed since it uses shortest and minimal path consisting least number of links, so that any interference of the packet happens can be avoided. It will also utilize the minimum available bandwidth capacity and flow weightage through the nodes and hence eliminate any weak nodes available in the network to achieve maximum flow capacity with minimal links and by using the shortest path without any overlapping by employing suitable transfer protocol for the proposed architecture. Additionally, flexible and common switch is attached with two controllers, is in case any controller failure happens, then the concerned switch will act as the backup link and path can be reestablished without any problem.

List of Available SDN Controllers
There are many controllers acting in the control layer of SDN. Among them POX, RYU, OpenDaylight, Floodlight are important. The list of other controllers shown in the Table 3.1 exhibiting the comparison of various controllers with controller name, programming language, Developer, license provider and the platform support.

Comparison of Various SDN Controllers
The following table 3.1 signifies the comparison of the variuos SDN controllers with their programming languages used, Developer of the controller, License provider and platform support. provided any mechanism to achieve high-level performance or fault-tolerance at high scale in SDN based networks in which high latency are the most essential issues to be taken care of, since it happens by the variation of links heterogeneity through the backup path. During no failure in the network or if it is a ideal network the backup controllers remains passive and will not be used for the process.Inorder to solve this, Load balancing during the failure becomes an important concern. To overcome scalability issue, previous research has used multi controllers but the optimal numbers of controllers to be used is not yet determined which leads to overloading and high complexity in load balancing. Many attacks lead to failure of links, by detecting those attacks, the link failure can be eliminated at initial stage itself which is not yet incorporated with the SDN plane. Generally, many techniques are employed for overcoming link failure but the complex nature of the link prediction path and too many paths and backup leads to high energy consumption and high computational time. The efficient route of the network must be determined and overlapping of data in the path must be overcome. Hence to overcome all the issues mentioned a novel technique has to be implemented.
SDN technology can help a network prepare for a successful and stable IoT deployment which can deliver the agility and flexibility that the Internet of Things demands. The architecture of the SDN is framed in a Multi Controller Framework in which a main controller is linked with optimal number of sub-controllers.
As shown in the Figure 3.2, the optimal number of sub-controllers is required to be determined which is carried by adopting a novel Ideal Controller Optimization approach which takes into account the maximum capacity of the controller, data packet size and average request of data to the controller and the required controllers are connected in series in the control plane of the network. Each subcontroller is connected to various switches which are linked with nodes. In order to identify abnormal behaviour of nodes in IoT networks a novel Disruption acquiescent technique has been introduced which uses Micro-Cluster Outlier Detection with conditional entropy approach incorporating traffic separation techniques using deep packet inspection which not only detects the abnormal behaviour but it also decides whether the abnormality has been caused by a DDoS attack and eliminates the vulnerability of attacks. Thus unwanted link failures are highly eliminated. Even, when a link failure occurs the node automatically gets migrated to the neighbouring node using distributed decision scheme with load informing strategy which considers the nearest switch with lowest active nodes. In case of multilink failure, the controller migrates from all the nodes to another switch which is linked to other controller. Moreover, in SDN technology, delays will be the most essential issues to be taken care of, since it happens by the migration of links inaccurately which causes overlapping via the saved path. In order to do route discovery in the network and to overcome the overlapping of data in the path a novel Maximum Flow Shortest Route Technique is developed in which shortest path consisting minimum number of links is achieved thereby avoiding the interference of the packet by utilizing the minimum residual bandwidth capacity and the weightage of flow through the nodes and thereby eliminating the weak nodes to get the maximum flow with shortest path without overlapping by employing transfer protocol for the architecture.
Also, a common switch is linked with two controllers; in case of controller failure the switch acts as a backup path. In case of overloading in the main controller, a dormant controller is allocated for the routing. This results to get an appropriate flow entries that can be generated priorly to avoid the overloading of control channel and determine the latency or delay in path formation. If any link or controller failure occurs, the active controllers take over which in turn, controls the flow of data over various links and promptly replace the routing. Hence a reliable fault tolerant with no link faults or failure in an interactive, secured SDN has to be implemented.

9.
Use FTP protocol to get Maximum flow with shortest path without overlapping.

end while
The ideal controller optimization approach is depicted in Algorithm 5.1. Initially, the main controller is started. Then, the subcontrollers are connected to the main controller. For each subcontroller, from line 3 to line 8 as depicted, collect and record the maximum capacity of controller (Max_controller_capacity), Data Packet size (DPsize) and Average request of data (AREQD). Connect all these parameters in series to the control plane of SDN. In this way, the main controller is connected to optimal subcontrollers and in turn the subcontrollers are linked with the end hosts or nodes in the network.
The second component or technique is Distruption Acquiescent Technique which is depicted in Algorithm 5.2, we are checking for the abnormal node behaviour in IoT. Initially, after the system is started, the node behaviour is verified. For each host or node using the approaches like Micro-cluster Outlier detection and conditional entropy approach, calculation of the traffic separation is done based on the data traffic and the link traffic. Using the method, Deep Packet Inspection(DPI), we obtain the abnormality information in node. Further, the abnormality can happen from DDOS attack. Using DPI technique the vulnerability of attacks are eliminated and even unwanted link failures are also eliminated.
There exists two types of link failures, single link and multi-link failures. If single link failure occurred, then automatic node migration can happen to the neighbouring node. To do this we use distributed decision scheme with load information strategy, obtain the nearest switch information with lowest active nodes. In case of multilink failures, node migration is done with the help of controller to other switch or (Nodes to Switch Migration). These information are linked to the other subcontrollers. Finally, store the node abnormality and correct it to eliminate the unnecessary information.
In the third technique the maximum flow shortest route technique is explained in Algorithm 5.3. Here we need to determine the overlapped free route for IoT Network. Once the system is started, in each host, get the backup path in each network. Calculate the path having minimum links in network. If the shortest path is achieved, the packet interference is avoided. Calculate the packet interference by considering miniumum residual bandwidth capacity, node flow weightage. Further eliminate the weak nodes.
Further, by using File Tranfer Protocol (FTP) to get Maximum flow with shortest path without overlapping. If any failure of the controller, switch will having the backup path. Suppose if there is an overload of main controller, use dormant controller for routing. Additionally calculate the overlap free path by considering the control channel overhead and path information latency and store the result containing the error free controllers and optimal links and develop secured SDN.

between controllers, switches and Hosts
According to the figure 6.1 application model, the main controller C0 i.e the remote controller which is RYU here, is connected to three sub controllers, C1, C2 and C3. In turn, the subcontrollers are connected to switches which are internally connected to each other. We can find the connection established between the two ends i.e the host machines with that of the switches. The hosts or clients are connected to the switches. Through the switches, hosts can connect to the controllers. Here, SDN follows the centralized approach, we have a main controller. If the hosts cannot get information about the data packets from the switches, then the switches will connect to the controllers and through it, there is a connectivity established between the remote main controller with the sub-ordinate controllers which are subcontrollers in this case. Now the controller will pass the information to the sub-controllers, in turn the subcontrollers will pass the data packets to switches and finally it will reach the hosts for processing of data. Like this we have a efficient and guaranteed data communication between the hosts or clients and the controllers.
The proposed system model appears to be a layered architecture consisting of the main controller(C0) in the above layer, sub-controllers below it, and number of switches connected with one more host connecting to the switches in the middle and the bottom layers. This will make the connection establishement easier and also if any

5.
If receive a Packet_in message then 6. Parse message;

7.
If the source address of the received packet is the server, the destination address is the controller then 8.
Record the time Tarrive of received message;

9.
Calculate the response time by the formula T response = T arrive -T send ;

10.
Store response time; The ultimate aim of the preferred algorithm is to attach the controllers with the main-controller and the switches and ultimately to the end hosts. Check the ping connectivity and verify the bandwidth of the link and obtain the minimum bandwidth to get the least server response time and the throughput.

Server Response Time Measurement in Real-Time
As in [2] , to measure the response time of a server there is a strategy of obtaining the it and it is as follows: Step1: Generate Packet_Out message and pass to Switches. The controller commences once the system starts, further the controller checks the time interval say 't' to send the message i.e the transmission time and makes the initiation of sending the authenticated message and makes note of the initiation i.e the start time and the transmitted time. There should be a synchronization established between the servers available in the pool of resources and the message transmitted. The content of this Packet_out message includes the information of data in terms of packet, their source address, IP address of the controller used and also the designated receipent address attached with the respective server IP.
Step2: Handling of Packet_out message by Switches. Next, the intended message initiated by the controller is received by the respective OpenFlow switch, the respective switch will check the data packets by parsing and transfers these packets to the respective servers.
Step3: Reply message generated from server, is received by the controller and calculates the the response time of the server. The client request from the server is done in a form of a simulation, once the controller generates the data packets and the controller IP will be acting as the destination address. The flow table gets a new entry in a form of the Packet_in message, therefore this message need to be sent by the server to the controller. Further, the controller receives the incoming time of the parsed packet_in message data packet from the respective server. This results, to obtain the response time of the respective server and also the database will be update accordingly.
Step4: Again and again go through step1, step2, and step3 until end condition is reached.  The throughput is nothing but the measure of the performance of the network. The comparison of the various clients in the SDN network is done and graph is plotted as shown in figure 7.1 and indicated in the   7.2, the proposed algorithm has a lower response time than SD-WLB, LBBSRT, round robin and random algorithms. Based on these methods, we can clear see that the proposed (RDFTMS) method is having less server response time i.e 1.3 seconds with that of RND, RR, LBBSRT, SD-WLB who have 3.9 seconds, 2.5 seconds, 2.2 seconds and 1.8 seconds respectively.  As shown in the figure 7.3, we need to calculate the TCP bandwidth between the clients. We have three topologies mentioned here namely, custom SDN, default SDN and the proposed (RDFTMS) SDN. The graph is plotted between Nodes connected vs Gigabits per second. The respective output shows that the suggested methodology has better TCP bandwidth compared to the other two approaches.

Results and Discussion
The following Table 7.3 signifies the TCP bandwidth between various clients : We need to calculate the TCP Bandwidth between the clients to check the performance of the network. From the Table 7 The bandwidth of the network is defined as the computation that indicates the maximal capacity of communication media links to transfer the data packets over a network in a particular interval of time. Figure  7.3 explains the TCP bandwidth compared with that of proposed topology, default topology and custom topology.
In the process of calculating the bandwidth using the Open Flow switch with RYU controller, the performance metrics obtained represent the data packets transferred from Client 1(C1) to Client 2 (C2) in the proposed topology is 26.0 Gbps, in custom topology it is 26.7 Gbps and in default topology it is 25.1 Gbps. Similarly for the packets transferred from C1 to C3 in proposed topology it is 26.2 Gbps and that of custom and default topology it is 25.2 Gbps and 24.5 Gbps, between C1 to C4 , for proposed topology it is 26.6 Gbps and that of custom and default topology it will be 25 Gbps and 24.4 Gbps.
Similarly the proposed topology has good improvement compared to the custom topology as depicted in the  The throughput test in the controller is evaluated for the maximum amount of data, it is processed in a second between two nodes, measured in bits per second or data packets per second. Here iperf3 utility is used to test the controller throughput performance. In order to measure the TCP throughput, iperf3 is executed for 10 seconds on client side and data is collected every 1 second on the server side. The executed result is shown in table 6 and represented graphically in figure 8. It supports to understand about the end-to-end performance of the network.
As in Figure 7.4, highest and lowest throughput in gigabits is approximately 37.6 gigabits and 27.4 gigabits between C1 and C2 node, 37.7 gigabits and 27.1 gigabits between C1 and C3 node, 29.3 gigabits and 26.2 gigabits between C2 and C3 node.  Table 7.4, we can see the comparison of the average throughput between different clients i.e Client1-Client2, Client1-Client3 and Client2-Client3. From the result we can clearly mention that the average throughput between Client2-Client3 is better compared to the other comparison of the clients. (iperf3 command used to test the throughput between the clients)   Once, the connection is established, using the iperf command, calculation of Bandwidth in switches are done. The minimum bandwidth is taken among them and it is used for the further process. It is as shown in the figure 7.6.

EAI Endorsed Transactions on
Internet of Things 04 2021 -02 2022 | Volume 7 | Issue 26 | e4 To check whether the connection is established properly, we need to conduct the ping test between the client and server. This process is carried out as shown in the figure 7.7. As shown in the figure 7.8, the round trip time between the client and the server is calculated after performing the ping command and clearly showing the number of packets transmitted, received and also any packet loss has occurred and even the time to obtain the round trip time.
Based on the results obtained and comparison done with that of the traditional methods such as SD-WLB, LBBSRT, Round Robin (RR) and Random selection methods, the RDFTMS mechanism is having superiority and there is improvement w.r.t the average server response time by 18%, 19.58%, 33.94% and 57.41% respectively. Similarly, the enhancement of throughput in an average w.r.t these algorithmic techniques are also considered and they appear to be 8.25%, 16.52%, 29.72% and 58.27% respectively.

Conclusion
Load balancing based on the server response time, throughput is being compared , this improves the server workload ditribution among various datacenters. Ultimately the customers or clients will have a great experience in terms of the reducing response time and increase in the throughput. The controller is considered as the master mind of the network and is majorly anlayzed to get the flow of network traffic in the real time so that it is easily monitored to get the clear idea of the packet flow in the heavy network traffic. For any efficient client to server communication to happen, i.e nothing but the smooth traffic movement between any two nodes , we need an effective and efficient mechansim of movement of data in the form of packets so that easy flow of data can happen without any transmission impairment. In this work the controller used is RYU. It is mainly used to gain resource utilization so that the network traffic is better and to achieve high network performance. In future, using any deep learning or machine learning mechanisms with other SDN controllers, calculate the performance of the network in terms of server response time, throughput by considering other metrics like packet loss, delay, jitter. Finally developing a improvised, reliable, fault tolerant SDN for the efficient communication between the intended client or the host and the respective server.