SDN redundant controller increment deployment method for multi-controller failure

Abstract

The invention discloses an SDN redundant controller increment deployment method for multi-controller failure. The method comprises the following steps: S1, calculating the failure probability of each controller according to the node importance of a switch in a network structure; s2, in combination with the failure probability and the failure scene of the controller, formalizing a redundant controller increment deployment problem of multi-controller failure, and constructing a redundant controller increment deployment model by taking the minimum number of redundant controllers and the worst delay as objective functions; s3, performing optimization solution on the redundant controller increment deployment model based on an NSGA2 algorithm; and S4, designing a controller selection scheme based on a greedy thought to improve the NSGA2 algorithm so as to avoid overload of the controller. According to the invention, the fault tolerance of the network can be effectively improved, the network delay after the network controller breaks down is reduced, and convenience is brought to deployment and maintenance of the network.

Description

Technical Field

[0001] This invention relates to the field of network deployment, and more particularly to an incremental deployment method for SDN redundant controllers in the event of multiple controller failures. Background Technology

[0002] In SDN, the controller is responsible for network path calculation, rule distribution, and other tasks, making it the most critical component of the network. Therefore, the reliability of the controller is extremely important. Initially, SDN used a single-controller architecture. However, a single-controller network structure is inherently unreliable. A single controller is an obvious target for attackers. Moreover, due to the centralized control nature of SDN, if the controller fails due to software or hardware problems, the entire network can be paralyzed.

[0003] Therefore, many researchers have proposed distributed control plane architectures. A distributed control plane refers to dividing the network into different regions, each with its own controller. Amin was the first to propose a multi-controller distributed control plane, HyperFlow.

[0004] While some solutions have been developed to improve the robustness and security of single controllers, they still cannot completely guarantee that controllers will not fail, nor can they cope with sudden controller failures. Currently, the latest approach to controller failure tolerance is controller allocation. In a distributed control plane, controllers are assigned different roles, which are defined in the OpenFlow protocol. The main idea is that master controllers in other areas can act as slave controllers of the current master controller. When the master controller fails due to software or hardware issues, switches within the domain can be mapped to other slave controllers. This structure significantly improves the fault tolerance of SDN. However, slave controller allocation needs to be considered from multiple perspectives. Improper slave controller allocation can easily lead to cascading failures, causing the entire network to collapse. Cascading failures refer to the situation where, when the master controller fails, if the allocated slave controllers are inappropriate, the slave controllers will also fail. Subsequent allocation of slave controllers to these affected controllers will greatly increase the probability of further controller failures, leading to a chain reaction of controller failures.

[0005] First, when a controller fails, the total capacity of the control plane decreases, while the demand in the data plane remains the same. Even if the switches are remapped, there's a significant risk of overloading other controllers, leading to their failure and a chain reaction that results in widespread controller failures. Furthermore, even if the control plane's capacity can accommodate all the data plane switches, switches within the failed controller's domain often need to be migrated to more distant controllers, traversing more links, increasing latency and link load. Simultaneously, because SDN is a scale-free network, a small number of nodes often bear the majority of traffic. From a hardware perspective, these nodes age and suffer significant wear and tear; from a functional perspective, the greater the workload, the more prone they are to errors. Therefore, a few critical nodes have a high failure rate, and these nodes also handle the most traffic. Current solutions lack node importance analysis, treating all nodes equally when measuring latency. However, in reality, node importance varies. For example, nodes in densely populated areas are more important than those in sparsely populated areas, and nodes in city centers are more important than those in parks. Important nodes require priority for latency assurance. In summary, a new approach is needed to address the multi-controller failure problem in the control plane. Summary of the Invention

[0006] The purpose of this invention is to address the above-mentioned problems by providing an incremental deployment method for SDN redundant controllers in the event of multiple controller failures, taking into account deployment costs and maximum network latency.

[0007] To achieve the above objectives, the technical solution of the present invention is as follows:

[0008] An incremental deployment method for SDN redundant controllers in the face of multiple controller failures includes the following steps:

[0009] S1. Calculate the failure probability of each controller based on the node importance of the switch in the network structure.

[0010] S2. Combining the failure probability and failure scenarios of the controller, the problem of incremental deployment of redundant controllers with multiple controller failures is formalized, and a model for incremental deployment of redundant controllers is constructed with the objective function of minimizing the number of redundant controllers and the worst latency.

[0011] S3. Optimize and solve the incremental deployment model of redundant controllers based on the NSGA2 algorithm;

[0012] S4. Design a controller selection scheme based on greedy thinking to improve the NSGA2 algorithm and avoid controller overload.

[0013] Furthermore, step S1 includes the following steps:

[0014] S11. Calculate the node degree of the switch. The calculation formula is as follows:

[0015] ;

[0016] S12. The node importance of the switch is calculated based on the node degree of the switch. The calculation formula is as follows:

[0017] ;

[0018] S13. The importance of the controller is calculated based on the ratio of the switch's node degree to the total node degree. The calculation formula is as follows:

[0019] ;

[0020] S14. Analyze the distribution patterns of node degree and node importance; the calculation formula is as follows:

[0021] ;

[0022] S15. The importance of the controller is expressed as the sum of the importance of the switches managed by the controller; at the same time, the failure probability of the controller is formally expressed as a power-law function. Then, the formula for calculating the failure probability of the controller is:

[0023] ;

[0024] in, Indicates controller Is it a switch? The main controller, Represents a constant.

[0025] Furthermore, step S2 includes the following steps:

[0026] S21, Definition The set of scenarios where the controller fails is as follows: , This represents one of the failure scenarios; This indicates the probability of the failure scenario occurring. Representing controllers Failure probability; definition Failure scenario The maximum latency of the downstream switch is calculated using the following formula:

[0027] ;

[0028] S22. Using minimizing the number of redundant controllers and worst-case latency as the objective function, construct an incremental deployment model for redundant controllers. The calculation formula is as follows:

[0029] ;

[0030] ;

[0031] ;

[0032] ;

[0033] ;

[0034] in, Represents a set of redundant controllers for incremental deployment; Indicates switch Streaming request rate; Indicates controller capacity, This indicates the percentage of reserved capacity for the controller.

[0035] Furthermore, step S3 includes the following steps:

[0036] S31. Simplifying the problem of incremental deployment of redundant controllers in the event of multiple controller failures, we get:

[0037] ;

[0038] in, Indicates the number of redundant controllers. Indicates the maximum delay;

[0039] S32, from The parent population is formed by randomly selecting a portion of redundant controllers for deployment. ;

[0040] S33, Regarding the parent population Non-dominated sorting is performed to divide different populations into different ranks;

[0041] S34. Then, select, crossover, and mutate operations are used to generate the offspring population. ;

[0042] S35, Parental population and offspring population Merge and perform non-dominated sorting, selecting individuals as new parent populations based on their crowding density;

[0043] S36. Repeat steps S33 to S35 until the optimal solution is obtained.

[0044] Furthermore, step S4 includes the following steps:

[0045] S41. Generate a delay matrix for each controller failure scenario under each redundant controller deployment scheme, using the following formula:

[0046] ;

[0047] ;

[0048] ;

[0049] in, This indicates a redundant controller deployment scheme. Indicates controller failure scenario , This represents the set of switches within the fault controller domain; Represents the set of normal controllers; Indicates switch To the controller The minimum weighted delay;

[0050] S42, Setting up a redundant controller deployment scheme and controller failure scenarios The weighted delay matrix of the lower switch is The controller selection scheme is as follows ; and All are one-dimensional matrices. ; This indicates the selected controller number for each switch;

[0051] S43, Regarding For each row in the algorithm, starting with the first delay element, determine if the controller capacity meets the requirements. If not, continue checking the next delay element in the row. If the requirements are met, select that controller as the migration target and update its load and... ;

[0052] S44, For Sort in ascending order, with the last row representing the redundant controller deployment scheme. In controller failure scenarios The maximum delay.

[0053] Furthermore, step S41 includes the following steps:

[0054] S411, For For each switch in the array, calculate its weighted delay to all normal controllers. All delays of each switch are denoted as a one-dimensional matrix, and the one-dimensional matrix is ​​sorted in ascending order.

[0055] S412. Combine the one-dimensional matrices of all switches vertically into a two-dimensional matrix. The number of rows in a two-dimensional matrix is ​​equal to The number of switches in the middle, the number of columns in the two-dimensional matrix equals The number of controllers in the middle;

[0056] S413. For each row of the two-dimensional matrix, sort them in ascending order according to the size of the first weighted delay.

[0057] Compared with the prior art, the advantages and positive effects of this invention are:

[0058] This invention proposes an incremental deployment scheme for redundant SDN controllers in the face of multiple controller failures. It first introduces power-law properties and network node importance to calculate the probability of controller failure and the maximum network latency, respectively. Then, it formally defines the deployment location and number of redundant controllers and network latency, modeling it as a multi-objective optimization problem and proposing a heuristic solution. Finally, a greedy approach is incorporated into the controller selection algorithm to avoid controller overload. This invention can effectively improve network fault tolerance, reduce network latency after network controller failure, and facilitate network deployment and maintenance. Attached Figure Description

[0059] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0060] Figure 1 A diagram showing the network structure for normal operation;

[0061] Figure 2 Network diagram for when controller C1 fails;

[0062] Figure 3 Network diagram showing the faults in controllers C1 and C3;

[0063] Figure 4 A diagram illustrating the importance of nodes in different networks;

[0064] Figure 5 A schematic diagram illustrating the variance of node importance in different networks;

[0065] Figure 6 This is a schematic diagram illustrating the variance of node importance in Cernet.

[0066] Figure 7Flowchart for incremental deployment algorithm;

[0067] Figure 8 A graph showing the correspondence between objective functions of different numbers of fault controllers in Cernet;

[0068] Figure 9 A graph showing the average maximum delay ratio for different numbers of faulty controllers in Cernet;

[0069] Figure 10 A CDF diagram illustrating the maximum latency of Cernet;

[0070] Figure 11 for A diagram illustrating the number of times a redundant controller repeats;

[0071] Figure 12 for A schematic diagram showing the runtime of HIPRC and ORP;

[0072] Figure 13 for A schematic diagram showing the runtime of HIPRC and ORP;

[0073] Figure 14 This diagram illustrates the number of controller overloads in different CERNET schemes.

[0074] Figure 15 This is a diagram illustrating the controller overload rate for different schemes in CERNET.

[0075] Figure 16 A schematic diagram showing the correspondence between the objective functions of different numbers of fault controllers in a BTN;

[0076] Figure 17 A schematic diagram showing the average maximum delay ratio for different numbers of faulty controllers in a BTN;

[0077] Figure 18 This is a schematic diagram illustrating the runtime of HIPRC and ORP;

[0078] Figure 19 This diagram illustrates the number of controller overloads in different BTN configurations.

[0079] Figure 20 This is a schematic diagram showing the controller overload rate of different schemes in BTN. Detailed Implementation

[0080] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, any modifications, equivalent substitutions, improvements, etc., made by those skilled in the art to all other embodiments obtained without creative effort should be included within the protection scope of the present invention.

[0081] This invention proposes an incremental deployment method for SDN redundant controllers in the event of multiple controller failures. This method reduces the possibility of data plane congestion and control plane cascading failures caused by fault recovery schemes, while also enhancing network fault tolerance. The main objective of this invention is to reduce the maximum network latency while minimizing the number of redundant controllers deployed. The main idea is to deploy redundant controllers at appropriate locations on the existing network. When a failure occurs, the switches within the fault domain select one of all normal controllers, including the redundant controller, as the primary controller (which can be called the backup controller relative to the original failed controller).

[0082] This invention formally defines the incremental placement of redundant controllers for multiple controller failures (IPRC-MCF) and designs a heuristic incremental placement of redundant controllers scheme (HIPRC). The IPRC-MCF problem has two objective functions. The first objective is to minimize the number of redundant controllers deployed incrementally. Naturally, a higher number of redundant controllers results in lower maximum network latency, but this increases network costs. The second objective is to minimize the maximum network latency. This invention demonstrates that nodes in the network have different importance and differentiates the probability of different controller failures accordingly. This is fully considered when calculating the location of redundant controllers. When measuring the maximum network latency, all scenarios of controller failure are considered as much as possible, calculating the probability of different scenarios rather than simply adding the maximum latency of all scenarios. Simultaneously, nodes are differentiated based on their importance to reduce the latency of important nodes. During calculation, considering only latency without considering load may cause controller overload, potentially leading to controller failure and new controller failure problems such as cascading failures. Therefore, this invention proposes a controller selection scheme based on a greedy approach. When the heuristic algorithm optimizes the deployment location of redundant controllers based on maximum latency, the controller load factor is incorporated, effectively avoiding controller overload.

[0083] The main work of this invention is as follows:

[0084] (1) Through case analysis, it is shown that controller failure will increase network latency and lead to cascading failures, and corresponding solutions are proposed;

[0085] (2) It was analyzed and shown that the distribution of node importance in the existing network conforms to the power law property, and the key factor of node importance was introduced when calculating the controller failure rate and node delay;

[0086] (3) The IPRC-MCF problem is formally defined, and a heuristic scheme based on the NSGA2 algorithm is proposed to solve the problem. A greedy idea is introduced when selecting the controller to avoid controller overload.

[0087] (4) Simulations were performed in different real networks. In Cernet, the latency and controller overload rate were approximately 50% of those in other schemes.

[0088] Problem Analysis

[0089] This invention analyzes the shortcomings of control plane cascade failures and existing solutions, and then presents the solution proposed in this invention. First, a simple example is given to illustrate the design motivation of this invention. For example... Figure 1-2 As shown.

[0090] Figure 1 This is a simplified network diagram. Circles represent switches S1-S15. Switches of the same color indicate they belong to the same controller. Concentric circles indicate that the controller is deployed on that node; C1-C4 represent the controllers. Additionally, the flow request rate of the switches and the load of the controllers are labeled. It is assumed that the capacity of each controller is 1000kb / s.

[0091] Figure 2 The network state when controller C1 fails is given. Assume S1 and S4 migrate to C4, S2 migrates to C2, and S3 migrates to C3. Figure 2 As can be seen, due to controller capacity limitations, S1 and S4 cannot be migrated to the nearby C3 and need to be migrated to C4 over a considerable distance. On one hand, this increases the distance between the switch and the controller, increasing network latency; on the other hand, long-distance communication between the switch and the controller requires more links, increasing the overall load on the data plane. The same applies to S3.

[0092] Regardless of the migration method, this network will overload the controller. Overload can easily cause the controller to fail, leading to cascading network failures and more serious problems.

[0093] Naturally, deploying redundant controllers in appropriate locations within the network can significantly reduce the adverse effects of controller failure. For example, assuming a redundant controller C5 is deployed on S9, when C1 fails, S1, S3, and S4 can be migrated to C5, and S2 can be migrated to C2, as follows. Figure 3 As shown. This approach does not significantly increase network latency and also reduces the likelihood of controller overload. Furthermore, deploying redundant controllers can handle a larger number of failed controllers. Assuming C3 also fails at this point, S10 and S11 can be migrated to C5, and S8 and S9 can be migrated to C4. Figure 3 It can handle two faulty controllers, and Figure 2 It can only handle one faulty controller.

[0094] Figure 2 The maximum latency is significantly higher than Figure 3 ,at the same time, Figure 3 This approach can handle more faulty controllers. Incremental deployment of redundant controllers can effectively increase the network's resilience and improve its fault tolerance level.

[0095] Meanwhile, the redundant controller placement scheme is compatible with other controller fault tolerance schemes, such as single master controller reliability improvement schemes, master-slave controller fast switching schemes, and master controller location deployment, etc.

[0096] To better reflect reality, this invention differentiates the probability of failure for different controllers when considering redundant controller deployment, incorporating the crucial factor of node importance. From a network function perspective, controllers located in critical network positions bear more network traffic and computational tasks, increasing their probability of failure. From a network structure perspective, controllers in critical network positions experience faster hardware wear and tear and aging, similarly increasing their failure probability. Furthermore, these controllers are also prime targets for attackers.

[0097] I. Network Modeling

[0098] 1.1 Network Model

[0099] This invention formally defines the variables and parameters required for this invention. First, the network is defined as an undirected graph. , Represents nodes in the network. . This refers to a link in the network. The node mentioned in this invention can house either a switch or a controller. Represents a set of switches. . Represents a set of controllers. , . It is a 0-1 variable, and its specific meaning is shown in equation (1). This represents the set of redundant controllers that will be deployed incrementally. The meaning is similar. It is also a 0-1 variable, as shown in equation (2). Indicates controller It is a switch The main controller, otherwise As shown in equation (3). Wherein, .akin, This indicates the mapping status of the switches managed by the failed controller after the controller fails. Indicates controller It is a switch A new main controller, otherwise As shown in equation (4). Indicates controller Has a malfunction occurred? As shown in equation (5). Additionally, Indicates controller A collection of switches within the domain. . Represents the set of fault controllers. . This indicates the flow request rate of the switch.

[0100]

[0101] 1.2 Controller Failure Probability

[0102] This invention analyzes the controller failure probability from the perspective of node importance (node ​​degree). First, it defines node degree and proves that node degree in an SDN network follows a power-law distribution. Then, it presents the calculation method for the controller failure probability.

[0103] 1.2.1 Network Structure and Node Importance

[0104] First, the node degree of the switch is given. The calculation method is shown in equation (6).

[0105] (6)

[0106] The switch node degree refers to the number of links that the node owns in the network. Furthermore, according to equation (6), the importance of a switch node can be obtained. The definition of is shown in equation (7):

[0107] (7)

[0108] The meaning of node importance is: switch The ratio of the node degree to the total node degree. Similarly, the importance of the controller is given. The definition is shown in equation (8):

[0109] (8)

[0110] The significance of controller importance is: controller The sum of the node importance of the switches within the domain.

[0111] Faloutsos proposed that the internet is not randomly generated, but rather follows a power-law distribution. Similarly, Lada's research indicates that a power-law property also exists between web pages and websites on the internet, meaning that fewer websites contain more web pages. Albert points out that the internet is a non-uniform network, conforming to a power-law distribution.

[0112] Meanwhile, SDN is a scale-free network that conforms to the Zipf distribution and power-law distribution. That is, a few nodes have high node importance, while most nodes have low node importance. This invention selects several real-world networks from TopologyZoo and analyzes the node importance of these networks, such as... Figure 4 As shown in the figure. The Cernet network was also analyzed.

[0113] The distribution of node importance in these networks indicates that different nodes have varying degrees of importance within the network. The greater the node's importance, the greater its role in the network, and the more traffic it handles. Therefore, the distribution of network traffic varies across different nodes. Consequently, different controllers manage different amounts of traffic, providing a new perspective for studying controller failures.

[0114] 1.2.2 Controller Failure Probability with Power-Law Characteristics

[0115] As mentioned in the previous section, the importance of nodes in a switch varies considerably, and their distribution generally follows a power-law characteristic. For controllers, the difference in node importance is even greater. This invention calculates the variance of node importance and the variance of controller importance in different networks, such as... Figure 5 As shown, the variance of controller importance for each network differs significantly from the variance of switch importance. Furthermore, the variance of controller importance for Cernet was calculated 100 times, with the controller deployment locations varying each time. Figure 6 As shown in the figure, the variance of controller importance is generally greater than that of node importance. These analyses indicate that the gap between controller importance is larger than the gap between node importance, and the distribution of controller importance is closer to a high-dimensional power-law distribution.

[0116] Most existing controller failure solutions fail to consider the traffic differences between controllers. In reality, different controllers have varying levels of workload. From a node perspective, the traffic differences between nodes are significant. Since node traffic needs to be managed through the controller, different controllers have different loads. From a network function perspective, the greater the load, the more computational tasks the controller needs to complete, leading to more errors and unresponsiveness in the software running on the controller entity. From a network structure perspective, a greater load also increases the aging and wear of controller hardware and wiring. Similarly, this increases the probability and frequency of controller failure. Furthermore, controllers with high node importance are also primary targets for attackers. All of these factors increase the probability of controller failure. Therefore, it can be considered that there is a direct positive correlation between the probability of node failure and the importance of the node. Thus, it is essential to differentiate the probability of failure for different controllers.

[0117] The above analysis shows that, whether considering network functionality and structure or the software and hardware aspects of the controller, node importance is a crucial factor to consider in controller failure. Therefore, this invention incorporates node importance as a key factor when addressing controller failure.

[0118] The distribution of node degree and node importance follows a power law distribution, meaning that a small number of nodes have high node degree and node importance, as shown in equation (9).

[0119] (9)

[0120] Based on equation (9) and the above analysis, the definition and calculation method of the controller failure probability of the present invention are given.

[0121] Regarding the controller failure probability, in an SDN network, the importance of each node can be obtained. For a multi-controller SDN network, the network is usually divided into different regions, each managed by a designated controller. This invention represents the controller importance as the sum of the importance of the switches managed by the controller. Simultaneously, the controller failure probability is formally represented as a power-law function, as shown in equation (10). Indicates controller Is it a switch? The main controller, Represents a constant. (The rest is incomplete and likely refers to a specific value.) Set to 3.

[0122] (10)

[0123] Analysis shows that adding redundant controllers can improve the network's tolerance to controller failures.

[0124] The analysis process is as follows: For the set of controllers in the network In other words, its total capacity can be denoted as The sum of the flow request rates of the switches can be denoted as: . Indicates controller The capacity. Generally speaking, the sum of the controller capacities is greater than the sum of the flow request rates of the switches, that is... Assuming When the controller When a malfunction occurs, At least one controller will be overloaded, potentially leading to a cascading failure. The network cannot cope. A failure has occurred. If there is at least one redundant controller in the network at this time, then it can ensure... The network can cope Failures can occur. Therefore, deploying redundant controllers can improve the network's tolerance to controller failures.

[0125] Analysis shows that adding redundant controllers can reduce the maximum network latency.

[0126] The analysis process is as follows: For the controller set When the location of the redundant controller is fixed, at least one controller will exist. ,when In the event of a failure, the nearest controller contains a redundant controller. This redundant controller can then act as the primary controller after the failure. If no redundant controller is available, and the nearest controller's capacity is insufficient to manage the switch to be migrated, the switch will need to be migrated to a more distant controller, increasing the maximum latency.

[0127] 1.3 Incremental Deployment of Redundant Controllers for Multiple Controller Failures (IPRC-MCF)

[0128] This invention formally defines the incremental deployment problem of redundant controllers in the face of multiple controller failures. It includes the objective function, constraints, and a corresponding heuristic algorithm.

[0129] 1.3.1 Formal Definition

[0130] This paper analyzes the incremental deployment problem of redundant controllers in the face of multiple controller failures, using the IPRC-MCF framework. For a multi-controller SDN network, the paper plans how to deploy redundant controllers to improve network fault tolerance in the event of multiple controller failures. Two objective functions need to be considered: first, to minimize the number of redundant controllers to reduce costs; second, to minimize the maximum latency from the switch to the backup controller when the primary controller fails.

[0131] This invention assigns a failure probability to each controller and considers all controller failure scenarios. This invention uses... express A collection of scenarios where the controller fails. . This indicates combination operations. Use... This represents one of the scenarios, namely All controllers failed simultaneously. , . express The probability of the scenario occurring, where . Representing controllers The failure probability can be calculated by equation (10).

[0132] Additionally, definition For the scene The maximum delay of the switch is calculated as shown in Equation (11).

[0133] (11)

[0134] Based on the above description, for the IPRC-MCF problem, the objective of this invention is to find a redundant controller deployment scheme to minimize a given objective function under certain constraints. This invention formalizes the objective function and constraints as Equation (12). Equation (12) represents minimizing the number of redundant controllers and the worst-case delay.

[0135] (12)

[0136]

[0137] (13)

[0138] (14)

[0139] (15)

[0140] (16)

[0141] in, This represents the set of redundant controllers for incremental deployment. In equation (13), Indicates in the scene The worst-case latency from the switch in the faulty controller domain to the new master controller. Equation (14) indicates that after a fault occurs, the sum of the flow request rates of the switches must not exceed the capacity of the controller. Indicates switch The streaming request rate. Indicates controller capacity, This represents the proportion of reserved capacity for the controller. This capacity is reserved to cope with network fluctuations. Equation (15) indicates that the switch can only have one master controller. Equation (16) indicates that the number of controller failures is no less than two.

[0142] 1.3.2 Optimal Solution to the IPRC-MCF Problem

[0143] To compare with the solution proposed in this invention, this invention analyzes the optimal solution to the IPRC-MCF problem and proposes an algorithm for the optimal solution. The main idea is to traverse all controller failure scenarios for each redundant controller deployment location, and find the minimum number of redundant controllers and the maximum minimum latency deployment scheme. The algorithm flow is shown in Table 1.

[0144] Table 1 Optimal Deployment Algorithm for IPRC-MCF Problem

[0145]

[0146] Algorithm 1 takes the network topology, the number of controller failures, the probability of a controller failure scenario, and the maximum latency for that scenario as input. The output is the optimal deployment scheme, including the number and location of redundant controllers. The number of controllers is... The maximum number of redundant controllers that can be deployed is set to [number]. The main idea of ​​Algorithm 1 is traversal. For a fixed number of redundant controllers, we have... Deployment options (line 1). This represents the number of nodes in the network. This needs to be calculated for each deployment scheme. Assume the number of controller failures is... ,therefore There are a total of [number] controllers. There are several failure scenarios (line 3). For each failure scenario, the probability of that scenario occurring and the maximum delay under that scenario can be obtained (lines 4-6). This represents the sum of the maximum latency for all redundant controller deployment scenarios (line 7). The initial value is 0. express The set (line 9). Finally, from Find the smallest Corresponding redundant controller deployment scheme And the number of redundant controllers (line 11).

[0147] Because it contains two nested loops, Algorithm 1 requires a significant amount of time to complete the computation. Its computational complexity is O(n log n). This invention uses this algorithm as a performance reference to compare with the proposed solution. In reality, this solution is not applicable. For example, for Internet2, assume this topology requires 7 controllers. The network has 34 nodes and 42 links. For Algorithm 1, the maximum number of redundant controllers is 3. If 2 controllers fail, then the number of solutions to be calculated is... .

[0148] Analysis shows that the IPRC-MCF problem proposed in this invention can be reduced to a special knapsack problem. For redundant controller sets... First, the number of redundant controllers is limited. At this point, the IPRC-MCF problem can be simplified as follows: For a set (the set of network nodes) Find the existence of a subset , making Minimum, and .in, The maximum network latency, calculated based on the redundant controller deployment, can be obtained from equation (11). Therefore, the IPRC-MCF problem is Np-hard.

[0149] II. HIPRC Solution Design

[0150] For the IPRC-MCF problem, this invention designs a solution based on existing heuristic algorithms. As analyzed above, IPRC-MCF is a bi-objective optimization problem. It includes both the number of redundant controllers deployed and the maximum latency after a failure. However, these two objectives are conflicting. To reduce the maximum latency, the number of redundant controllers must be increased. Conversely, to reduce the number of redundant controllers, the maximum latency must increase. Therefore, the optimization results differ depending on the specific requirements. There is no single, absolutely correct solution to the IPRC-MCF problem. Therefore, this invention calculates the Pareto solution to this problem.

[0151] First, the Pareto solution and dominance relationship based on the IPRC-MCF problem are given. The IPRC-MCF problem is first simplified to equation (17). Indicates the number of redundant controllers. Indicates the maximum delay:

[0152] (17)

[0153] (13-16)

[0154] Analyze the Pareto solution of the IPRC-MCF problem. This represents a set of redundant controller deployment schemes. For It does not exist. At the same time satisfy , .So This is a Pareto solution to the IPRC-MCF problem.

[0155] Analyze the dominance relationships in the solutions to the IPRC-MCF problem. For two schemes involving redundant controller deployment, and ,if For the Pareto solution of the IPRC-MCF problem, and If it is not a Pareto solution to the IPRC-MCF problem, then Dominate , It is non-dominant, denoted as .

[0156] Analysis revealed that the IPRC-MCF problem has a Pareto optimal solution.

[0157] The analysis process is as follows: As can be seen from the above, the maximum latency of the network is... For specific fault scenarios It is a constant, therefore, . Representing a scene Below, the maximum latency among all switch latencies. For simplicity, it is noted in the scenario. Below, the latency set corresponding to all switches is: .then, Regarding the delay The more controllers in the network, the shorter the distance between the switch and the controller. The smaller the value, the better. The smaller the number of redundant controllers, the more redundant controllers there are, and the more controllers that can function normally in the network. And because ,then For the solution set Assume the corresponding objective functions are respectively , For all for Solution , recorded as At the same time, record , .for ,if ,So ,because Similarly, for ,if ,So .therefore, It is a Pareto solution, meaning that the IPRC-MCF problem has at least one Pareto solution.

[0158] 2.1 Heuristic Incremental Deployment of Redundant Controllers

[0159] Based on the above analysis, this invention provides a heuristic incremental placement of redundant controllers scheme (HIPRC) for the IPRC-MCF problem based on the NSGA2 algorithm.

[0160] NSGA2 is a multi-objective optimization algorithm that primarily solves multi-objective problems through mutation, crossover, and diversity. The incremental deployment algorithm of this invention is shown in Table 2.

[0161] Table 2. Heuristic Algorithm for Incremental Deployment of Redundant Controllers

[0162]

[0163] The algorithm is briefly described below. First, let's start with... A subset of the selected schemes were used to form the parent population. (Lines 1-2). Then, for the parent population... Perform a non-dominated sort to divide the different populations into different tiers (row 3). Then, use selection, crossover, and mutation operations commonly used in genetic algorithms to generate the offspring population. (Line 4). The following is the loop part of the algorithm. The parent population... and offspring population Merge, and on Perform a quick non-dominated sort (lines 6-7). Since at this point... Since there are many individuals in the middle generation, it is necessary to calculate the crowding density to determine the quality of individuals within the same level, and select suitable individuals to form the new parent population (lines 8-9). Subsequently, selection, crossover, and mutation operations commonly used in genetic algorithms are employed to generate the offspring population. (Line 10), until the loop ends. The flowchart of the algorithm is as follows: Figure 7 As shown.

[0164] 2.2 HIPRC computational complexity

[0165] NSGA-2 has a significantly reduced complexity compared to NSGA. Specifically, the complexity of non-dominated sorting is O(n log n). The complexity of crowding calculation is The complexity of determining dominance is Therefore, the algorithm's complexity is O(n log n). .

[0166] 2.3 Controller Selection Scheme Based on Greedy Algorithm

[0167] In the above scheme, the NSGA2 algorithm was used to heuristically explore the deployment location and number of redundant controllers. The basic idea for calculating the path from the switch to the controller is based on Dijkstra's shortest weighted path. However, if the capacity of the controller closest to the switch to be assigned is insufficient to handle the switch, it will lead to controller overload, and in severe cases, controller failure, increasing the number of controller failures. Therefore, relying solely on the shortest path calculation method without considering controller capacity will reduce the reliability of the control plane.

[0168] This invention improves NSGA2 by selecting the shortest weighted path while avoiding controller overload.

[0169] 2.3.1 Switch Delay Matrix

[0170] First, a delay matrix is ​​generated for each controller failure scenario under each redundant controller deployment scheme, denoted as... .in This indicates a redundant controller deployment scheme. Indicates controller failure scenario . The specific meanings are shown in equations (18)-(20).

[0171] (18)

[0172] (19)

[0173] (20)

[0174] This represents the set of switches within the fault controller domain. Represents the set of normal controllers. It includes both fault-free controllers and redundant controllers for incremental deployment. Indicates switch To the controller The minimum weighted delay. Algorithm 3 provides... The calculation method is shown in Table 3.

[0175] Table 3 Weighted Delay Matrix Algorithm

[0176]

[0177] for For each switch in the array, calculate its weighted delay to all normal controllers. Represent all delays of each switch as a one-dimensional matrix, and sort these matrices in ascending order (rows 2-10). Combine the one-dimensional matrices of all switches vertically into a two-dimensional matrix. (Line 9). The number of rows in the matrix equals... The number of switches in the matrix equals the number of columns in the matrix. The number of controllers. Then for... Each row is sorted in ascending order according to the size of the first delay (row 11).

[0178] 2.3.2 Controller Selection Scheme

[0179] After obtaining the weighted delay matrix of the switch, a controller is selected for the switch based on the controller capacity. The main idea is to prioritize the controller with the smallest weighted delay for each switch. The specific algorithm is shown in Table 4.

[0180] Table 4. Controller selection scheme based on greedy algorithm

[0181]

[0182] The algorithm is briefly described below. This is noted in the redundant controller deployment scheme. and controller failure scenarios The weighted delay matrix of the lower switch is The controller selection scheme is as follows , and All are one-dimensional matrices (row 1). . This indicates the selected controller number for each switch. .for For each row in the algorithm, starting with the first delay element, determine whether the controller capacity meets the requirements. Indicates controller The existing load (lines 2-4). If not, continue to check the next delay element in that line, i.e., whether the capacity of the next controller meets the requirements. If the controller capacity meets the requirements, then select that controller as the migration target and update the controller's load and... (Lines 7-8). Finally, for Sort in ascending order, with the last row representing the redundant controller deployment scheme. In controller failure scenarios The maximum delay is shown in line 13.

[0183] It is important to note the controller selection scheme here. This refers to a redundant controller deployment scheme. In controller failure scenarios The temporary scheme presented here is only for calculating the maximum latency under this scheme in this scenario. This scheme is part of the NSGA2 algorithm optimization process, and each optimization iteration generates several controller selection schemes. Therefore, the scheme presented here does not represent the final controller backup selection scheme calculated by this invention for the switch.

[0184] III. Simulation and Analysis

[0185] 3.1 Simulation Settings

[0186] This invention presents the performance of HIPRC in different real-world networks and compares it with other methods. The simulation used a terminal environment with an i7 3770k CPU and 16GB of RAM. The relevant code was written in Python. To ensure the reliability of the results, the simulations of different schemes were repeated multiple times, and the average value was calculated.

[0187] Comparison of options:

[0188] RRP: Random and Redundant Placement. Randomly selects redundant controller locations within the network.

[0189] WP: Without Redundant controller deployment.

[0190] ORP: Optimal Redundant Placement, which is the optimal redundant controller deployment scheme obtained by traversal in Section 3.3.

[0191] HIPRC: The heuristic incremental deployment scheme for redundant controllers proposed in this invention.

[0192] Parameter settings:

[0193] Unless otherwise specified, the maximum flow request rate of the switch is set to 1000 kiloreq / s, and the maximum capacity of the controller is 5000 kiloreq / s. The ratio of switch to main controller is 1:5 to 1:20.

[0194] Topology settings:

[0195] To ensure the effectiveness and universality of the scheme comparison, this invention starts from... We selected a real network, BTN, for simulation comparison. This is a topology dataset that includes hundreds of real network topologies. Additionally, the topologies used also include Cernet, the China Education and Research Network. Table 5 shows the network parameters.

[0196] Table 5 Network Parameters

[0197]

[0198] 3.2 Simulation Results

[0199] First, the Pareto chart of HIPRC in Cernet is given, such as... Figure 8 As shown. The optimization objectives of HIPRC include latency and the number of redundant controllers. Among them, Figure 8 (a) shows the correspondence of the objective function when the number of fault controllers is 2. Figure 8 (b) shows the correspondence of the objective function when the number of fault controllers is 3. This indicates the number of faulty controllers. As shown in the diagram, HIPRC can simultaneously provide the optimized delay for different numbers of redundant controllers, while the optimization method ORP can only select a fixed number of redundant controllers. When the number of redundant controllers increases linearly, the number of solutions that the ORP method needs to calculate increases by an order of magnitude, which will significantly increase the computation time.

[0200] Figure 9 The maximum delay of different schemes is compared when the number of fault controllers is different. At that time, run all the schemes 100 times and calculate the average value. Due to the excessive simulation time, it was only run 10 times. Since ORP is the optimal solution, this invention uses the ORP result as the basis for calculating the proportions of other solutions. Let the result of ORP be denoted as... The delay ratio is calculated as shown in equation (21).

[0201] , (twenty one)

[0202] As can be seen from the figure, ORP has the lowest maximum latency. The HIPRC scheme proposed in this invention is only slightly slower than the optimal scheme. This indicates that the scheme of this invention can effectively reduce the maximum network latency when multiple controllers fail. Although the RRP scheme also deploys redundant controllers, its maximum latency is also relatively high due to the lack of location optimization. The WP scheme does not deploy redundant controllers, therefore its maximum latency is the highest. This also shows that deploying redundant controllers can effectively reduce the maximum network latency when controllers fail.

[0203] To more clearly illustrate the maximum latency differences between different schemes, this invention also provides information on the Cernet network. The maximum delay distribution at time, such as Figure 10As shown. Similarly, this simulation was repeated 100 times. It should be noted that the maximum delay here does not have a specific unit because, during the calculation, the maximum delay is multiplied by the node importance of the switch and the probability of different failure scenarios, and the coefficients also include a fixed constant. Section 3 gives the specific calculation method. Obviously, the solution of the present invention is very close to the optimal solution. In each simulation, the solution of the present invention has a significant advantage over RRP and WP.

[0204] For Cernet, when 100 simulations were performed, and the deployment locations of redundant controllers obtained from the proposed HIPRC scheme were statistically analyzed and compared with those obtained from the optimal ORP scheme. The number of overlaps is as follows: Figure 11 As shown in the figure, in 100 simulations, the location did not overlap with the optimal solution in only more than 20 instances. In most cases, the deployment location calculated by the HIPRC scheme overlapped with the optimal solution at least once. This indicates that the HIPRC scheme can effectively calculate a better deployment location for redundant controllers.

[0205] Figure 12 and Figure 13 They were given respectively and This represents the average runtime of different methods. The runtime of the optimization method is affected by two factors. First, the number of faulty controllers, and second, the maximum number of redundant controllers deployed in the network. For the number of redundant controllers, each additional controller increases the number of solutions the optimization method needs to calculate by an order of magnitude, resulting in a significant increase in computation time.

[0206] To measure the impact of different solutions on load, this invention reduces the number of redundant controllers and increases the number of faulty controllers, comparing controller load under different flow request rates. There are two main metrics: the number of overloaded controllers and the controller overload rate. The calculation method is the sum of the number of overloaded controllers and the overload rate for each fault scenario. Figure 14 and Figure 15 Experimental results for the number of overloads and the overload rate in Cernet are presented respectively. Figure 14 In the process, due to the increase in the flow request rate without an increase in the total number of controllers, the number of controllers overloaded in RRP and WP gradually approaches that of ORP and the proposed solution HIPRC. However, from the perspective of overload rate, ORP and HIPRC still have advantages.

[0207] To verify the universality of the algorithm, similar simulation experiments were also conducted in the BTN network. Figure 16Pareto charts for HIPRC in BTN are presented. The optimization objectives of HIPRC include delay and the number of redundant controllers. Figure 16 (a) shows the correspondence of the objective function when the number of fault controllers is 2. Figure 16 (b) shows the corresponding relationship of the objective function when the number of fault controllers is 3. Similarly, Indicates the number of faulty controllers.

[0208] Figure 17 The maximum latency of different schemes is compared when there are different numbers of failed controllers. Similarly, since ORP is the optimal scheme, the results of ORP are used as the basis to calculate the proportion of other schemes, as shown in Equation (21). As can be seen from the figure, the maximum latency of ORP is the smallest. The HIPRC scheme is only slightly different from the optimal scheme ORP, which shows that the scheme of the present invention can effectively reduce the maximum latency of the network when multiple controllers fail. Although the RRP scheme also deploys redundant controllers, its maximum latency is also high because it does not optimize the location. The WP scheme does not deploy redundant controllers, so its maximum latency is the largest. This also shows that deploying redundant controllers can effectively reduce the maximum latency of the network when controllers fail.

[0209] Figure 18 The runtime comparison between HIPRC and ORP is presented for different numbers of faulty controllers. The graph shows that the ORP solution has a significantly longer runtime. Regarding... and The number of redundant controllers deployed is the same. If the number of redundant controllers increases, the increase in runtime of the ORP solution will be more significant.

[0210] Figure 19 and Figure 20 Experimental results for the number of overloaded controllers and overload rate in BTN are presented. Similar to CERNET, deploying redundant controllers can effectively reduce the controller load and lower the controller overload rate. As the flow request rate increases, the number of overloaded controllers using different methods gradually becomes similar. However, from the perspective of overload rate, ORP and HIPRC still have significant advantages.

[0211] IV. Conclusion

[0212] To improve control plane fault tolerance, this invention proposes a redundant controller deployment scheme, HIPRC, for multi-controller failures. The main optimization objectives include the number and location of redundant controllers and the maximum latency after a network failure. First, power-law properties and network node importance are introduced to calculate the probability of controller failure and the maximum network latency, respectively. Then, the deployment location and number of redundant controllers and network latency are formally defined and modeled as a multi-objective optimization problem, and a heuristic algorithm is proposed. A greedy approach is incorporated into the controller selection process to avoid controller overload. Finally, simulations were performed on different networks, and the results show that the proposed method can improve network fault tolerance, reduce network latency after a failure, and achieve a maximum controller overload rate of only 50% of other schemes.

Claims

1. A method for incremental deployment of SDN redundant controllers in the event of multiple controller failures, characterized in that: Includes the following steps: S1. Calculate the failure probability of each controller based on the node importance of the switch in the network structure. S2. Combining the failure probability and failure scenarios of the controller, the problem of incremental deployment of redundant controllers with multiple controller failures is formalized, and a model for incremental deployment of redundant controllers is constructed with the objective function of minimizing the number of redundant controllers and the worst latency. S3. Optimize and solve the incremental deployment model of redundant controllers based on the NSGA2 algorithm; S4. Design a controller selection scheme based on greedy thinking to improve the NSGA2 algorithm and avoid controller overload.

2. The incremental deployment method for SDN redundant controllers in response to multiple controller failures as described in claim 1, characterized in that: Step S1 includes the following steps: S11. Calculate the node degree of the switch. The calculation formula is as follows: ； S12. The node importance of the switch is calculated based on the node degree of the switch. The calculation formula is as follows: ； S13. The importance of the controller is calculated based on the ratio of the switch's node degree to the total node degree. The calculation formula is as follows: ； S14. Analyze the distribution patterns of node degree and node importance; the calculation formula is as follows: ； S15. The importance of the controller is expressed as the sum of the importance of the switches managed by the controller; at the same time, the failure probability of the controller is formally expressed as a power-law function. Then, the formula for calculating the failure probability of the controller is: ； in, Indicates controller Is it a switch? The main controller, Represents a constant.

3. The incremental deployment method for SDN redundant controllers in response to multiple controller failures as described in claim 2, characterized in that: Step S2 includes the following steps: S21, Definition The set of scenarios where the controller fails is as follows: , This represents one of the failure scenarios; This indicates the probability of the failure scenario occurring. Representing controllers Failure probability; definition Failure scenario The maximum latency of the downstream switch is calculated using the following formula: ； S22. Using minimizing the number of redundant controllers and worst-case latency as the objective function, construct an incremental deployment model for redundant controllers. The calculation formula is as follows: ； ； ； ； ； in, Represents a set of redundant controllers for incremental deployment; Indicates switch Streaming request rate; Indicates controller capacity, This indicates the percentage of reserved capacity for the controller.

4. The incremental deployment method for SDN redundant controllers in response to multiple controller failures as described in claim 3, characterized in that: Step S3 includes the following steps: S31. Simplifying the problem of incremental deployment of redundant controllers in the event of multiple controller failures, we get: ； in, Indicates the number of redundant controllers. Indicates the maximum delay; S32, from The parent population is formed by randomly selecting a portion of redundant controllers for deployment. ; S33, Regarding the parent population Non-dominated sorting is performed to divide different populations into different ranks; S34. Then, select, crossover, and mutate operations are used to generate the offspring population. ; S35, Parental population and offspring population Merge and perform non-dominated sorting, selecting individuals as new parent populations based on their crowding density; S36. Repeat steps S33 to S35 until the optimal solution is obtained.

5. The incremental deployment method for SDN redundant controllers in response to multiple controller failures as described in claim 4, characterized in that: Step S4 includes the following steps: S41. Generate a delay matrix for each controller failure scenario under each redundant controller deployment scheme, using the following formula: ； ； ； in, This indicates a redundant controller deployment scheme. Indicates controller failure scenario , This represents the set of switches within the fault controller domain; Represents the set of normal controllers; Indicates switch To the controller The minimum weighted delay; S42, Setting up a redundant controller deployment scheme and controller failure scenarios The weighted delay matrix of the lower switch is The controller selection scheme is as follows ; and All are one-dimensional matrices. ; This indicates the selected controller number for each switch; S43, Regarding For each row in the algorithm, starting with the first delay element, determine if the controller capacity meets the requirements. If not, continue checking the next delay element in the row. If the requirements are met, select that controller as the migration target and update its load and... ; S44, For Sort in ascending order, with the last row representing the redundant controller deployment scheme. In controller failure scenarios The maximum delay.

6. The incremental deployment method for SDN redundant controllers in response to multiple controller failures as described in claim 5, characterized in that: Step S41 includes the following steps: S411, For For each switch in the array, calculate its weighted delay to all normal controllers. All delays of each switch are denoted as a one-dimensional matrix, and the one-dimensional matrix is ​​sorted in ascending order. S412. Combine the one-dimensional matrices of all switches vertically into a two-dimensional matrix. The number of rows in a two-dimensional matrix is ​​equal to The number of switches in the middle, the number of columns in the two-dimensional matrix equals The number of controllers in the middle; S413. For each row of the two-dimensional matrix, sort them in ascending order according to the size of the first weighted delay.

Images