SDN (Software Defined Network) dynamic control system based on cloud native architecture

Abstract

The invention provides an SDN (Software Defined Network) dynamic control system based on a cloud native architecture, and belongs to the technical field of SDN and cloud native. The system adopts a three-layer decoupling architecture of a service layer, a control layer and a data layer, wherein the service layer consists of a core network, a cloud platform and edge nodes and is used for issuing service requirements and executing a joint resource scheduling strategy; the control layer comprises four core modules, namely a micro-servitization SDN control module, a cross-domain collaborative engine module, an end-to-end service quality guarantee module and an edge collaborative optimization module, and is responsible for unified analysis, decision and scheduling to realize dynamic updating of a network strategy and multi-cluster collaborative optimization; the data layer is composed of an SDN switch and a router, and is used for executing a flow table rule and collecting network situation data. Through deep fusion of the SDN and the cloud native technology, the problems of upgrade interruption, low cross-domain collaboration efficiency and edge resource limitation of a traditional network architecture are solved, and the method can be widely applied to hybrid cloud management, industrial Internet of Things and intelligent city network scenes.

Description

Technical Field

[0001] This invention relates to the fields of software-defined networking (SDN) and cloud-native technologies, and in particular to a dynamic control system for SDN networks based on a cloud-native architecture, which supports network collaboration among multiple clusters. Background Technology

[0002] While SDN technology is now widely used for centralized network management, traditional controllers often employ monolithic architectures, requiring downtime for algorithm updates and hindering their ability to adapt to the rapid iteration demands of cloud-native environments. For example, upgrading a financial-grade network necessitates service interruptions, severely impacting business continuity. Furthermore, while existing modular designs enhance flexibility, they lack deep integration with cloud-native platforms, preventing elastic scaling of resources and resulting in inefficient cross-cluster resource collaboration.

[0003] In hybrid cloud and edge computing scenarios, network coordination among multiple clusters relies on static policies, lacking real-time dynamic adjustment capabilities. For example, cross-cluster traffic scheduling often results in insufficient bandwidth utilization due to fixed paths and an inability to detect changes in business load, leading to delayed troubleshooting. In scenarios with high-speed node movement, network topology changes frequently, making it difficult for traditional IP network architectures to adapt dynamically, causing packet loss and latency issues. Existing solutions attempt to optimize network layer resource allocation through SDN, but fail to form a closed-loop feedback with the container orchestration layer (such as Kubernetes, hereinafter referred to as K8S), resulting in a disconnect between network policies and business needs. For example, network policy updates are delayed during container migration, causing service interruptions or resource waste, resulting in container network performance degradation. K8S's default scheduling algorithm only focuses on resource matching and does not consider the needs of network latency-sensitive applications, leading to delayed network policy updates during container migration and an increased risk of service interruption.

[0004] Although some studies have applied SDN to 5G core networks and certain cloud computing fields, their QoS policies are limited to a single network domain, failing to cover the entire link from wireless access to the cloud platform, and lacking dynamic algorithm loading and real-time policy synchronization. Large-scale heterogeneous terminals (such as industrial sensors and smart home appliances) face interoperability difficulties due to protocol diversity, making unified orchestration difficult to achieve with traditional centralized architectures.

[0005] In summary, how to solve the problems of resource waste caused by rigid traditional network architecture, low resource utilization, lack of cross-layer collaboration and blank full-link optimization, lack of linkage between network policies and service scheduling, and high operation and maintenance complexity are urgent problems to be solved by those skilled in the art. Summary of the Invention

[0006] This invention proposes a dynamic control system for SDN networks based on a cloud-native architecture. Its core lies in constructing a three-layer decoupled collaborative architecture consisting of a business layer, a control layer, and a data layer. It also deeply integrates the fine-grained control capabilities of SDN with the cloud-native microservice architecture. By microserviceizing the control layer and deeply integrating it with the cloud-native platform, it enables dynamic updates of network policies and cross-cluster collaborative optimization.

[0007] The technical solution adopted in this invention is as follows:

[0008] A cloud-native architecture-based SDN network dynamic control system, the system comprising a service layer, a control layer, and a data layer;

[0009] The business layer includes a core network, a cloud platform, and edge nodes. The core network and cloud platform are used to send business flow requests, cross-cluster link status, and local resource data to the control layer. Lightweight agents run on the edge nodes to receive and execute the joint resource scheduling policies generated by the control layer, schedule service instances to designated nodes, and report the policy execution effect to the control layer. At the same time, they continuously synchronize and manage the edge agent status with the control layer.

[0010] The control layer is connected to the business layer and the data layer. It is used to receive business flow requests, cross-cluster link status, local resource data and policy execution effects issued by the business layer, as well as network situation data uploaded by the data layer. It performs unified analysis, decision-making and scheduling, generates network control policies and further converts them into flow table rules and sends them to the data layer. At the same time, it generates joint resource scheduling policies and uploads them to the business layer.

[0011] The data layer includes SDN switches and routers, which are used to execute flow table rules issued by the control layer, complete packet forwarding, and collect network situation data and upload it to the control layer.

[0012] Furthermore, the control layer includes a microservice-based SDN control module, a cross-domain collaboration engine module, an end-to-end quality of service assurance module, and an edge collaboration optimization module;

[0013] The microservice-based SDN control module receives network status data uploaded from the data layer and service flow requests and cross-cluster link statuses issued by the service layer. It calculates network paths and monitors status by invoking routing algorithms, generates network control policies, and further transforms them into complete flow table rules for distribution to the data layer. It also receives flow table adjustment instructions from the end-to-end quality of service (QoS) assurance module and distributes the necessary local flow table rules to the data layer. Furthermore, it continuously interacts with the edge collaboration optimization module to synchronize status and policies, providing configuration and policy data for lightweight proxy operation on edge nodes. It also transmits traffic monitoring data to the cross-domain collaboration engine module, receives policy iteration and optimization instructions, adjusts transmission policies according to the instructions, and distributes complete flow table rules to the data layer, overwriting existing flow tables. Finally, it gradually captures abnormal network states, including link breaks, topology changes, and network congestion, through traffic monitoring and outputs these network anomalies to the end-to-end QoS assurance module.

[0014] The cross-domain collaboration engine module is used to receive traffic monitoring data generated by the microservice SDN control module, and integrate multi-domain data such as business flow requests, cross-cluster link status, local resource data and policy execution effect from the business layer to generate a joint resource scheduling policy that integrates routing policies and business scheduling suggestions, and transmits it to the business layer; it is also used to generate policy iteration optimization instructions based on the routing policy and transmit them to the microservice SDN control module to realize transmission policy iteration optimization.

[0015] The end-to-end quality of service assurance module is used to receive network anomalies monitored by the microservice SDN control module and service flow requests and cross-cluster link status transmitted by the service layer. When a network anomaly occurs, it calculates a new transmission path based on the priority information of the service flow request and the cross-cluster link status, converts it into a flow table adjustment instruction, and sends it to the microservice SDN control module.

[0016] The edge collaboration optimization module is used to synchronize policies and interact with the microservice-based SDN control module, and to synchronize state data and management configuration data with the lightweight agent running on the edge node, manage the lightweight agent of the edge node, and realize edge autonomy.

[0017] Furthermore, the microservice-based SDN control module includes a routing calculation component, a traffic monitoring component, a policy execution component, and an algorithm management component;

[0018] The routing calculation component is used to obtain network topology data from the traffic monitoring component and cross-cluster link status from the business layer, match routing algorithm plugins according to business flow requests, and call the SDN control algorithm plugin in the algorithm management component to perform path calculation, generate the optimal transmission policy, and output it to the policy execution component.

[0019] The traffic monitoring component is used to collect network situation data from the data layer through monitoring tools, store it in the database to form a network situation database, provide network topology data for the routing calculation component, and output the monitored latency, bandwidth and feedback data to the cross-domain collaboration engine module. At the same time, it captures network anomalies and transmits them to the end-to-end service quality assurance module.

[0020] The policy execution component is used to receive the optimal transmission policy from the routing calculation component, the policy iteration optimization instruction from the cross-domain collaboration engine module, and the flow table adjustment instruction from the end-to-end service quality assurance module, convert them into flow table rules and send them to the data layer, and at the same time continuously interact with the edge collaboration optimization module in terms of state and policy synchronization.

[0021] The algorithm management component is used to obtain SDN control algorithm images from the image repository, perform version management, monitor new version algorithm images and update them on a rolling basis, and match SDN control algorithms for the routing calculation component according to business logistics needs and cross-cluster link status.

[0022] Furthermore, the routing calculation component consists of one or more routing algorithm plugins, used to match transmission tasks in different business scenarios; after listening to the new version algorithm image, the algorithm management component starts the new version algorithm container instance, gradually migrates traffic to the new instance through the service mesh, and reclaims the old version container. If the new version algorithm causes performance abnormalities, it automatically triggers the rollback process to restore to the stable version.

[0023] Furthermore, the cross-domain collaboration engine module is used for:

[0024] The system acquires service flow requests carrying QoS parameters, cross-cluster link status data, and policy execution results for historical policies from the core network and cloud platform at the service layer. It also acquires local resource data from edge nodes at the service layer and traffic monitoring data from the traffic monitoring component. The acquired multi-source data is normalized to construct a cross-domain resource scoring model. Based on the scoring model, a joint resource scheduling policy integrating routing policies and container scheduling suggestions is generated. This joint resource scheduling policy is injected into the service layer through a Kubernetes custom resource definition interface. The policy iteration and optimization instructions generated based on the joint resource scheduling policy are transmitted to the policy execution component of the microservice-based SDN control module. Simultaneously, traffic monitoring data from the traffic monitoring component is received for policy optimization.

[0025] Furthermore, the end-to-end quality of service assurance module is used for:

[0026] Service flow requests are obtained from the core network at the service layer and mapped to the DSCP tag field of SDN to mark the priority and quality of service requirements of network traffic, thereby distinguishing different types of service flow requests;

[0027] Network anomaly data is obtained from the traffic monitoring component. When the latency and packet loss rate exceed the threshold, an alarm is triggered and a fast recovery mechanism is started. A new transmission path is calculated based on the priority of business flow requests, service quality requirements, and cross-cluster link status.

[0028] The transmission path is converted into a flow table adjustment command and sent to the microservice SDN control module to correct the business flow transmission strategy.

[0029] Furthermore, the edge collaborative optimization module is used for:

[0030] Deploy and manage lightweight proxies for edge nodes in the business layer at the control layer;

[0031] The network policy is received from the microservice-based SDN control module in the control layer and distributed to the lightweight agent on the edge node for execution.

[0032] It receives status data and management configuration data collected by the lightweight agent of the edge node and synchronizes them to the microservice SDN control module;

[0033] The lightweight agent at the edge node dynamically adjusts the granularity of the flow table based on the local resource utilization: when resources meet the demand, the flow table is refined; when resources do not meet the demand, similar flow table entries are merged.

[0034] Furthermore, the cluster management tools used in the business layer include Kubernetes K8S, K3s, and KubeEdge; the business layer communicates with the modules within the control layer via the gRPC protocol, and cross-domain service collaboration is achieved through the modules within the control layer; the control layer communicates with the data layer via the OpenFlow protocol.

[0035] A computer-readable storage medium storing a computer program that, when executed by a processor, performs the functions of the system described above.

[0036] Compared with the prior art, the present invention has the following main advantages:

[0037] 1. This invention designs a dynamic algorithm hot update mechanism, which realizes uninterrupted upgrade and elastic scaling of SDN control algorithm through microservice architecture and rolling update mechanism.

[0038] 2. This invention has smooth compatibility and can be adapted to mainstream CNI plugins (such as Calico, Cilium, etc.) and network protocols (BGP / OSPF / RIP), supporting seamless migration from traditional data centers to 5G edge scenarios.

[0039] 3. This invention adopts a joint strategy optimization to achieve cross-domain resource collaboration. Through closed-loop feedback of network status and container scheduling and an end-to-end QoS guarantee mechanism, it can effectively optimize the transmission performance of critical services, reduce end-to-end service latency, improve cross-cluster bandwidth utilization, and the resource management effect is significantly better than that of static strategy schemes.

[0040] 4. This invention supports edge autonomy capabilities, enabling rapid response to local policies through lightweight agents, significantly improving the utilization rate of edge node resources, and reducing dependence on the central cloud. Attached Figure Description

[0041] Figure 1 This is the overall system architecture diagram of the present invention.

[0042] Figure 2 This is a flowchart of the dynamic algorithm update process of this invention.

[0043] Figure 3 This is a schematic diagram of the joint strategy generation and injection of the present invention. Detailed Implementation

[0044] This invention presents a cloud-native SDN network dynamic control system for cloud-native network environments. Addressing the problems of low resource utilization, lack of cross-layer collaboration, and gaps in end-to-end optimization inherent in traditional network architectures, it constructs a three-layer decoupled architecture comprising a business layer, a control layer, and a data layer. The SDN control layer is microservice-based and deeply integrated with the cloud-native platform, enabling dynamic updates of network policies, multi-cluster collaborative optimization, and end-to-end service quality assurance. The overall system architecture is as follows: Figure 1 As shown in the accompanying drawings and specific embodiments, the technical solution of the present invention will be described in detail below.

[0045] In this embodiment, the service layer mainly includes the core network, the Kubernetes cluster (cloud platform), and edge nodes (managed using KubeEdge). The data layer consists of multiple SDN switches supporting the OpenFlow protocol. The control layer, as the core, is connected to the service layer and the data layer, and is deployed in the Kubernetes cluster. It contains four core modules: a microservice-based SDN control module, a cross-domain collaboration engine module, an end-to-end quality of service assurance module, and an edge collaboration optimization module.

[0046] The main working process of this embodiment is as follows:

[0047] Data Acquisition: The SDN switches at the data layer report network status data, such as port traffic statistics and link status, to the traffic monitoring component at the control layer via the OpenFlow protocol. Simultaneously, the core network at the service layer reports service flow requirements, cross-cluster link status, local resource data, and policy execution results to the cross-domain collaboration engine module at the control layer via the NEF interface, the cloud platform via the Metrics API, and edge nodes via lightweight proxies.

[0048] Dynamic policy generation: The cross-domain collaboration engine module of the control layer integrates all data, generates joint policies based on the resource scoring model (such as routing high-priority video streams in the core network to low-latency links and suggesting that the scheduler deploy the corresponding Pods to edge nodes closer to users), and merges network rules and scheduling suggestions into a joint resource scheduling policy;

[0049] Policy execution and feedback: Flow table rules are distributed to the data layer switches via the policy execution component; scheduling suggestions are injected into the Kubernetes scheduler in the business layer via CRDs to drive Pod migration. The execution effects of the business layer and data layer are monitored in real time and fed back to the control layer, forming a closed-loop optimization system.

[0050] Anomaly Recovery: When the control layer detects a link failure or node overload, the end-to-end service quality assurance module automatically triggers the recovery process, generates flow table adjustment instructions, and switches paths through the policy execution component's instruction data layer to ensure business continuity.

[0051] The system described in this embodiment includes a business layer, a control layer, and a data layer:

[0052] The business layer includes a core network, a cloud platform, and edge nodes. The core network and cloud platform are used to send business flow requests, cross-cluster link status, and local resource data to the control layer. Lightweight agents run on the edge nodes to receive and execute the joint resource scheduling policies generated by the control layer, schedule service instances to designated nodes, and report the policy execution effect to the control layer. At the same time, they continuously synchronize and manage the edge agent status with the control layer.

[0053] The control layer is connected to the business layer and the data layer. It is used to receive business flow requests, cross-cluster link status, local resource data and policy execution effects issued by the business layer, as well as network situation data uploaded by the data layer. It performs unified analysis, decision-making and scheduling, generates network control policies and further converts them into flow table rules and sends them to the data layer. At the same time, it generates joint resource scheduling policies and uploads them to the business layer.

[0054] The data layer includes SDN switches and routers, which are used to execute flow table rules issued by the control layer, complete packet forwarding, and collect network situation data and upload it to the control layer.

[0055] The control layer described in this embodiment includes a microservice-based SDN control module, a cross-domain collaboration engine module, an end-to-end quality of service (QoS) assurance module, and an edge collaboration optimization module. The microservice-based SDN control module receives network status data uploaded from the data layer and service flow requests and cross-cluster link statuses issued by the service layer. It calculates network paths and monitors status by invoking routing algorithms, generates network control policies, and further converts them into complete flow table rules for distribution to the data layer. It also receives flow table adjustment instructions from the end-to-end QoS assurance module and distributes the necessary local flow table rules to the data layer. Furthermore, it continuously interacts with the edge collaboration optimization module to synchronize status and policies, providing configuration and policy data for lightweight proxy operation on edge nodes. It also transmits traffic monitoring data to the cross-domain collaboration engine module, receives policy iteration optimization instructions, adjusts transmission policies according to instructions, and distributes complete flow table rules to the data layer, overwriting existing flow tables. Finally, it gradually captures abnormal network states, including link breaks, topology changes, and network congestion, through traffic monitoring and outputs these network anomalies to the end-to-end QoS assurance module.

[0056] The construction process and functions of the microservice-based SDN control module are as follows:

[0057] S101, Split the SDN controller into functional components.

[0058] The traditional monolithic SDN controller is split into four independent components and deployed in a containerized manner within the control layer cluster:

[0059] The routing calculation component subscribes to topology change events in the network situation database. When a link state change is detected at the data layer, it matches the routing algorithm plugin (BGP / OSPF protocol or pluggable algorithm (such as Dijkstra)) according to the service flow request. At the same time, it calls the SDN control algorithm plugin in the algorithm management component to dynamically recalculate the optimal path and sends the new transmission policy to the policy execution component.

[0060] The traffic monitoring component integrates the Prometheus monitoring tool to continuously collect network status data such as link latency, bandwidth utilization, and packet loss rate from the data layer switches. All data is stored in the network status database, providing network topology data for the routing calculation component. The monitored latency, bandwidth, and feedback data are output to the cross-domain collaboration engine module, while network anomalies are captured and transmitted to the end-to-end quality of service assurance module.

[0061] The policy execution component receives transmission policies from the routing calculation component, policy iteration and optimization instructions from the cross-domain collaboration engine module, and flow table adjustment instructions from the end-to-end quality of service assurance module. It converts these into specific flow table rules and distributes them to the SDN switches in the data layer through a canary release strategy (such as batch distribution) to avoid network instability. At the same time, it continuously interacts with the edge collaboration optimization module to synchronize status and policies.

[0062] The algorithm management component manages the container image versions of SDN control algorithms (such as congestion control and load balancing algorithms), monitors new algorithm image versions and updates them on a rolling basis, provides API interfaces for operations and maintenance personnel to query, and matches SDN control algorithms to the routing calculation component based on business logistics requirements and cross-cluster link status.

[0063] S102, Containerized Deployment and Communication Configuration.

[0064] Each module is packaged as a Docker image and deployed on a Kubernetes cluster. Modules communicate with each other via the gRPC protocol and are registered with the Consul service discovery center. TLS authentication is enabled for the communication links to ensure security. Guaranteed-level QoS is configured for other components (such as route calculation), and dedicated resources are allocated to them.

[0065] S103, Dynamic Algorithm Loading Mechanism.

[0066] like Figure 2 As shown, the process includes:

[0067] Image management involves packaging the optimized routing algorithm into an image and pushing it to a private Harbor repository, with tags following semantic versioning.

[0068] Version monitoring and updates are handled by the Kubernetes Operator in the algorithm management component, which monitors the image repository. When a new version tag is detected, a rolling update is automatically triggered, creating a new version algorithm Pod instance. 10% of traffic is switched to the new instance via Istio's VirtualService configuration. After verifying the new instance's performance is stable, the 100% traffic switch is gradually completed.

[0069] In case of abnormal rollback, if the traffic monitoring component detects that the packet loss rate of the new algorithm instance increases by more than 5%, it will immediately issue an alarm and trigger the rollback process: the Operator will switch all traffic back to the old version stable instance and record the event log for troubleshooting.

[0070] The cross-domain collaboration engine module in the control layer of this embodiment is used to receive traffic monitoring data generated by the microservice SDN control module, and integrate multi-domain data such as business flow requests, cross-cluster link status, local resource data and policy execution effect from the business layer to generate a joint resource scheduling policy that integrates routing policies and business scheduling suggestions, and transmits it to the business layer; it is also used to generate policy iteration optimization instructions based on the routing policy and transmit them to the microservice SDN control module to realize transmission policy iteration optimization.

[0071] The construction and execution process of the cross-domain collaboration engine module is as follows:

[0072] S201, Multi-domain network status acquisition and modeling.

[0073] The cross-domain collaboration engine collects core network service flow requirements, cross-cluster link status data of the cloud platform cluster, and local resource data of edge nodes from the business layer; it also obtains traffic monitoring data from the traffic monitoring component of the control layer. After normalizing all the data, a cross-domain resource scoring model is constructed.

[0074] S202, Joint Strategy Generation and Injection.

[0075] like Figure 3 As shown, the method for generating joint strategies based on the cross-domain resource scoring model is as follows:

[0076] For AR inspection services (high priority, low latency), the engine generates policies. On the network side, a dedicated bandwidth path is reserved on the data layer switch via the control layer policy execution component. On the service side, it is recommended that the service layer scheduler prioritize scheduling Pods to edge nodes with GPU resources.

[0077] Policy injection involves transmitting network policies to the policy execution component, converting them into flow tables, and then distributing them to the data layer SDN switches. Scheduling suggestions are converted into Kubernetes CRDs (Custom Resources) and injected into the business layer, influencing its scheduling decisions.

[0078] S203, closed-loop feedback and dynamic optimization.

[0079] After the business layer Pod runs, the actual policy execution effect (such as end-to-end latency) is collected again by the control layer and fed back to the cross-domain collaboration engine module. The engine judges the effectiveness of the policy based on this, and if the goal is not achieved, a new round of iterative optimization is triggered.

[0080] The end-to-end quality of service assurance module in the control layer described in this embodiment is used to receive network anomalies monitored by the microservice SDN control module and service flow requests and cross-cluster link status transmitted by the service layer. When a network anomaly occurs, it calculates a new transmission path based on the priority information of the service flow request and the cross-cluster link status, converts it into a flow table adjustment instruction, and sends it to the microservice SDN control module.

[0081] The construction process and functions of the end-to-end quality of service assurance module are as follows:

[0082] S301, QoS policy mapping and priority marking.

[0083] Network-side mapping: The end-to-end QoS assurance layer receives business logistics requirements carrying QoS parameters from the business layer core network and converts them into SDN DSCP tag fields according to a pre-set mapping table.

[0084] On the cloud platform side, this layer uses the Cilium CNI plugin to convert the bandwidth limiting annotations in the Pod's NetworkPolicy into the corresponding flow table rules in the data layer switch, thereby achieving bandwidth limiting.

[0085] S302, Anomaly Detection and Rapid Recovery.

[0086] The traffic monitoring component detects anomalies in parameters such as latency and packet loss rate across cluster links and generates alarms, triggering a rapid recovery process, specifically:

[0087] In the fast path switching, after receiving an alarm, the end-to-end service quality assurance module calculates a new transmission path based on service priority and link status, converts it into a flow table adjustment instruction, and sends it to the policy execution component, which then issues the new flow table to the relevant data layer switches to switch the affected service traffic to the preset backup path.

[0088] Business migration involves calling the business layer Kubernetes API through the cross-domain collaboration engine module to perform eviction operations on affected Pods, triggering their rescheduling to healthy nodes calculated by the cross-domain collaboration engine, thereby enabling rapid business recovery.

[0089] The edge collaboration optimization module in the control layer described in this embodiment is used to synchronize policies and interact with the microservice SDN control module. At the same time, it synchronizes state data and management configuration data with the lightweight agent running on the edge node, manages the lightweight agent of the edge node, and realizes edge autonomy.

[0090] The construction process and functions of the edge collaborative optimization module are as follows:

[0091] S401, Edge Proxy Deployment and Policy Synchronization.

[0092] On each edge node of the business layer, a lightweight SDN proxy based on eBPF technology is deployed. This proxy maintains heartbeat and policy synchronization with the microservice-based SDN control module of the control layer through the NATS message bus. The control layer distributes the calculated rate limiting and priority policies to the proxy for execution.

[0093] S402, Adaptive Flow Table Optimization.

[0094] The edge agent monitors the CPU utilization of its local node (business layer) in real time.

[0095] When CPU utilization is below the lower threshold, the agent uses fine-grained flow tables to set independent queues and rate-limiting rules for each important business flow.

[0096] When CPU utilization exceeds the upper threshold, the agent automatically initiates merging rules, merging multiple flow entries destined for the same network segment into a single more general entry, and disabling some non-core monitoring functions to reduce CPU overhead and ensure that core data forwarding is not affected.

[0097] Through the above implementation methods, this invention achieves deep integration of SDN and cloud-native technologies at the business layer, control layer, and data layer, solving core problems such as interruption of traditional network architecture upgrades, inefficient cross-domain collaboration, and limited resources in edge scenarios. It can be widely applied to scenarios such as hybrid cloud management, industrial IoT, and smart city networks.

[0098] It should be noted that although system components and data flows are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these components to be arranged in the specific order shown, or requiring all illustrated components to be included in the system. In some cases, the functionality of multiple components may be combined into a single component, or the functionality of a single component may be split into multiple components. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Claims

1. A dynamic control system for SDN networks based on cloud-native architecture, characterized in that, The system includes a business layer, a control layer, and a data layer; The business layer includes a core network, a cloud platform, and edge nodes. The core network and cloud platform are used to send business flow requests, cross-cluster link status, and local resource data to the control layer. Lightweight agents run on the edge nodes to receive and execute the joint resource scheduling policies generated by the control layer, schedule service instances to designated nodes, and report the policy execution effect to the control layer. At the same time, they continuously synchronize and manage the edge agent status with the control layer. The control layer is connected to the business layer and the data layer. It is used to receive business flow requests, cross-cluster link status, local resource data and policy execution effects issued by the business layer, as well as network situation data uploaded by the data layer. It performs unified analysis, decision-making and scheduling, generates network control policies and further converts them into flow table rules and sends them to the data layer. At the same time, it generates joint resource scheduling policies and uploads them to the business layer. The data layer includes SDN switches and routers, which are used to execute flow table rules issued by the control layer, complete packet forwarding, and collect network situation data and upload it to the control layer.

2. The SDN network dynamic control system based on cloud-native architecture according to claim 1, characterized in that, The control layer includes a microservice-based SDN control module, a cross-domain collaboration engine module, an end-to-end quality of service assurance module, and an edge collaboration optimization module. The microservice-based SDN control module receives network status data uploaded from the data layer and service flow requests and cross-cluster link statuses issued by the service layer. It calculates network paths and monitors status by invoking routing algorithms, generates network control policies, and further transforms them into complete flow table rules for distribution to the data layer. It also receives flow table adjustment instructions from the end-to-end quality of service (QoS) assurance module and distributes the necessary local flow table rules to the data layer. Furthermore, it continuously interacts with the edge collaboration optimization module to synchronize status and policies, providing configuration and policy data for lightweight proxy operation on edge nodes. It also transmits traffic monitoring data to the cross-domain collaboration engine module, receives policy iteration and optimization instructions, adjusts transmission policies according to the instructions, and distributes complete flow table rules to the data layer, overwriting existing flow tables. Finally, it gradually captures abnormal network states, including link breaks, topology changes, and network congestion, through traffic monitoring and outputs these network anomalies to the end-to-end QoS assurance module. The cross-domain collaboration engine module is used to receive traffic monitoring data generated by the microservice SDN control module, and integrate multi-domain data such as business flow requests, cross-cluster link status, local resource data and policy execution effect from the business layer to generate a joint resource scheduling policy that integrates routing policies and business scheduling suggestions, and transmits it to the business layer; it is also used to generate policy iteration optimization instructions based on the routing policy and transmit them to the microservice SDN control module to realize transmission policy iteration optimization. The end-to-end quality of service assurance module is used to receive network anomalies monitored by the microservice SDN control module and service flow requests and cross-cluster link status transmitted by the service layer. When a network anomaly occurs, it calculates a new transmission path based on the priority information of the service flow request and the cross-cluster link status, converts it into a flow table adjustment instruction, and sends it to the microservice SDN control module. The edge collaboration optimization module is used to synchronize policies and interact with the microservice-based SDN control module, and to synchronize state data and management configuration data with the lightweight agent running on the edge node, manage the lightweight agent of the edge node, and realize edge autonomy.

3. The SDN network dynamic control system based on cloud-native architecture according to claim 2, characterized in that, The microservice-based SDN control module includes a routing calculation component, a traffic monitoring component, a policy execution component, and an algorithm management component; The routing calculation component is used to obtain network topology data from the traffic monitoring component and cross-cluster link status from the business layer, match routing algorithm plugins according to business flow requests, and call the SDN control algorithm plugin in the algorithm management component to perform path calculation, generate the optimal transmission policy, and output it to the policy execution component. The traffic monitoring component is used to collect network situation data from the data layer through monitoring tools, store it in the database to form a network situation database, provide network topology data for the routing calculation component, and output the monitored latency, bandwidth and feedback data to the cross-domain collaboration engine module. At the same time, it captures network anomalies and transmits them to the end-to-end service quality assurance module. The policy execution component is used to receive the optimal transmission policy from the routing calculation component, the policy iteration optimization instruction from the cross-domain collaboration engine module, and the flow table adjustment instruction from the end-to-end service quality assurance module, convert them into flow table rules and send them to the data layer, and at the same time continuously interact with the edge collaboration optimization module in terms of state and policy synchronization. The algorithm management component is used to obtain SDN control algorithm images from the image repository, perform version management, monitor new version algorithm images and update them on a rolling basis, and match SDN control algorithms for the routing calculation component according to business logistics needs and cross-cluster link status.

4. The SDN network dynamic control system based on cloud-native architecture according to claim 3, characterized in that, The routing calculation component consists of one or more routing algorithm plugins, used to match transmission tasks in different business scenarios; after listening to the new version algorithm image, the algorithm management component starts the new version algorithm container instance, gradually migrates traffic to the new instance through the service mesh, and reclaims the old version container. If the new version algorithm causes performance abnormalities, it automatically triggers the rollback process to restore to the stable version.

5. The SDN network dynamic control system based on cloud-native architecture according to claim 2, characterized in that, The cross-domain collaboration engine module is used for: The system acquires service flow requests carrying QoS parameters, cross-cluster link status data, and policy execution results for historical policies from the core network and cloud platform at the service layer. It also acquires local resource data from edge nodes at the service layer and traffic monitoring data from the traffic monitoring component. The acquired multi-source data is normalized to construct a cross-domain resource scoring model. Based on the scoring model, a joint resource scheduling policy integrating routing policies and container scheduling suggestions is generated. This joint resource scheduling policy is injected into the service layer through a Kubernetes custom resource definition interface. The policy iteration and optimization instructions generated based on the joint resource scheduling policy are transmitted to the policy execution component of the microservice-based SDN control module. Simultaneously, traffic monitoring data from the traffic monitoring component is received for policy optimization.

6. The SDN network dynamic control system based on cloud-native architecture according to claim 2, characterized in that, The end-to-end quality of service assurance module is used for: Service flow requests are obtained from the core network at the service layer and mapped to the DSCP tag field of SDN to mark the priority and quality of service requirements of network traffic, thereby distinguishing different types of service flow requests; Network anomaly data is obtained from the traffic monitoring component. When the latency and packet loss rate exceed the threshold, an alarm is triggered and a fast recovery mechanism is started. A new transmission path is calculated based on the priority of business flow requests, service quality requirements, and cross-cluster link status. The transmission path is converted into a flow table adjustment command and sent to the microservice SDN control module to correct the business flow transmission strategy.

7. A dynamic control system for SDN networks based on a cloud-native architecture according to claim 2, characterized in that, The edge collaborative optimization module is used for: Deploy and manage lightweight proxies for edge nodes in the business layer at the control layer; The network policy is received from the microservice-based SDN control module in the control layer and distributed to the lightweight agent on the edge node for execution. It receives status data and management configuration data collected by the lightweight agent of the edge node and synchronizes them to the microservice SDN control module; The lightweight agent at the edge node dynamically adjusts the granularity of the flow table based on the local resource utilization: when resources meet the demand, the flow table is refined; when resources do not meet the demand, similar flow table entries are merged.

8. The SDN network dynamic control system based on cloud-native architecture according to claim 1, characterized in that, The cluster management tools used in the business layer include Kubernetes K8S, K3s, and KubeEdge; the business layer communicates with the modules within the control layer via the gRPC protocol, and cross-domain service collaboration is achieved through the modules within the control layer; the control layer communicates with the data layer via the OpenFlow protocol.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, performs the functions of the system according to any one of claims 1 to 7.

Images