A Multi-Controller Load Balancing Algorithm for SDMANET

Abstract

The present invention discloses a multi - controller load - balancing algorithm for SDMANET. In order to cope with the topology changes caused by the arbitrary movement of SDMANET nodes, switches are divided into four situations, and it is judged which situation the switch is in according to the control - link state and the corresponding policy is executed. In order to improve the quality of the SDMANET control link, the link quality between the switch and each controller is monitored, and the change in the corresponding control - link quality before and after the switch migration is calculated. In order to reduce the number of switch migrations, the degree of load balance of the controllers is considered. The more balanced the load is, the fewer cases where switches need to be migrated due to controller overload. In order to avoid unnecessary migrations caused by node movement, the time that the switch can move within the communication range of the corresponding controller is calculated according to the position and movement speed of the switch. By combining the above aspects, the source controller, the destination switch, and the destination controller are calculated, and the quality of the control link is improved by migrating the switch fewer times, thereby improving the performance of the SDMANET control plane.

Description

Technical Field

[0001] The present invention relates to the field of network transmission technologies, and in particular, to a multi-controller load balancing algorithm for SDMANET. Background Art

[0002] Existing multi-controller load balancing algorithms can be applied to wired SDN networks with stationary nodes and can dynamically map switches to controllers according to the changes in SDN control plane traffic. For example, in Document 1 ([1]

[0003] Hu, Tao et al. "EASM: Efficiency-aware switch migration for balancing controller loads in software-defined networking." Peer-to-Peer Networking and Applications 12 (2019): 452-464) proposed an efficiency-aware load balancing algorithm (EASM). The algorithm determines whether the controller load is balanced through the load difference matrix and the trigger factor, then calculates the migration efficiency based on the load balancing rate and the migration cost, and changes the mapping relationship between the switch and the controller based on the migration efficiency model. Another example is the literature 2 ([2] A. Filali, S. Cherkaoui and A. Kobbane, "Prediction-Based Switch Migration Scheduling for SDN Load Balancing," ICC 2019-2019 IEEE International Conference on Communications (ICC), 2019, pp. 1-6). By recursively calling the ARIMA model to predict the traffic sent by each switch in the next few seconds, the long-term load of the controller can be predicted, so as to migrate the switch in advance at the necessary moment to prevent the controller from overloading. Another example is the literature 3 ([3] N. Aljeri and A. Boukerche, "A Mobility-based Switch Migration Scheme for Software-Defined Vehicular Networks," ICC 2021-IEEE International Conference on Communications, 2021, pp. 1-6). Considering the mobility and density of SDVN vehicles, the mobility of vehicles is evaluated by the fixed base station and the average session time of vehicles between the base station and its neighboring domains in other domains. The higher the mobility, the higher the processing cost and delay of the corresponding controller. The algorithm changes the mapping between the fixed base station and the controller by comparing the average session time, reducing the overall migration delay of the vehicle and the cost of the vehicle moving between domains.

[0004] However, there is currently no multi - controller load - balancing algorithm that takes into account the quality of the SDN control link. The algorithms proposed in references [1], [2], and [3] are all for wired SDN networks. After a switch joins the network, there is no corresponding strategy to maintain the mapping between the new switch and the controller. When the Master link of the switch is disconnected, it cannot be managed by other controllers either, and there will be a situation where the switch cannot connect to any controller within its communication range. Therefore, the algorithms proposed in the above - mentioned references do not support node mobility and cannot be used in SDMANET. In addition, the migration cost defined in reference [1] considers the number of hops between the switch and the controller. SDN determines the transmission path of data packets in the control link through a routing protocol. For SDMANET (SDMANET is the SDN mobile ad - hoc network (MANET)) with rapidly changing topologies, the number of hops in the path between the switch and the controller will change in real - time due to node mobility. Therefore, the accurate migration efficiency cannot be obtained. The prediction of controller load in reference [2] does not consider the impact of the change in the number of nodes on the load at future moments. Using time - series methods to analyze historical data can only predict the load of each switch, but cannot accurately predict the controller load. In addition, the algorithm it proposed is only applicable to large - scale networks that generate a large number of new flows per second and requires long - term observation of the network, and is not applicable to SDMANET with fast - moving nodes. Although reference [3] considers the mobility of vehicles, only fixed base stations participate in switch migration. The fixed base stations are wired to the controllers, and vehicle movement does not affect the communication between the fixed base stations and the controllers. If this protocol is used in SDMANET, there will still be a situation where any moving switch cannot connect to any controller within its communication range. Secondly, although both vehicles and fixed base stations can be abstracted as SDN switches, this protocol does not pay attention to the mapping relationship between vehicles and controllers. The mobility of vehicles is only used as a basis for judging whether to migrate the fixed base stations. Essentially, it is still a multi - controller load - balancing algorithm for wired SDN networks.

[0005] For SDMANET networks, the algorithm not only needs to consider the dynamic changes in control - plane traffic, but also needs to consider the characteristics of wireless - link communication between nodes and the arbitrary movement of nodes. First of all, compared with the SDN network with stationary nodes, in SDMANET, there are situations where nodes leave or join the network and control links are disconnected due to node mobility. There is currently no multi - controller load - balancing algorithm that supports SDN networks with node mobility. When a switch node joins the network, the existing algorithms cannot decide which controller manages the switch. When the link between the switch and its Master controller is disconnected, the existing algorithms cannot determine whether the switch has left the network, nor can they migrate it to other controllers that can communicate with it. In addition, compared with wired SDN networks, the quality of the wireless control link in SDMANET is poor, with more packet loss and mis - packets, and the performance of the control plane is low.

[0006] Based on the above considerations, the present invention proposes a multi - controller load - balancing algorithm for SDMANET, which takes into account the characteristics of poor wireless control link quality and node mobility in SDMANET. Summary of the Invention

[0007] Aiming at the deficiencies of the prior art, the present invention jointly considers the control link quality, load - balancing degree, switch location, and moving speed, and proposes a multi - controller load - balancing algorithm for SDMANET. This algorithm can cope with the topological changes caused by the arbitrary movement of SDMANET nodes, support the arbitrary movement of nodes, and can improve the control link quality with as few switch migrations as possible, thereby improving the performance of the control plane of SDMANET adopting a multi - controller architecture.

[0008] To achieve the above object, the present invention provides the following technical solutions:

[0009] The present invention provides a multi - controller load - balancing algorithm for SDMANET, including the following steps:

[0010] S1. Create a mapping between switches and controllers, record and update the set of switch conditions in real - time; the switch conditions are divided into four types: leaving the network, joining the network, Master link disconnection, and maintaining the connection. Determine which condition the switch is in according to the control link state, and execute the corresponding strategy to ensure that each switch in the network is always managed by exactly one controller.

[0011] S2. Dynamically maintain the mapping between switches and controllers by jointly considering the control link quality, load - balancing degree, switch location, and moving speed, and calculate the source controller, destination switch, and destination controller.

[0012] Further, the specific method of step S1 includes:

[0013] S11. Algorithm initialization: Create a mapping M between switches and each controller and a set G for recording switch conditions.

[0014] S12. Monitor the control link connection status in real - time and maintain the mapping M: Monitor whether the Master link and Slave link between the controller and each switch are maintained, and monitor whether a new connection is established.

[0015] S13. Update the switch status and maintain the set G: If the number of switches in the topology increases, update the corresponding switch to the joining - network condition; if the Master link is disconnected and the corresponding switch does not have a Slave link, update the switch to the leaving - network condition; if the Master link is disconnected but the corresponding switch has a Slave link, update the switch to the Master - link - disconnected condition.

[0016] S14. Execute the corresponding policy: If the switch is joining the network, select the controller that can communicate with it and has the lowest load as its Master controller. After completion, update the switch status to connected. If the Master link of the switch is disconnected, change its Slave controller with the lowest load to the Master controller. After completion, update the switch status to connected.

[0017] Furthermore, in step S12, inactivity - probe probes are sent at fixed time intervals to detect whether the Master link and Slave link are connected.

[0018] Furthermore, the specific method of step S2 includes:

[0019] S21. Monitor the link quality between the switch and each controller, and calculate the change in the corresponding control link quality before and after the switch migration.

[0020] S22. Calculate the time that the switch can move within the communication range of the corresponding controller according to the position and moving speed of the switch.

[0021] S23. Calculate the load - balance rate LBR.

[0022] S24. Evaluate the policy of migrating each switch to each controller, and select the mapping of the source controller, destination switch, and destination controller corresponding to the highest evaluation value.

[0023] Furthermore, in step S21, the link quality includes Master link quality and Slave link quality. Among them, the link quality is reflected by monitoring the re - transmission rate.

[0024] Furthermore, the switch sends inactivity - probe probes at fixed time intervals to monitor the packet - loss rate of the control link, and sends them to the controller through custom OpenFlow messages.

[0025] Furthermore, step S21 calculates the change in the corresponding control link quality before and after the switch migration through the following formula:

[0026]

[0027] where q in is the control link quality between switch s i and controller c n , and q im is the control link quality between switch s i and controller c m .

[0028] Further, in step S22, the position coordinates of the switch are P(x1, y1, z1), and the calculation formula for the moving speed v of the switch is:

[0029]

[0030] where (x2, y2, z2) are the coordinates of the position P' of the switch at the previous moment, and Δt is the unit time interval;

[0031] The calculation formula for the time that the switch can move within the communication range of the corresponding controller is:

[0032]

[0033] (x q ,y q ,z q ) are the coordinates of the switch node;

[0034] The normalization of the time that the switch can move within the communication range of the corresponding controller after migration relative to before migration is expressed as:

[0035]

[0036]

[0037] τ ij reflects the time that the switch can move within the communication range of the corresponding controller after migration relative to before migration, and after normalization, β is obtained i,mn .

[0038] Further, in step S23, LBR is the load balancing rate between controllers, which is expressed as:

[0039]

[0040] n is the number of controllers, and L is the controller load.

[0041] Further, step S24 evaluates the strategy of migrating each switch to each controller through the following formula:

[0042] score = β i,mn (α1Δ i,mn +α2LBR)

[0043] where α1 and α2 are coefficients, and Δ i,mn represents the change in the corresponding control link quality after the switch s i migrates from controller c m to controller c n , and β i,mnNormalization of the time that the switch can move within the communication range of the corresponding controller after migration compared to before migration; LBR is the load balancing rate between controllers.

[0044] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0045] 1) In view of the characteristics of arbitrary movement of SDMANET nodes, the present invention adopts different strategies based on the connection situation of the control link, supports the arbitrary movement of nodes, ensures that the switches in the network are always effectively managed by the control plane until they leave the network, and ensures that subsequent algorithms can be used for SDMANET.

[0046] 2) In view of the wireless control link of SDMANET, the present invention proposes a multi-controller load balancing algorithm by combining control link quality, load balancing degree, switch position and moving speed, improves the quality of the SDMANET control link on the basis of ensuring that the controller is not overloaded, reduces the number of switch migrations, and has higher performance of the SDMANET control plane. Description of the Drawings

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those of ordinary skill in the art, other drawings can also be obtained according to these drawings.

[0048] Figure 1 It is a flowchart of a processing method for SDMANET node movement provided by an embodiment of the present invention.

[0049] Figure 2 It is a schematic diagram of an SDMANET network provided by an embodiment of the present invention.

[0050] Figure 3 It is a schematic diagram of a multi-controller SDN architecture provided by an embodiment of the present invention. Detailed Embodiments

[0051] In order to better understand the technical solution, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described examples are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art based on the present application belong to the scope of protection of the present invention.

[0052] A multi - controller load - balancing algorithm for SDMANET proposed by the present invention. First, to solve the problem that the movement of SDMANET nodes causes switches to be unable to connect to the controllers within the communication range normally, the algorithm divides switches into four situations: leaving the network, joining the network, Master link disconnection, and maintaining connection. It determines which situation the switch is in according to the control - link status and executes the corresponding strategy. Second, regarding the quality of the control link, the algorithm monitors the link quality between the switch and each controller and calculates the change in the corresponding control - link quality before and after the switch migration. Third, in order to reduce the number of switch migrations, the algorithm considers the degree of load balance of the controllers. The more balanced the load is, the fewer cases of switch migration due to controller overload. To avoid unnecessary migrations caused by node movement, the algorithm calculates the time that the switch can move within the communication range of the corresponding controller according to the position and movement speed of the switch. The longer the time is, the more suitable it is for migration. Finally, by combining the above aspects, the source controller, the destination switch, and the destination controller are calculated, and the quality of the control link is improved by migrating the switch fewer times, thereby improving the performance of the SDMANET control plane.

[0053] On the one hand, aiming at the characteristic of arbitrary movement of SDMANET nodes, the present invention proposes a processing method for the movement of SDMANET nodes, adopting different strategies based on the connection situation of the control link to ensure that the switches in the network are always effectively managed by the control plane until they leave the network, ensuring that the subsequent algorithm can be used for SDMANET. As Figure 1 shown, it includes the steps:

[0054] (1) Algorithm initialization: Create a mapping M between the switches and each controller and a set G for recording the situation of the switches;

[0055] (2) Real - time monitor the connection situation of the control link and maintain the mapping M: Monitor whether the Master link and Slave link between the controller and each switch are kept connected, and monitor whether a new connection is established;

[0056] (3) Update the switch status and maintain the set G: If the number of switches in the topology increases, update the corresponding switch to the joining - network situation; If the Master link is disconnected and the corresponding switch does not have a Slave link, update the switch to the leaving - network situation; If the Master link is disconnected but the corresponding switch has a Slave link, update the switch to the Master - link - disconnection situation;

[0057] (4) Execute the corresponding policy: If the switch is in the situation of joining the network, select the controller that can communicate with it and has the least load as its Master controller. After completion, update the switch situation to maintain the connection. If the switch is in the situation of the Master link being disconnected, change its Slave controller with the least load to the Master controller. After completion, update the switch situation to maintain the connection.

[0058] As Figure 2 shown, all nodes in SDMANET communicate through wireless links, and the nodes can move arbitrarily. The switch can be directly wirelessly connected to the controller or can be connected to the controller through other node relays. The transmission path of information between the switch and the controller is determined by the routing protocol, and this path changes continuously with the topology change. For example, Figure 2 switch 1 in Figure 2 can be directly connected to controller A, switch 7 can be connected to controller C through switch 3 relay, and switch 1 can also be connected to controller C through controller A and switch 6 relay. In addition, there is a situation in SDMANET where the switch cannot be connected to any controller, such as

[0059] switches 8 and 9 in Figure 2 cannot establish a connection with any controller. Figure 2 As the SDMANET nodes move continuously, there will be a situation where nodes leave the network, that is, the switch disconnects from all controllers in the SDN control plane. For example, if Figure 2 switch 7 in Figure 2 moves continuously to the right until it disconnects from switch 3. At this time, switch 7 cannot communicate with any controller, and this switch node leaves the network. As the SDMANET nodes move continuously, there will also be new nodes joining the network, that is, there will be a new switch establishing a connection with the controller in the SDN control plane. For example, if Figure 2 switch 8 in Figure 2 moves continuously to the left until it enters the communication range of controller B. At this time, switch 8 can establish a connection with controller B, and this switch node joins the network.

[0060] The multi - controller SDN architecture is as Figure 3As shown, this architecture is implemented based on the OpenFlow protocol. The OpenFlow protocol divides controllers into three roles: Equal, Master, and Slave. Equal is the default role of the controller. Controllers with the Equal and Master roles have full access to the switch and can send and receive all OpenFlow messages. However, the switch must ensure that the Master controller is its only controller. If a controller's role changes to Master, the switch will change the roles of other controllers to Slave. A controller with the Slave role has read-only access to the switch and cannot send messages to the switch to modify the switch's state, such as OFPT PACKET OUT and OFPT FLOW MOD messages, etc. That is, a controller with the Slave role cannot manage the switch. For example, Figure 3 in Figure 3 , the Master controller of switch 1 is controller A, and the Slave controllers are controller B and controller C. At this time, only controller A can perform operations such as issuing flow tables to switch 1, that is, only controller A can manage switch 1.

[0061] For SDMANET, due to nodes moving out of the communication range or the quality of the wireless link between nodes decreasing, it may cause the switch to disconnect from the Master controller. Since the Master controller is the only one, the switch that disconnects from the Master link cannot be managed by any controller. If there is still a Slave controller for this switch, it means that it has not left the network, and a Slave controller should be selected and its role should be changed to Master to let this controller manage the switch. For example, if Figure 3 in Figure 3 the Master link between switch 1 and controller A is disconnected, then controller B or controller C needs to be selected as the Master controller of switch 1. In addition, if the Slave link of the switch is disconnected, it will not affect the switch.

[0062] To ensure that all switches in the network can be effectively managed by the SDN control plane, the algorithm maintains the mapping M between switches and each controller, and classifies switches into four situations: leaving the network, joining the network, Master link disconnection, and maintaining the connection. These four situations respectively correspond to: the switch disconnects all links with the control plane; the switch in the situation of leaving the network adds a control link; the Master link of the switch is disconnected but there are still Slave links; the control link of the switch remains unchanged, a new Slave link is added, or the Slave link is disconnected. The algorithm updates the set G used to record the situation of the switch in real time, and adopts different strategies based on the situation of the switch to ensure that the switches in the network are always managed by one and only one controller, thereby ensuring that the multi-controller load balancing algorithm proposed in the present invention can be used in SDMANET. The specific processing method is as follows:

[0063] Step 1: Algorithm initialization. Create the mapping M between switches and each controller and the set G used to record the situation of the switch, where the mapping M can distinguish the roles of the controllers. If the switch exists in the topology, it means that the switch must have a Master controller, and it can be judged that the switch is in the situation of maintaining the connection. If the switch does not exist in the topology, it may be because the Master link has been disconnected before the algorithm is executed, resulting in that although the switch can communicate with the control plane, it cannot be added to the network topology by the topology discovery mechanism. Therefore, the situation of the switch cannot be accurately judged based on the network topology. The algorithm maintains the mapping M in real time through Step 2, and updates the set G according to the complete mapping relationship.

[0064] Step 2: Monitor the connection status of the control link in real time. After the OpenFlow secure channel is connected to the controller, it will periodically send inactivity-probe probes to the controller to detect whether the connection is maintained. The default sending interval of the probes is 15s. There is more control information on the Master link that can be used to judge whether the connection is maintained, but there is almost no message transmission on the Slave link. The algorithm uses the inactivity-probe probes to detect the Master link and the Slave link, shortens the sending interval to 3s, and if no message is received by the controller within two time intervals, it is regarded as the link being disconnected, and the mapping M is updated accordingly. When the switch establishes a connection with a new controller, the mapping M is also updated accordingly.

[0065] Step 3: Update the switch status. According to the mapping M, the mapping relationship between the switch and other controllers can be known. If there is no control link for the switch, the corresponding switch in G is in the situation of leaving the network. If the switch was in the situation of leaving the network at the previous moment and now a new control link is added, the corresponding switch in G is in the situation of joining the network. If the switch has a Master controller, the corresponding switch in G is in the situation of maintaining the connection. If the switch has no Master controller but has Slave controllers, the corresponding switch in G is in the situation of the Master link being disconnected.

[0066] Step 4: Execute the corresponding policy. According to the set G, the current situation of the switch can be known. If the switch is in the situation of joining the network, select the controller with the smallest load that has a mapping with it as the Master controller. After completion, update the situation of this switch to maintaining the connection and update the mapping M. If the switch is in the situation of the Master link being disconnected, change its Slave controller with the smallest load to the Master controller. After completion, update the situation of this switch to maintaining the connection and update the mapping M. Switches in the situation of maintaining the connection and leaving the network do not need to perform operations.

[0067] On the other hand, the present invention proposes a multi-controller load balancing algorithm for the SDMANET wireless control link, combining the control link quality, load balancing degree, switch location, and moving speed, which improves the SDMANET control link quality on the basis of ensuring that the controller is not overloaded and reduces the number of switch migrations.

[0068] The algorithm considers the SDNMANET control link quality, so it is necessary to obtain the quality of all control links in the network. The OpenFlow protocol is implemented based on TCP. No matter what reason causes an error in the OpenFlow message, reliable transmission will be ensured through retransmission. Therefore, the algorithm reflects the control link quality through the retransmission rate. The higher the retransmission rate, the worse the control link quality. There is a lot of control information transmission on the Master link, and the controller can directly monitor the retransmission rate of the corresponding link. However, there is almost no message transmission on the Slave link, so the retransmission rate of the corresponding link cannot be monitored in a short time. The algorithm uses the inactivity-probe probe to increase the number of data packets transmitted on the Slave link, and uses these data packets to enable the controller to monitor the Slave link quality.

[0069] The algorithm defines the set C of all controllers and the set S of all switches, and reflects the impact of the algorithm on the control link quality through the ratio of the change in the control link quality before and after the switch migration:

[0070]

[0071] where Δ i,mn represents si From c m Migrate to c n After that, corresponding to the change in the control link quality. Since the control link quality may deteriorate after migration, so Δ i,mn May be negative. Where q in Is the control link quality between switch s i And controller c n Between, q im Is the control link quality between switch s i And controller c m Between.

[0072] The algorithm defines the load balancing rate:

[0073]

[0074] Where n is the number of controllers and L is the controller load. The more balanced the load between controllers, the fewer cases where switches need to be migrated due to overload.

[0075] The algorithm considers the time that the switch can move within the communication range of the corresponding controller before and after migration. Since the transmission path of the control message cannot be known, the algorithm only considers the direct connection between the switch and the controller. The delay and link quality of a single-hop wireless link are usually better than those of a multi-hop link. Therefore, the algorithm should also preferentially select the mapping where the switch and the controller can be directly connected. The switch can report the current position coordinates P(x1, y1, z1) through OpenFlow messages. The algorithm calculates the moving speed v of the switch through the following formula:

[0076]

[0077] Where (x2, y2, z2) are the coordinates of the previous position P' of the switch, and Δt is the unit time interval. The movement trajectory of the switch node is abstracted as a straight line:

[0078]

[0079] Let the ratio in formula (4) be k, and this formula can be expressed as

[0080]

[0081] Suppose the coordinates of the controller position P c Are (a, b, c), the spherical radius of the communication range is R, and the coordinate equation of the communication range boundary is:

[0082] (x - a) 2 +(y - b) 2 +(z - c) 2 =R 2 (6)

[0083] Since the switch is within the communication range of the controller, the simultaneous equations (5) and (6) can definitely yield Q1(x q1 ,y q1 ,z q1 ) and Q2(x q2 ,y q2 ,z q2 ) two intersection points. According to the direction of the switch node movement, it can be determined whether it is moving towards Q1 or Q2. The node coordinates are expressed as (x q ,y q ,z q ), and thus the time the switch can move within the communication range of the corresponding controller is obtained by the following formula:

[0084]

[0085] The longer the switch moves within the controller's communication range, the fewer times the switch needs to be migrated due to node movement. This algorithm defines:

[0086]

[0087]

[0088] It is used to reflect the impact of the switch's movement time within the communication range on the control link. ij Reflects the time that the switch can move within the communication range of the corresponding controller after migration relative to the time before migration. After normalization, β i,mn β i,mn Always greater than 0, that is, multi-hop links will not have a negative impact. i,mn The smaller the value, the shorter the movement time after migration.

[0089] Taking the above considerations into account, this algorithm evaluates the migration strategy of each switch to each controller:

[0090] score=β i,mn (α1Δ i,mn +α2LBR) (10)

[0091] The source controller, destination switch, and destination controller mapping corresponding to the highest score value is selected, where α1 and α2 are coefficients.

[0092]

[0093] Algorithm 1 is the execution process of this algorithm. This process draws on the process of game theory and will be immediately started when the controller is overloaded. The algorithm periodically traverses the controller set C at 6s intervals, and starts this process with each controller as the source controller to find a mapping with a higher score value. In the second step, the source controller opens a game domain, and other controllers can join this game domain. A controller can only join one game domain at the same time. Only the controllers in the same game domain can accept the switches to be migrated, thus avoiding multiple switches being migrated to the same controller at the same time. The different game domains spontaneously formed by the controllers do not interfere with each other. Different game domains can execute the algorithm process for their own domains at the same time, enabling the algorithm to support the simultaneous migration of multiple switches while avoiding controller overload, thereby improving the algorithm performance.

[0094] The algorithm takes into account the quality of the wireless control link in SDMANET and improves the overall link quality of the SDN control plane by changing the mapping between switches and controllers. In addition, this algorithm considers the time that a switch can move within the communication range of the corresponding controller, enabling the switch node to migrate to other controllers in advance when it is about to move out of the current controller's communication range, and avoiding the situation where the switch immediately moves out of the controller's communication range after migrating to a new controller. Moreover, this algorithm also considers the controller load balancing rate to further reduce the number of migrations required due to controller overload.

[0095] The multi - controller load balancing algorithm proposed by the present invention can be used in SDMANET, supports arbitrary movement of nodes, and ensures that all switches in the network can be effectively managed by the controller. In addition, compared with other existing algorithms, when used in SDMANET, this algorithm has a higher overall network control link quality, fewer switch migrations, and higher performance of the SDMANET control plane.

[0096] The above - mentioned are only the preferred embodiments of the present invention and are not intended to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention are all included in the protection scope of the present invention.

Claims

1. A multi - controller load - balancing algorithm for SDMANET, characterized in that, Including the following steps: S1. Create a mapping between the switch and the controller, record and update in real time the set of switch conditions; the switch conditions are divided into four types: leaving the network, joining the network, Master link disconnection, and maintaining the connection. Determine which condition the switch is in according to the control link status and execute the corresponding policy to ensure that the switches in the network are always managed by one and only one controller; The specific method of step S1 includes: S11. Algorithm initialization: Create a mapping M between the switch and each controller and a set G for recording switch conditions; S12. Monitor the connection status of the control link in real time and maintain the mapping M: Monitor whether the Master link and Slave link between the controller and each switch are maintained, and monitor whether a new connection is established; S13. Update the switch status and maintain the set G: If the number of switches in the topology increases, update the corresponding switch to the joining network condition; if the Master link is disconnected and the corresponding switch does not have a Slave link, update the switch to the leaving network condition; if the Master link is disconnected but the corresponding switch has a Slave link, update the switch to the Master link disconnection condition; S14. Execute the corresponding policy: If the switch is in the joining network condition, select the controller that can communicate with it and has the lowest load as its Master controller, and after completion, update the switch condition to maintaining the connection; if the switch is in the Master link disconnection condition, change its Slave controller with the lowest load to the Master controller, and after completion, update the switch condition to maintaining the connection; S2. Dynamically maintain the mapping between the switch and the controller by combining the control link quality, load balancing degree, switch location, and movement speed, calculate the source controller, destination switch, and destination controller required, and evaluate the policy for each switch to migrate to each controller: score = β i,mn (α1Δ i,mn + α2LBR) (10) Select the source controller, destination switch, and destination controller mapping corresponding to the highest score value, where α1 and α2 are coefficients, and Δ i,mn represents switch s i from controller c m migrate to controller c n after the corresponding change in the control link quality, β i,mn is the normalization of the time that the switch can move within the communication range of the corresponding controller after migration relative to before migration; LBR is the load balancing rate between the controllers.

2. The multi - controller load - balancing algorithm for SDMANET according to claim 1, characterized in that In step S12, inactivity-probe probes are sent at fixed time intervals to detect whether the Master link and Slave link are maintained.

3. The multi - controller load - balancing algorithm for SDMANET according to claim 1, wherein, The specific method of step S2 includes: S21. Monitor the link quality between the switch and each controller and calculate the change in the corresponding control link quality before and after the switch migration; S22. Calculate the time that the switch can move within the communication range of the corresponding controller according to the switch location and movement speed; S23. Calculate the load balancing rate LBR; S24. Evaluate the policy for each switch to migrate to each controller, and select the mapping of the source controller, destination switch, and destination controller corresponding to the highest evaluation value.

4. The multi - controller load - balancing algorithm for SDMANET according to claim 3, characterized in that, In step S21, the link quality includes the Master link quality and the Slave link quality. Among them, the link quality is reflected by monitoring the retransmission rate.

5. The multi - controller load - balancing algorithm for SDMANET according to claim 4, characterized in that, The switch sends inactivity-probe probes at fixed time intervals to monitor the packet loss rate of the control link and sends them to the controller through custom OpenFlow messages.

6. The multi - controller load - balancing algorithm for SDMANET according to claim 3, characterized in that, Step S21 calculates the change in the corresponding control link quality before and after the switch migration through the following formula: where q in is the control link quality between switch s i and controller c n ; q im is the control link quality between switch s i and controller c m .

7. The multi - controller load - balancing algorithm for SDMANET according to claim 6, characterized in that, In step S22, the position coordinates of the switch are P(x1, y1, z1), and the calculation formula for the moving speed v of the switch is: where (x2, y2, z2) are the coordinates of the position P' of the switch at the previous moment, and Δt is the unit time interval; The calculation formula for the time that the switch can move within the communication range of the corresponding controller is: (x q , y q , z q ) are the coordinates of the switch node; The normalization of the time that the switch can move within the communication range of the corresponding controller after migration compared to before migration is expressed as: τ ij It reflects the time during which the switch can move within the communication range of the corresponding controller after migration compared to before migration, and β is obtained after normalization i,mn .

8. The multi - controller load - balancing algorithm for SDMANET according to claim 6, characterized in that, In step S23, LBR represents the load balancing rate between the controllers and is expressed as: n is the number of controllers, and L is the controller load.

Images