A method for dynamic hibernation of SDN controller based on switch migration

Abstract

The application discloses a kind of based on switch migration SDN controller dynamic dormancy method, it is related to software defined network technical field, to solve the problem of frequent dormancy wake-up, unreasonable migration decision and energy consumption and performance imbalance in existing SDN controller dormancy scheme.The method first real-time acquisition controller operating state data, calculate current load rate by multidimensional weighted load model and collect historical data;Then adopt long short-term memory network (LSTM) to predict future load, combine current and predicted load to filter and verify the controller to be put into dormancy;Subsequently, the candidate controller is screened to form a collaborative decision domain, and the optimal target controller is determined based on a multidimensional scoring model and a switch migration scheme is developed;After completing switch migration according to the four-stage process, the controller to be put into dormancy is switched to the dormant state;At the same time, the active controller load is monitored in real time, and when overload occurs and cannot be relieved by active controller migration, the dormant controller is awakened and load balancing migration is performed.The application effectively reduces the number of active controllers, reduces the overall network energy consumption, improves resource utilization, and adapts to the dynamic changes of network traffic while ensuring the quality of service of the SDN control plane.

Description

Technical Field

[0001] This invention relates to the field of software-defined networking (SDN) technology, and more specifically, to a dynamic sleep method for SDN controllers based on switch migration. This method is applicable to energy efficiency optimization of the SDN control plane and can reduce controller operating energy consumption and improve resource utilization while ensuring network service quality. Background Technology

[0002] Software-defined networking (SDN) achieves centralized control and programmability of the network by decoupling the control plane from the data plane, significantly improving network flexibility and management efficiency. However, as network scale increases, the energy consumption of SDN controllers becomes increasingly prominent. In multi-controller deployment scenarios, network traffic often fluctuates, causing some controllers to have low utilization or even idle during low-load periods, resulting in energy waste.

[0003] In existing technologies, controller hibernation mechanisms have been proposed as an energy-saving strategy, reducing energy consumption by putting some controllers into hibernation during low-load periods. For example, some solutions reduce energy consumption by optimizing controller deployment locations or hibernating low-traffic links. However, these methods do not fully consider the dynamic changes in network traffic and are prone to generating additional overhead due to frequent hibernation and wake-up, affecting network stability. In addition, existing switch migration strategies are mostly based on the current load status and lack prediction of future load, which may lead to short-sighted migration decisions, causing frequent migrations and increasing control signaling overhead and latency.

[0004] Specifically, the existing technology has the following drawbacks:

[0005] 1. Lack of foresight in hibernation decisions: Existing solutions typically make hibernation decisions based on the current load of the controller, without considering future load changes. This can easily trigger frequent state switching when traffic fluctuates, increasing energy consumption and performance jitter.

[0006] 2. Insufficient optimization during switch migration: Failure to comprehensively consider the target controller's load capacity, link distance, and migration cost during the migration process may result in load imbalance or low migration efficiency.

[0007] 3. Slow response of wake-up mechanism: When network load surges, existing wake-up strategies often rely on threshold triggering and lack prediction and proactive recovery mechanisms, which may lead to service delays or interruptions.

[0008] Although existing research has attempted to combine load prediction with switch migration strategies, there are still shortcomings in load prediction accuracy, multi-target migration decision-making, and coordinated adaptation of controller wake-up mechanisms, making it difficult to achieve an effective balance between energy consumption optimization, quality of service assurance, and network stability.

[0009] Therefore, there is an urgent need for an SDN controller management solution that can dynamically adapt to changes in network traffic and balance energy efficiency and performance. Summary of the Invention

[0010] To address the aforementioned shortcomings of existing technologies, this invention proposes a dynamic sleep method for SDN controllers based on switch migration. By employing load prediction, multi-target switch migration decision-making, and proactive controller wake-up strategies, this method minimizes the number of active controllers and reduces overall network energy consumption while ensuring the quality of service in the SDN control plane. This solves the problems of frequent sleep / wake-up, unreasonable migration decisions, and energy consumption-performance imbalance in existing solutions.

[0011] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0012] A method for dynamic hibernation of an SDN controller based on switch migration includes the following steps:

[0013] Step 1: Network Status Awareness and Load Data Acquisition: Real-time acquisition of the operating status data of all controllers in the SDN network, calculation of the current load rate of each controller based on a multi-dimensional weighted load model; and collection of historical load data of controllers to provide data support for subsequent load prediction.

[0014] Step 2: Controller load prediction and determination of controllers to be hibernated: Long Short-Term Memory (LSTM) network is used to predict the future load of each controller; combined with the current load rate of the controller and the future load prediction results, controllers that meet the hibernation conditions are selected and the load carrying capacity of the remaining active controllers after hibernation is verified.

[0015] Step 3: Candidate Controller Screening and Switch Migration Plan Formulation: Centered on the controller to be dormant, select candidate controllers with load acceptance capabilities to form a collaborative decision domain; calculate the comprehensive score of the candidate controllers based on a multi-dimensional scoring model to determine the optimal target controller; and formulate a switch migration plan according to load priority.

[0016] Step 4: Switch migration execution and controller hibernation: Perform switch migration according to the preset migration process. After all switches belonging to the controller to be hibernated are migrated, switch the controller to hibernation mode to reduce power consumption.

[0017] Step 5: Controller Overload Monitoring and Wake-up Adaptation: Monitor the load status of active controllers in real time. When an overload occurs and cannot be alleviated by migration between active controllers via switches, wake up the dormant controller. Develop and execute a migration plan from the switch to which the overloaded controller belongs to the woken-up controller to achieve network load balancing.

[0018] Furthermore, in step one:

[0019] The controller load rate LR_j is calculated using a multi-dimensional weighted model:

[0020]

[0021] in This is expressed as CPU utilization. This is expressed as the percentage of memory used. This represents the percentage of the task queue length. For dynamic weights.

[0022] Furthermore, in step two:

[0023] The controller load rate is divided into three levels: 1) Light load ( 1) Allows entry into hibernation. 2) Medium load ( 3) Overload ( ) The standby controller is woken up, triggering the migration operation. The controller to be put into hibernation must simultaneously meet the conditions that the current load rate is light and the future load forecast is also light.

[0024] The input to the LSTM load forecasting model is a historical load sequence. and flow characteristics Output for the future load prediction probability distribution of the step The load forecasting process includes a training phase and a forecasting phase. During the training phase, model parameters are adjusted using historical data, and during the forecasting phase, the trained model is used to output load forecasting results in real time.

[0025] When determining the controller to be put to sleep, the average load and the predicted average load after removing one active controller need to be calculated. If neither of them exceeds the maximum safe load, the lightly loaded controller with the fewest managed switches is selected as the controller to be put to sleep.

[0026] Furthermore, in step three:

[0027] Candidate controllers in the collaborative decision-making domain must meet two conditions: first, acceptable load. The first condition is greater than 0; the second condition is that the load after receiving the switch to be migrated will not exceed the overload threshold.

[0028] The target controller scoring function is defined as follows:

[0029]

[0030] in, The remaining load rate score for candidate controllers is calculated based on the deviation between the post-migration load and the average load. The score is the link distance score between the candidate controller and the switch to be migrated, which is inversely proportional to the distance. The migration cost score is inversely proportional to bandwidth and latency; , are weighting coefficients, satisfying... .

[0031] Furthermore, in step four, the switch migration process includes four stages:

[0032] Phase 1: Role change request. The target controller's role is changed from SLA to Equal. The hibernation controller sends a migration message to the target controller. After the target controller completes the switch role change, it sends a ready message back.

[0033] Phase 2: Migration preparation and empty flow table entry operation. The hibernation controller sends a Flow-mod message to the switch to add and delete empty flow table entries. After the switch executes the message, it sends a Flow-removed message.

[0034] Phase 3: Migration Confirmation. The hibernation controller confirms that the request processing is incomplete via a Barrier-request message. Once the processing is complete, it sends a migration completion message to the target controller.

[0035] Phase 4: Final role modification. The target controller changes its role in the switch to master, completing the migration and takeover.

[0036] Furthermore, in step five:

[0037] After the controller wakes up, the switch to which the overloaded controller belongs is selected first for migration, with the shortest link distance to the woken-up controller. Two load constraints must be met during the migration process:

[0038]

[0039]

[0040] in The load rate after controller migration, The load rate before migration The increased load caused by migrating the switch. Attached Figure Description

[0041] 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.

[0042] Figure 1 is a schematic diagram of switch migration under a light-load scenario of the controller in an embodiment of the present invention;

[0043] Figure 2 is a flowchart of the SDN controller dynamic sleep method based on switch migration in an embodiment of the present invention;

[0044] Figure 3 is a flowchart of the algorithm for determining the sleep controller in an embodiment of the present invention;

[0045] Figure 4 is a flowchart of the algorithm for the switch migration scheme in this embodiment of the invention;

[0046] Figure 5 is a schematic diagram of the switch migration execution process in an embodiment of the present invention;

[0047] Figure 6 is a flowchart of the controller wake-up and load balancing algorithm in an embodiment of the present invention;

[0048] Figure 7 is a diagram of the experimental simulated network topology in an embodiment of the present invention;

[0049] Figure 8 is a comparison of the load generated by switches within the jurisdiction of different controllers in an embodiment of the present invention;

[0050] Figure 9 is a comparison chart of the energy saving rates of different schemes in the embodiments of the present invention;

[0051] Figure 10 is a comparison of real-time energy of different schemes in the embodiments of the present invention;

[0052] Figure 11 is a comparison of the total energy of different schemes in the embodiments of the present invention;

[0053] Figure 12 is a comparison chart of the average link distance of different schemes in the embodiments of the present invention;

[0054] Figure 13 is a comparison chart of migration overhead for different schemes in the embodiments of the present invention. Detailed Implementation

[0055] To better illustrate the content of this invention, specific embodiments are provided below to further verify the invention. It is hereby stated that these embodiments are merely for more direct description of the invention and are only a part of it, and should not be construed as limiting the invention in any way. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0056] Architecture Implementation

[0057] This invention provides an SDN controller dynamic hibernation architecture based on switch migration, including a state awareness module, a load prediction module, a controller to be hibernated determination module, a switch migration decision module, a migration execution module, and a wake-up adaptation module. These modules work together to achieve dynamic hibernation of the controller and network load balancing.

[0058] 1. Status Awareness Module: Deployed on each controller node in the SDN network, it collects real-time operating status data such as CPU utilization, memory usage, and task queue length of the controller, and calculates the multi-dimensional weighted load rate of each controller to provide basic data for subsequent modules;

[0059] 2. Load Forecasting Module: A load forecasting model is built based on a Long Short-Term Memory (LSTM) network. It takes the controller's historical load sequence and traffic characteristics as input and outputs the future load forecast. The load prediction results of the step support the accurate determination of the controller to be in hibernation;

[0060] 3. Hibernation Controller Determination Module: Combining the current load rate output by the status perception module and the future load prediction value output by the load prediction module, the module filters light-load controllers, verifies the feasibility of hibernation, and determines the final hibernation controllers.

[0061] 4. Switch Migration Decision Module: A collaborative decision domain is built around the controller to be hibernated. The optimal target controller is selected through a multi-dimensional scoring model, and a migration plan is formulated according to the switch load priority.

[0062] 5. Migration Execution Module: Following the preset four-stage migration process, the module executes the migration operation of the switch from the controller to be hibernated to the target controller. After the migration is completed, the controller to be hibernated is triggered to enter hibernation mode.

[0063] 6. Wake-up Adaptor Module: Monitors the load of active controllers in real time. When an overload occurs and cannot be alleviated by migration between active controllers, it wakes up the dormant controller and formulates a switch migration plan to achieve network load balancing.

[0064] Method Implementation Examples

[0065] Referring to Figures 2 to 5, this embodiment of the invention provides a dynamic sleep method for an SDN controller based on switch migration, the specific steps of which are as follows:

[0066] 1. Network Status Awareness and Load Data Acquisition: Deploy status acquisition components on each controller in the SDN network to monitor and collect the controller's CPU computation load in real time. Maximum acceptable computational load Current memory usage Maximum memory consumption Number of unprocessed tasks in the current queue and queue maximum capacity Data such as load factor is used to calculate the load rate of each controller based on a multi-dimensional weighted load model. The dynamic weights α, β, and γ are adjusted in real time through online learning to ensure the accuracy of load rate calculation. Simultaneously, historical load data from the controller is continuously stored to form a historical load sequence, providing data support for load forecasting.

[0067] 2. Controller Load Prediction and Dormant Controller Determination: The load prediction module is invoked, and the historical load sequences LR(t - 10), LR(t - 9), ..., LR(t) and current traffic characteristics are input into the trained LSTM model to obtain the load prediction probability distribution for the next τ steps. Based on the load rate classification criteria, the current and future load levels of each controller are determined.

[0068] The algorithm for determining which controllers are to go to sleep is executed, and the specific process is shown in Figure 3: Input the network topology, the load status of all controllers in the network, the set of sleep controllers, the set of active controllers, and the maximum safe load; predict the future load of active controllers using `Predict_Load[]`; calculate the total system load `total_system_load` and the average load `avg_load` after removing one active controller, as well as the predicted average load `predicted_avg_load` corresponding to the predicted total system load; if the predicted average load and the average load do not exceed... If the number of active controllers does not exceed 1 or the average load exceeds the safe range, the decision process is terminated.

[0069] 3. Candidate controller screening and switch migration plan development: Screening controllers that meet acceptable load requirements. Controllers with a load greater than 0 and whose load does not exceed the limit after receiving the switch form a collaborative decision domain. Switches belonging to the controllers to be in hibernation are sorted in descending order of load, and switches with higher loads are migrated first.

[0070] The algorithm for implementing the switch migration plan is shown in Figure 4. The inputs are the switch number (s_id) to be migrated, the source controller (src_controller), and the set of candidate controllers. If s_id is not in the switch set, return migration failure; otherwise, the source controller removes the switch; calculate the migration cost score for each candidate controller. Remaining load rate score and link distance score A comprehensive score is calculated using a multi-dimensional scoring model. Select the candidate controller with the highest score as the optimal target controller, add the switch to be migrated to the controller, calculate the actual migration cost, and return the migration success result and cost data.

[0071] The switch migration and controller hibernation process follows a four-stage migration procedure: In the first stage, the target controller's role is changed to "equal," and the hibernation controller sends a migration message. The switch completes the role change and then reports readiness. In the second stage, the hibernation controller sends a `Flow-mod` message to the switch to add empty flow entries. After confirming execution via a `Barrier-request` message, it sends another `Flow-mod` message to delete the empty flow entries. The switch then executes this and sends a `Flow-removed` message. In the third stage, the hibernation controller handles incomplete requests via `Barrier-request` messages and sends a migration completion message to the target controller. In the fourth stage, the target controller changes its role in the switch to "master," completing the migration takeover. After all switches belonging to the hibernation controller have migrated, the controller enters hibernation mode, and its power consumption switches to a fixed hibernation power consumption. .

[0072] 4. Controller Overload Monitoring and Wake-up Adaptation: Real-time monitoring of the load status of active controllers. When a controller overload rate is detected... When this happens, add it to the overloaded controller set overloaded_controllers. First, try migrating the switch of the overloaded controller to another active controller. If the load rate of the overloaded controller drops below the threshold after migration, there is no need to wake up the dormant controller. If all active controllers cannot effectively share the load and future traffic is predicted to continue to grow, then the controller wake-up process is triggered.

[0073] The controller wake-up algorithm is executed, and the specific process is shown in Figure 5: Initialize the overload controller set `overload_controllers` and the wake-up controller set `wake_up_controllers`; traverse the active controllers and filter out the overload controllers; for each overload controller, attempt to migrate the switch to other active controllers. If the load returns to normal after migration, continue traversing; if the load is still overloaded, wake up the dormant controller `wake_up_ctrl` and add it to `wake_up_controllers`; migrate some switches of the overload controller to the woken controllers until the overload controller load returns to normal, and further perform load balancing operations to ensure that the wake-up controller load is within a reasonable range, and return the processing result and the wake-up controller set.

[0074] It should be noted that this method embodiment is based on the same inventive concept as the above-described architecture embodiment, and the functions and method steps of each module correspond one-to-one to ensure the consistency and completeness of the technical solution.

Claims

1. A dynamic sleep method for SDN controllers based on switch migration, characterized in that, The steps are as follows: Step 1: Network Status Awareness and Load Data Acquisition: Real-time acquisition of operational status data for all controllers in the SDN network. This operational status data includes CPU computational load, maximum acceptable computational load, current memory usage, maximum memory consumption, number of unprocessed tasks in the current queue, and maximum queue capacity. The current load rate of each controller is calculated based on a multi-dimensional weighted load model. The calculation formula for the multi-dimensional weighted load model is as follows: in This is expressed as CPU utilization. This is expressed as the percentage of memory used. This represents the percentage of the task queue length. The weights are dynamic and adjusted through online learning. Simultaneously, historical load data from the controller is collected to form a historical load sequence. Step 2: Controller Load Prediction and Controller Dormancy Determination: A load prediction model is constructed using a Long Short-Term Memory (LSTM) network. The historical load sequences LR(t-10), LR(t-9), ..., LR(t) and current traffic characteristics are input into the model, which outputs the load prediction results for the next several steps. The controller load is divided into light load (...) based on the load rate. ), mid-load ( ), overload ( The system is divided into three levels; controllers that are currently and predicted to be lightly loaded are selected as candidates for hibernation; the average load avg_load and predicted average load predicted_avg_load after reducing one active controller are calculated. If both do not exceed the maximum safe load and the number of active controllers is greater than 1, the candidate controller with the fewest managed switches is selected as the final hibernation controller. Step 3: Candidate controller screening and switch migration plan formulation: Screen controllers with acceptable load > 0 and whose load after receiving the switch to be migrated does not exceed the overload threshold, and form a collaborative decision domain; The switches to which the sleep controller belongs are sorted in descending order of load; the comprehensive score of each candidate controller in the collaborative decision domain is calculated based on a multi-dimensional scoring model, the calculation formula of which is: in: Score the remaining load rate of the candidate controller; The score is calculated based on the link distance between the candidate controller and the switch to be migrated, and is inversely proportional to the distance. The score is based on migration cost (such as bandwidth overhead, latency, etc.). The lower the migration cost, the higher the score. 𝛼, 𝛽 are weighting coefficients, satisfying . Select the candidate controller with the highest comprehensive score as the optimal target controller and formulate a switch migration plan; Step 4: Switch Migration Execution and Controller Hibernation: Execute the switch migration according to a preset procedure, which includes: Phase 1: The target controller's role is changed from slave to equal. The hibernation controller sends a migration message to the target controller. After the target controller completes the switch role change, it sends a migration ready message back to the hibernation controller. Phase 2: The sleep controller sends a Flow-mod message to the switch to add an empty flow table entry, sends a Barrier-request message to confirm the addition is complete, and then sends a Flow-mod message to delete the empty flow table entry. After the switch performs the operation, it sends back a Flow-removed message. Phase 3: After the hibernation controller confirms that the incomplete request processing has been completed, a migration completion message is sent to the target controller. Phase 4: The target controller changes its role in the switch to master, completing the migration and takeover; After all switches belonging to the hibernation controller have completed migration, the controller will be switched to hibernation mode. The power consumption in hibernation mode is a fixed value. ; Step 5: Controller Overload Monitoring and Wake-up Adaptation: Monitor the load status of active controllers in real time, and... The controller is assigned to the overload controller set; an attempt is made to migrate the switch to which the overload controller belongs to another active controller. If the load rate of the overload controller does not exceed 70% after migration, the operation is terminated; if all active controllers cannot share the load and future traffic is predicted to continue to increase, the dormant controller is woken up; the switch to which the overload controller belongs is selected first for migration, and the following conditions must be met after migration: in The load rate after controller migration, The load rate before migration The load increase caused by the migration of the switch. Until the overload controller load rate is ≤70%, and then perform load balancing operation.

2. The SDN controller dynamic sleep method based on switch migration according to claim 1, characterized in that, In step 1: in Represented as the current controller CPU computational load, This represents the maximum acceptable computational load for the controller. in Represented as the current controller Memory usage Maximum memory consumption; in This represents the number of unprocessed tasks in the current queue. Maximum capacity of the queue.

3. The SDN controller dynamic sleep method based on switch migration according to claim 1, characterized in that, In step 3: The calculation rules are as follows: in The load rate of the target controller after receiving the switch. The average load rate of the non-sleep controller. This represents the maximum acceptable load rate for the controller.

4. The SDN controller dynamic sleep method based on switch migration according to claim 1, characterized in that, In step 3: in The link distance between the candidate controller and the switch to be migrated is the minimum distance; the smaller the distance, the higher the link distance score. in For the data volume of the switch, This represents the maximum bandwidth that the current controller can receive. This refers to transmission delay.

5. The SDN controller dynamic sleep method based on switch migration according to claim 1, characterized in that, In step 4: The energy consumption of the controller in sleep mode is a constant. : The energy consumption calculation formula for the controller in active state is as follows: in This indicates that the controller is in the CPU state. and load The energy consumption generated under the circumstances, of which In It is described as the set of frequency states supported by the CPU. in The controller is at a CPU frequency of Energy consumption in both the active and idle states. The controller is at a CPU frequency of Energy consumption at full load under certain conditions. Is the controller in CPU utilization under certain conditions. It is a value measured in an experiment.

6. The SDN controller dynamic sleep method based on switch migration according to claim 1, characterized in that, In step 5: The selection priority for wake-up controllers is as follows: first, select the sleep controller with the shortest link distance to the overload controller; then, select the sleep controller with the shortest historical response time; and finally, select the sleep controller with the lowest failure rate.

Images