Dynamic routing scheduling method and system based on service priority in dual stack environment

Abstract

The application discloses a kind of dynamic routing scheduling method and system based on service priority under dual stack environment, belong to software-defined wide area network and network communication technical field.Method includes: preset service priority rule and dual stack adaptation rule;Receive service request and mark service priority label, collect dual stack traffic data, link state and the running state of SRv6 path, predict dual stack traffic variation trend by prediction model;With service priority as core orientation, determine the dual stack routing allocation rule of different priority service, dynamically adjust IPv4 / IPv6 traffic shunt proportion, generate dynamic routing scheduling instruction;Issue instruction to software-defined wide area network controller execution, collect state after scheduling and closed loop adjustment;Link fault is detected, and synchronous fault switching and traffic back are executed according to service priority.The application realizes the differentiated dynamic scheduling and resource collaborative optimization based on service priority under dual stack environment.

Description

Technical Field

[0001] This invention relates to the field of software-defined wide area network (SDN-WAN) and network communication technology, specifically to a dynamic routing scheduling method and system based on service priority in an IPv4 / IPv6 dual-stack environment. Background Technology

[0002] Currently, Software-Defined Wide Area Network (SDN-WAN) technology has been widely deployed in industries such as finance and telecommunications. Meanwhile, with the large-scale advancement of IPv6, the coexistence of IPv4 / IPv6 dual-stack has become a long-term network deployment pattern. Existing technologies have disclosed SDN control schemes for dual-stack environments. These schemes receive service configuration requests from business systems, determine the IP type (IPv4 or IPv6) based on network configuration parameters, generate corresponding network configuration requests, and send them to the target network devices. This solution can complete service configuration distribution in a hybrid IPv4 and IPv6 network environment, meeting basic dual-stack service requirements.

[0003] However, the aforementioned existing technologies still have the following technical defects: First, there is a lack of a differentiated scheduling mechanism driven by service priority. Existing technologies only select routing methods based on traditional routing protocols according to the IP type in the network configuration parameters, without introducing service priority as a core input parameter for scheduling decisions. This makes it impossible to distinguish the differentiated network resource needs of different types of services, resulting in core services with high real-time and high reliability requirements not receiving priority transmission guarantees.

[0004] Second, dual-stack traffic scheduling decisions are based on a single dimension and lack dynamic coordination capabilities. Existing technologies rely primarily on IP type and the support capabilities of target network devices for routing decisions, without comprehensively considering the real-time distribution of dual-stack traffic, the real-time status of links, and future traffic change trends. This makes it impossible to achieve dynamic coordinated scheduling of IPv4 and IPv6 traffic, which can easily lead to congestion on one stack link while the other stack link resources are idle, reducing the overall utilization efficiency of dual-stack network resources.

[0005] In summary, existing dual-stack SDN control schemes have significant shortcomings in terms of service priority adaptation and dual-stack collaborative dynamic scheduling, and there is an urgent need for an improved scheme that can solve the above-mentioned technical problems. Summary of the Invention

[0006] To address the aforementioned issues, this invention provides a dynamic routing and scheduling method and system based on service priority in a dual-stack environment.

[0007] The dynamic routing scheduling method based on service priority in a dual-stack environment provided by this invention includes the following steps: Step S1: System Initialization Configuration It presets financial service priority rules, dual-stack adaptation rules, link status thresholds, and SRv6 path configuration information, presets the initial IPv4 / IPv6 traffic splitting ratio, and associates the business system with the SDN-WAN controller to achieve real-time synchronization of business information. The SRv6 path configuration information includes an SRv6 segment identifier list and path latency thresholds.

[0008] Step S2: Business Priority Identification and Multi-Dimensional Data Collaborative Collection It receives business requests from the business system in real time, identifies the business type and marks the business priority label, and collects the business transmission requirements at the same time. Real-time collection of dual-stack traffic data within the SDN-WAN wide area network, including bandwidth usage, traffic source, and traffic type for IPv4 / IPv6 traffic; Real-time collection of operational status indicators for each WAN link, including link bandwidth utilization, latency, jitter, packet loss rate, dual-stack support status, and link load. Real-time collection of SRv6 path operation status, including path latency and path availability, combined with link status data to form a link-path status database; By combining historical and real-time traffic data, the built-in prediction model can predict the peak and trend of dual-stack traffic in the future within a preset time period.

[0009] Step S3: Multi-dimensional collaborative decision-making to generate dynamic routing and scheduling instructions. The collected business information, dual-stack traffic data, link status data, SRv6 path operation status and traffic prediction results are filtered and integrated to determine whether each link is overloaded or in an abnormal state, and to identify whether the dual-stack traffic distribution is reasonable. Guided by business priority, the system integrates dual-stack traffic distribution, link status, and traffic prediction results to determine the dual-stack routing allocation rules for services with different priorities: core services are prioritized for allocation to link combinations with excellent link quality, perfect dual-stack adaptation, and configured with SRv6 low-latency paths; important services are allocated to link combinations with good link quality and normal dual-stack adaptation; and ordinary services are allocated to the remaining available links. Based on traffic prediction results and link status, dynamically adjust the IPv4 / IPv6 traffic offloading ratio: when it is predicted that the core service traffic of a certain stack will reach its peak and the corresponding link is sufficiently loaded, increase the offloading ratio of the traffic of that stack; when the traffic of a certain stack is overloaded and there is a backup link that supports the protocol, automatically switch some ordinary service traffic to the backup link; when a certain link only supports a single protocol, only allocate ordinary service traffic of the corresponding protocol. Generate dynamic routing scheduling instructions, which include the dual-stack traffic splitting ratio for each service, link allocation results, SRv6 path configuration information, and abnormal traffic handling strategies.

[0010] Step S4: Execution of routing scheduling instructions and real-time feedback adjustment The dynamic routing scheduling command is sent to the SDN-WAN controller. The SDN-WAN controller adjusts the routing strategy of each WAN link based on the path scheduling capability of the SRv6 protocol, allocates dual-stack traffic according to the command requirements, controls the bandwidth occupation of each link, ensures that core business traffic is forwarded first, and restricts or blocks abnormal traffic. Real-time collection of link status, dual-stack traffic distribution, and service transmission status after scheduling execution, with a focus on monitoring transmission indicators of core services; By comparing the differences in indicators before and after scheduling, and combining the traffic prediction results, if it is found that the link is still overloaded, the service transmission indicators are not up to standard, or the dual-stack traffic distribution is unreasonable, the scheduling instructions are immediately adjusted and reissued for execution, forming a closed loop of the entire process of collection-identification-decision-execution-feedback-adjustment.

[0011] Step S5: Link Failure Collaborative Fault Tolerance and Traffic Reversal Real-time detection of fault status of each WAN link and SRv6 path; once a fault is detected, a fault alarm is generated immediately, specifying the fault type, fault link, and scope of impact. Based on the fault alarm and combined with the service priority, a synchronous fault switching instruction is generated: immediately cut off the dual-stack traffic forwarding of the fault link, prioritize the switching of the core service traffic corresponding to the fault link to the backup high-quality link, and adjust the SRv6 path configuration information. Important services and ordinary services traffic are switched in order of priority to ensure that the core service switching latency is controlled within the preset threshold and the dual-stack traffic switching is completed synchronously. Once the faulty link or SRv6 path is restored to normal, confirm that the link status meets the standards, gradually adjust the routing instructions, smoothly switch dual-stack traffic back to the restored link according to service priority, adjust the traffic splitting ratio, and restore the SRv6 low-latency path configuration for core services.

[0012] This invention also provides a dynamic routing and scheduling system based on service priority in a dual-stack environment, used to implement the above method. The system includes: The SDN-WAN controller supports IPv4 / IPv6 dual-stack and SRv6 protocol, and is used to receive and execute dynamic routing scheduling instructions to adjust the routing policy of WAN links and dual-stack traffic allocation. The SDN-WAN controller has a built-in SRv6 forwarding control module, which is used to allocate different SRv6 segment identifiers according to service priority, configure low-latency paths for core services, and configure general paths for ordinary services.

[0013] The service priority management module is deployed between the SDN-WAN controller and the business system. It is used to receive service requests issued by the business system, identify service types and dynamically generate service priority tags, collect service transmission requirements, and upload service information to the dual-stack collaborative scheduling module and the SDN-WAN controller in real time. The service priority management module passively receives service request packets pushed by the business system in real time, and periodically obtains static service data from the service ledger database through active querying.

[0014] The dual-stack collaborative scheduling module, integrated into the SDN-WAN controller, is used to collect dual-stack traffic data in real time. It receives service information uploaded by the service priority management module, link status data uploaded by the link status acquisition module, and traffic prediction results uploaded by the traffic prediction module. Guided by service priority, it performs multi-dimensional collaborative decision-making, generates dynamic routing scheduling instructions, and sends them to the SDN-WAN controller. The dual-stack collaborative scheduling module has a built-in SRv6 path resolution module, which is used to generate the optimal forwarding path based on SRv6 according to service priority and link status.

[0015] The link status acquisition module is deployed at each WAN link node to collect real-time operational status indicators of each link, including link bandwidth utilization, latency, jitter, packet loss rate, dual-stack support status, and link load. The link status data is synchronized in real time to the dual-stack collaborative scheduling module and the SDN-WAN controller. The link status acquisition module adopts a dual detection mechanism that combines link heartbeat detection and traffic anomaly monitoring for fault detection.

[0016] The traffic prediction module has a built-in long short-term memory network prediction model, which is used to collect historical traffic data and real-time traffic data, predict the peak traffic and change trend of dual stack within a preset time period, and upload the prediction results to the dual stack collaborative scheduling module. The prediction results of the traffic prediction module include the prediction time period, the predicted peak traffic of IPv4 / IPv6 stack, the traffic change trend, the prediction accuracy, and the abnormal warning indicator.

[0017] Preferably, the dual-stack collaborative scheduling module adopts a combination of rule-based decision-making system and dynamic weight adjustment for collaborative decision-making, quantifying business priority, link utilization and traffic prediction results into weight factors, and dynamically adjusting the traffic distribution ratio; the dynamic routing scheduling instruction is encapsulated in structured binary format and sent to the SDN-WAN controller in real time via UDP protocol.

[0018] Preferably, the SDN-WAN controller and the dual-stack collaborative scheduling module are deeply integrated through SRv6 path programming: the dual-stack collaborative scheduling module generates a corresponding SRv6 segment identifier list according to the service priority, and sends the segment identifier list as the core parameter of the instruction to the SDN-WAN controller; after parsing the instruction, the SDN-WAN controller binds the service priority label with the corresponding segment identifier list through the SRv6 policy, forming an association relationship from the priority label to the segment identifier list to the forwarding path.

[0019] Preferably, the system further includes a collaborative fault tolerance mechanism: when the link status acquisition module detects a link or SRv6 path failure, the dual-stack collaborative scheduling module generates a collaborative fault switching instruction, and synchronously switches dual-stack traffic to a backup link or backup path according to service priority, controlling the core service switching delay to within 100ms; when the faulty link or path returns to normal, the dual-stack traffic is smoothly switched back.

[0020] Compared with existing technologies, this application constructs an integrated dynamic routing and scheduling system encompassing "business priority identification—multi-dimensional data collection—collaborative decision-making—closed-loop feedback—fault tolerance," achieving the organic integration of differentiated scheduling based on business priorities and multi-dimensional collaborative decision-making in a dual-stack environment. The various technical features of this application are interconnected and mutually supportive, forming a synergistic and efficient overall technical solution. Its beneficial effects are specifically reflected in the following five aspects.

[0021] I. Construct a differentiated scheduling mechanism driven by business priorities to ensure precise transmission of core services. Existing technologies select routing methods based solely on the IP type in network configuration parameters, without incorporating service priority as a core input parameter for scheduling decisions, thus failing to differentiate the varying network resource requirements of different service types.

[0022] This application establishes a business priority management mechanism that receives business requests from the business system in real time, dynamically generates priority tags, and uses business priority as the core guide for scheduling decisions, deeply binding it with dual-stack traffic splitting ratio adjustments, link allocation strategies, and SRv6 path selection. Specifically, differentiated resource allocation rules are determined based on business priority tags: core services are preferentially allocated to link combinations with excellent link quality, good dual-stack adaptation, and configured with low-latency SRv6 paths, while ordinary services are allocated to remaining available links. These technical features transform the resource allocation logic of the scheduling system from "static routing based on protocol type" to "dynamic guarantee based on business priority."

[0023] Therefore, this application achieves precise protection for core service transmission: core services always prioritize the use of high-quality link resources and low-latency SRv6 paths, core service latency can be controlled within 50ms, and transaction success rate is significantly improved; at the same time, service priority is deeply bound to scheduling policy, so that routing policy can be automatically adapted after priority adjustment without manual intervention.

[0024] II. Construct a multi-dimensional collaborative decision-making mechanism to achieve dynamic coordination and resource optimization of dual-stack traffic. The routing decisions of existing technologies mainly rely on IP type and the support capabilities of target network devices, without comprehensively considering the real-time distribution of dual-stack traffic, real-time link status, and future traffic change trends. The decision-making dimensions are too singular, and dynamic collaborative scheduling of IPv4 and IPv6 traffic cannot be achieved.

[0025] This application constructs a multi-dimensional collaborative decision-making system based on "service priority + dual-stack traffic + link status + traffic prediction". These dimensions form an organically coordinated logical chain: service priority serves as the decision guide, determining the priority order of resource allocation; real-time distribution of dual-stack traffic reflects the current network load; link status provides the basis for evaluating the quality of transmission paths; and traffic prediction results provide a forward-looking reference for decision-making, enabling the scheduling system to shift from "passive response" to "proactive pre-adjustment". Simultaneously, this application employs a dynamic weight adjustment algorithm, quantifying the parameters of each dimension into weight factors to achieve real-time dynamic adjustment of the IPv4 / IPv6 traffic offloading ratio.

[0026] Therefore, this application achieves dynamic collaborative scheduling of dual-stack traffic: IPv4 and IPv6 traffic are allocated in a unified collaborative decision-making mechanism; the dual-stack traffic splitting ratio is dynamically adjusted based on real-time status and prediction results; link allocation comprehensively considers multiple dimensions such as latency, packet loss rate, and dual-stack adaptability. The aforementioned collaborative effects significantly improve link resource utilization and effectively reduce the dual-stack traffic forwarding failure rate.

[0027] III. Construct a closed-loop dynamic adjustment mechanism to achieve adaptive optimization of scheduling strategies. Existing technologies adopt a one-way configuration mode of "request-issuance-feedback". After the scheduling instructions are executed, there is a lack of verification and correction mechanism for the execution effect, which makes it impossible to optimize the scheduling strategy in a timely manner.

[0028] This application employs a closed-loop design encompassing "collection—identification—decision-execution—feedback—adjustment" to enable the scheduling system to possess dynamic adaptive capabilities. After a scheduling command is executed, the system collects link status, dual-stack traffic distribution, and service transmission metrics in real time, comparing the differences in metrics before and after scheduling. If an anomaly is detected, the scheduling command is immediately adjusted and reissued for execution. This closed-loop feedback mechanism works in conjunction with a multi-dimensional collaborative decision-making mechanism. The feedback data is not only used to correct the current scheduling but also serves as input for optimizing the traffic prediction model, forming an iterative evolution chain of "prediction—decision-execution—feedback—optimization."

[0029] Therefore, this application achieves adaptive optimization of the scheduling strategy: automatically adjusts the routing strategy when the link status changes; automatically corrects the traffic splitting ratio when the traffic distribution deviates from the expectation; and automatically switches links or adjusts path parameters when the service transmission indicators fail to meet the standards, thus avoiding the attenuation of scheduling effect caused by static configuration.

[0030] IV. Construct a collaborative fault-tolerance mechanism based on business priorities to achieve high system availability. Existing technologies do not have differentiated fault switching strategies based on service priorities for link failure scenarios, and the fault switching of dual-stack traffic is independent of each other, which can easily lead to the problem of asynchronous switching.

[0031] This application establishes a collaborative fault tolerance mechanism based on service priorities, forming an integrated linkage with the priority-driven scheduling mechanism. When a link or SRv6 path fails, the system generates a collaborative fault switching instruction based on service priorities: core service traffic is preferentially switched to a backup high-quality link, while important and ordinary services are switched sequentially according to priority, ensuring that the switching latency of core services is controlled within 100ms; dual-stack traffic is switched synchronously to avoid service interruption caused by asynchronous protocol switching. After fault recovery, the system smoothly switches back traffic according to priority and restores the SRv6 low-latency path configuration for core services. The above fault tolerance mechanism and multi-dimensional collaborative decision-making share the same priority guidance and link status data source, ensuring that the fault switching decision logic is consistent with the normal scheduling logic.

[0032] Therefore, this application achieves high availability assurance for the system: the core business fault switching latency is controlled within 100ms; dual-stack traffic synchronous switching avoids business interruption; and smooth back-switch after fault recovery avoids link overload during the back-switch process.

[0033] V. Synergistic Effect of Various Technical Features The aforementioned technical features of this application are not isolated, but are interconnected and mutually supportive, forming a complete technical system integrating "guidance, decision-making, protection, and optimization".

[0034] First, the business priority-driven mechanism provides core guidance for multi-dimensional collaborative decision-making. Priority labels directly influence the weight factors in the dynamic weight adjustment algorithm, ensuring that decision results always revolve around the goal of ensuring core business operations. Second, multi-dimensional collaborative decision-making provides a basis for closed-loop feedback adjustments. Execution results are fed back to the decision-making module through closed-loop feedback to correct the weight parameters and judgment thresholds for subsequent decisions. Third, traffic prediction and dynamic weight adjustment work together. Prediction results provide a forward-looking basis for weight adjustments, while actual traffic data is fed back to the prediction model for optimization, forming a closed loop. Fourth, the collaborative fault tolerance mechanism and the priority-driven mechanism are integrated and linked. Fault switching decisions and normal scheduling decisions share the same priority guidance, ensuring that core businesses still receive sufficient resource guarantees during fault periods.

[0035] In summary, this application achieves a comprehensive technological upgrade from normal scheduling to fault tolerance, from passive response to proactive prediction, and from static configuration to dynamic optimization through the organic synergy of the aforementioned technical features. The overall technical effect is significantly better than the sum of the effects produced by the individual superposition of each feature, demonstrating outstanding substantive characteristics and significant progress. Attached Figure Description

[0036] Figure 1 This is an overall flowchart of the method in Embodiment 1 of this application; Figure 2 This is a flowchart of the "Business Priority Identification and Multi-Dimensional Data Acquisition" sub-process in the method of Embodiment 1 of this application; Figure 3 This is a flowchart of the "multi-dimensional collaborative decision-making and dynamic routing scheduling instruction generation" sub-process in the method of Embodiment 1 of this application; Figure 4 This is a flowchart of the "link failure collaborative fault tolerance and traffic backhaul" sub-process in the method of Embodiment 1 of this application; Figure 5 This is an overall architecture diagram of the system in Embodiment 2 of this application; Figure 6 This is a diagram showing the internal structure of the capability layer of the system in Embodiment 2 of this application; Figure 7 This is a diagram showing the inter-module communication and data interaction of the system in Embodiment 2 of this application. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings and specific embodiments. The described embodiments are merely some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0038] Definitions: To facilitate understanding of the technical solution of this application, the following terms are defined and explained: Dual Stack: refers to a network device or link that simultaneously supports the IPv4 protocol stack and the IPv6 protocol stack, and can handle the forwarding of packets of both IPv4 and IPv6 protocol types respectively.

[0039] SDN-WAN (Software Defined Wide Area Network): This technology is applied to wide area network scenarios to separate the control plane from the forwarding plane, and to manage and dynamically schedule wide area network links through a centralized controller.

[0040] SRv6 (Segment Routingover IPv6): A segmented routing technology based on the IPv6 forwarding plane. It specifies the forwarding path of packets in a source routing manner by embedding a Segment Routing Header (SRH) in IPv6 packets.

[0041] SID (Segment Identifier): A 128-bit identifier used in SRv6 technology to identify network nodes, links, or functions. It adopts the IPv6 address format and is the basic unit for constructing segmented routing paths.

[0042] Business Priority Labels: This application defines labels for identifying the priority level of financial business, which are divided into four levels: P1, P2, P3, and P4, with P1 being the highest priority and P4 being the lowest priority.

[0043] Dual-stack collaborative scheduling: The scheduling mechanism defined in this application refers to the SDN-WAN controller uniformly collecting, jointly deciding, and collaboratively allocating traffic for both IPv4 and IPv6 protocol stacks, rather than processing them independently.

[0044] Dynamic traffic splitting ratio: This application defines a scheduling parameter that refers to the ratio of IPv4 traffic to IPv6 traffic in the total traffic. This ratio can be dynamically adjusted in real time based on link status, service priority, and traffic prediction results.

[0045] Example 1 This embodiment provides a dynamic routing scheduling method based on service priority in a dual-stack environment, using a cross-regional SDN-WAN deployment scenario of a bank as an example. This scenario includes the head office data center, branch core computer rooms, and multiple branch outlets. The nodes are interconnected via WAN links (including core leased lines and backup internet leased lines), and all links support IPv4 / IPv6 dual-stack and SRv6 protocols.

[0046] The complete process of the method in this embodiment can be referred to Figure 1 This flowchart presents the entire implementation logic of this application, highlighting three core aspects: "dual-stack collaboration," "business priority," and "SRv6 adaptation." From system deployment and multi-dimensional data collection to collaborative decision-making, command execution, and real-time feedback adjustment and fault tolerance, a complete dynamic routing and scheduling closed loop is formed.

[0047] I. Explanation of Terms and Definitions Before describing this embodiment in detail, the following key terms are defined: (1) Business priority label: In this embodiment, financial business is divided into four levels: P1 (highest priority, such as cross-regional large-amount transfer, real-time payment), P2 (medium-high priority, such as ordinary transfer, redemption of wealth management products), P3 (medium priority, such as batch reconciliation, report generation), and P4 (low priority, such as log backup, system maintenance).

[0048] (2) Link status thresholds: preset boundary values ​​of link operation indicators, including latency (P1 level services ≤30ms, P2 level ≤50ms, P3 / P4 level ≤100ms), packet loss rate (P1 / P2 level ≤0.1%, P3 / P4 level ≤1%), and bandwidth utilization (core link ≤75%, ordinary link ≤90%).

[0049] (3) SRv6 path types: including low latency path (assigned to core business, latency ≤ 30ms), general path (assigned to important business, latency ≤ 50ms) and fault-tolerant path (assigned to ordinary business, latency ≤ 100ms).

[0050] (4) Dual-stack traffic splitting ratio: refers to the distribution ratio of IPv4 traffic and IPv6 traffic in the total traffic. The default initial ratio is IPv4:IPv6=4:6, which can be dynamically adjusted according to the real-time status.

[0051] II. System Architecture Deployment and Initial Configuration First, a complete scheduling system architecture is deployed in the bank's SDN-WAN wide area network environment. Specifically, an SDN-WAN controller is deployed in the branch's core computer room. This controller supports IPv4 / IPv6 dual-stack and SRv6 protocols and is responsible for centralized management and path scheduling of WAN links. A business priority management component is deployed next to the core transaction system for real-time synchronization of business information such as cross-regional transfers and real-time payments. Dual-stack collaborative scheduling functionality is integrated into the SDN-WAN controller. Link status acquisition components are deployed at the WAN access nodes of each branch. A traffic prediction component is deployed, connecting to the bank's traffic database for the past three months, focusing on collecting core business traffic data during special periods such as paydays and year-end settlements. All components communicate with each other via RESTful API interfaces to ensure real-time synchronous transmission of commands and data.

[0052] Secondly, perform initial configuration operations. The business priority management component presets financial business priority rules: large cross-regional transfers (single transaction amount ≥ 50,000 RMB), real-time payments, and core transaction linkage between branches and sub-branches are classified as P1-level core businesses; ordinary cross-regional transfers (single transaction amount < 50,000 RMB) and cross-regional redemption of wealth management products are classified as P2-level important businesses; branch office document transfers, data backups, and remote employee work are classified as P3-level ordinary businesses. The dual-stack collaborative scheduling component presets dual-stack adaptation rules, clarifying the dual-stack support type (whether it simultaneously supports IPv4 and IPv6) and bandwidth limits for each WAN link, configuring the initial traffic splitting ratio of IPv4 and IPv6 to 4:6. The SDN-WAN controller presets link status thresholds, specifically including: latency not exceeding 50ms, packet loss rate not exceeding 0.1%, and bandwidth utilization not exceeding 75%. SRv6 path planning parameters are configured, allocating low-latency path SIDs (path latency ≤ 30ms) for core businesses and general SIDs (path latency ≤ 100ms) for ordinary businesses. Finally, the associated business system and SDN-WAN controller are used to achieve real-time synchronization of information such as business type and business traffic.

[0053] III. Business Priority Identification and Multi-Dimensional Data Collection After initial configuration is complete, the system enters the real-time operation phase. See the detailed process below. Figure 2 : First, the business priority management component receives business requests from the bank's core business system in real time. When a large cross-regional transfer transaction (transaction amount 5 million yuan, processing time limit 10 seconds) is initiated from a branch, the business priority management component identifies the business type as "real-time large-amount transfer." Combining the transaction amount and processing time limit, and according to the preset mapping rules (transaction amount ≥ 1 million yuan and processing time ≤ 10 seconds are mapped to P1 level), it dynamically generates a priority label "P1," and simultaneously collects the transmission requirements of the business (latency requirement ≤ 50ms, no packet loss). The above business information (business ID, priority label, transmission requirements) is uploaded in real time to the dual-stack collaborative scheduling component and the SDN-WAN controller.

[0054] The business priority management component employs a combination of "active query + passive reception" to acquire business data. Specifically, financial business request messages are received passively; when various financial business terminals initiate business requests, they are automatically pushed to the component's message receiving interface. This interface uses the TCP protocol to listen, ensuring real-time and lossless message reception. The financial business ledger database uses an active query approach. The component has a built-in database query interface that actively accesses the ledger database at preset intervals (every 5 minutes), extracting basic business attribute data using SQL statements. A caching mechanism is also in place to reduce the pressure on the database from repeated queries. Real-time transaction log streams are received passively, connecting to log collection nodes on the SDN-WAN network. These nodes collect dynamic logs during business transactions in real time and push them to the component's log receiving port via streaming.

[0055] The specific mapping rules for business priorities from identification to priority tag generation are as follows: a three-dimensional mapping rule of "business type + business attribute + processing time limit" is adopted. "Real-time transfer, large-amount payment business (business type), transaction amount ≥ 1 million yuan (business attribute), processing time limit ≤ 10 seconds (processing time limit)" is mapped to "P1 (highest priority)"; "Ordinary transfer, account inquiry business (business type), transaction amount 1-1 million yuan (business attribute), processing time limit ≤ 30 seconds (processing time limit)" is mapped to "P2 (medium-high priority)"; "Batch reconciliation, report generation business (business type), no real-time transaction amount (business attribute), processing time limit ≤ 10 minutes (processing time limit)" is mapped to "P3 (medium priority)"; "Log backup, system maintenance related business (business type), no real-time business data (business attribute), no mandatory processing time limit (processing time limit)" is mapped to "P4 (low priority)". The above mapping rules exist in a dual form of "configurable XML configuration file + database storage", supporting online modification and dynamic updates by technical personnel.

[0056] Meanwhile, the dual-stack collaborative scheduling component collects all dual-stack traffic data within the SDN-WAN wide area network in real time. The collection frequency is once per second, and the collected content includes bandwidth usage of IPv4 and IPv6 traffic, traffic source (identification of each branch and outlet), and traffic type (corresponding service priority). When abnormal traffic is detected (such as a sudden increase in traffic or traffic from an unknown IP address), it is marked and uploaded to the SDN-WAN controller for subsequent scheduling decisions.

[0057] The link status acquisition component collects operational status metrics for each WAN link in real time, at a frequency of once per second. The collected metrics include: link bandwidth utilization (percentage), link latency (milliseconds), link jitter (milliseconds), packet loss rate (percentage), dual-stack support status (whether it simultaneously supports IPv4 and IPv6), and link load status (light load / normal / heavy load). The SDN-WAN controller collects the operational status of SRv6 paths in real time, including path latency and path availability, and combines this with the link status data to form a complete "link-path status database," which is synchronized to the dual-stack collaborative scheduling component in real time.

[0058] The traffic prediction component combines historical and real-time traffic data, using an LSTM prediction model to predict peak and trend changes in dual-stack traffic over the next 5-10 minutes. The input feature vector of the LSTM model employs multi-dimensional time-series features, comprising 12 specific dimensions: real-time traffic rate of the IPv4 stack, real-time traffic rate of the IPv6 stack, IPv4 stack traffic fluctuation value, IPv6 stack traffic fluctuation value, core link bandwidth utilization, average link latency, link jitter value, link failure frequency, proportion of high-priority service traffic, service initiation frequency, service type distribution proportion, and historical concurrent traffic coefficient. Historical data for these 12 dimensions are collected in 1-minute time steps, forming a continuous time-series dataset. The training data covers 180 days of continuous operation data, totaling approximately 2.592 million records, with 80% used for model training, 10% for model validation, and 10% for model testing. The prediction results are output in a standardized JSON format, including the prediction time period (future 10 minutes, 30 minutes, 1 hour), the predicted peak traffic for IPv4 / IPv6 stacks, the traffic trend (increasing / decreasing / stable), the prediction accuracy, and anomaly warning indicators (0 = no anomaly, 1 = traffic surge warning, 2 = traffic drop warning). The prediction results are pushed to the dual-stack collaborative scheduling component in real time.

[0059] The dual-stack collaborative scheduling component feeds back the actual traffic data after the decision is executed to the traffic prediction component for periodic fine-tuning of the model.

[0060] It should be noted that since the execution of the scheduling strategy will change the original dual-stack traffic distribution, directly using the actual traffic data after scheduling for the prediction model feedback may lead to logical loops. Therefore, this system employs the following mechanism to ensure the rationality of the feedback: (1) Baseline traffic separation: When training and fine-tuning, the traffic prediction module uses the original traffic data before the scheduling strategy takes effect and the residual prediction bias that has not been completely eliminated by the scheduling strategy, rather than the traffic data after it has been completely intervened.

[0061] (2) Dual-model architecture: The system has two built-in models - a natural flow prediction model (predicting the original flow trend without scheduling intervention) and a scheduling effect evaluation model (evaluating the actual impact of scheduling strategies on flow distribution). The feedback data of the natural flow prediction model comes from the flow records of the same period in history with no scheduling or light scheduling.

[0062] (3) Deviation attribution analysis: When the deviation between the actual flow and the prediction result exceeds 15%, the system first determines whether the deviation is caused by the execution of the scheduling strategy or by the error of the prediction model itself. Only when it is confirmed that the error is due to the model itself will the fine-tuning of the model parameters be triggered.

[0063] Through the above mechanism, this system achieves a reasonable closed loop of "prediction-decision-execution-feedback-optimization", avoiding the logical interference of scheduling intervention on the training of prediction models.

[0064] IV. Multi-dimensional collaborative decision-making and dynamic routing scheduling instruction generation See Figure 3 After receiving the collected service information, dual-stack traffic data, link status data, SRv6 path operation status, and traffic prediction results, the dual-stack collaborative scheduling component first verifies the validity of the data, removing abnormal data with missing core fields, incorrect format, or values ​​exceeding reasonable ranges. Incomplete data is then interpolated based on historical data from the same period. After filtering valid data, it compares it with preset link status thresholds to determine whether each link is overloaded or in an abnormal state (e.g., latency exceeding 50ms, packet loss rate exceeding 0.1%, bandwidth utilization exceeding 75%). Simultaneously, it determines whether the dual-stack traffic distribution is reasonable. For example, if a link has over 90% IPv6 traffic and is overloaded, while the backup link's IPv6 traffic is idle, then the dual-stack traffic distribution is identified as unreasonable.

[0065] Next, guided by service priority, the dual-stack traffic distribution, link status, and traffic prediction results are integrated to determine the dual-stack routing allocation rules for services of different priorities. The specific rules are as follows: (1) For P1 level core services: Priority will be given to link combinations with excellent link quality (latency ≤30ms, packet loss rate ≤0.05%, bandwidth utilization ≤70%), good dual-stack adaptation (supporting both IPv4 and IPv6 with balanced dual-stack performance) and configured with SRv6 low-latency paths. If the dedicated high-speed link is unavailable, the service will be assigned to the best link among the backup links that meets the conditions, and a link alarm will be triggered.

[0066] (2) For P2 level important services: allocate links with good link quality (latency ≤ 50ms, packet loss rate ≤ 0.1%, bandwidth utilization ≤ 80%) and normal dual-stack adaptation, and give priority to the links corresponding to the IPv6 stack.

[0067] (3) For P3 level ordinary services: they are allocated to the remaining available links, and the dual-stack traffic ratio can be flexibly adjusted to avoid occupying core link resources and to be evenly allocated to the links corresponding to IPv4 and IPv6.

[0068] (4) For P4-level low-priority services: there are no strict latency requirements, they are allocated to idle links (bandwidth utilization ≤ 50%), and idle link resources are used first to reduce the overall link load.

[0069] The dual-stack collaborative scheduling component dynamically adjusts the IPv4 / IPv6 traffic offloading ratio by combining traffic prediction results and link status. The dynamic weight adjustment algorithm introduces three core weight factors: service priority weight (P1=0.4, P2=0.3, P3=0.2, P4=0.1), link utilization weight (weight = 0.2 when bandwidth utilization < 60%, weight = 0.5 when 60%-80%, weight = 0.8 when > 80%), and traffic prediction weight (weight = 0.6 when predicted traffic growth ≥ 50%, weight = 0.4 when 30%-50%, weight = 0.2 when < 30%). The final offloading ratio is calculated as follows: Final offloading ratio = (service priority weight × service traffic percentage) + (link utilization weight × stack bandwidth margin) + (traffic prediction weight × prediction adjustment coefficient). The specific decision logic is as follows: (1) When the traffic of high priority services (P1, P2) accounts for more than 60%, and the bandwidth utilization of IPv4 stack exceeds 80% and the bandwidth utilization of IPv6 stack does not exceed 50%, the following actions are taken: the proportion of high priority services diverted to IPv6 stack is increased by 20%-30%, and the proportion of low priority services diverted to IPv4 stack is increased by 10%-20%.

[0070] (2) When the proportion of high-priority service traffic is less than 40%, and the bandwidth utilization of IPv4 stack does not exceed 60% and the bandwidth utilization of IPv6 stack exceeds 70%, the action to be performed is to increase the proportion of low-priority services diverted to IPv4 stack by 20%-30%, while maintaining the original diversion ratio of high-priority services.

[0071] (3) When the traffic prediction results show that the traffic of a certain stack will increase by more than 50% in the next 30 minutes, take the following action: divert the low priority services on that stack to another stack by 10%-20% in advance to avoid link congestion caused by traffic peaks.

[0072] (4) When the bandwidth utilization of both stacks is between 60% and 80% and the service priority distribution is balanced, the action to be performed is to maintain the original traffic splitting ratio (default IPv4:IPv6=5:5) and make minor adjustments (±5%) every 5 minutes based on real-time traffic changes.

[0073] When the IPv6 core service traffic is predicted to reach its peak and the corresponding high-quality links are sufficiently loaded, the IPv6 traffic offloading ratio should be appropriately increased; when a link is overloaded with IPv4 traffic and there is a backup link that supports IPv4, some IPv4 ordinary service traffic should be automatically switched to the backup link; when a link only supports a single protocol (such as only supporting IPv4), only ordinary service traffic of the corresponding protocol should be allocated to avoid traffic forwarding failure.

[0074] Based on collaborative decision-making results and leveraging the advantages of the SRv6 protocol, the SDN-WAN controller allocates differentiated forwarding paths to services of different priorities. The specific implementation is as follows: For IPv6 traffic of P1-level core services, low-latency SRv6 policy paths are directly allocated (path latency ≤ 30ms); for IPv4 traffic of P1-level core services, the system uses IPv4 over IPv6 tunneling technology (such as SRv6 over IPv4 or MPLS over SRv6) to carry it on a low-latency path of the same quality level, ensuring that dual-stack traffic receives consistent transmission quality assurance.

[0075] Similarly, P2-level services (IPv6 stack) are allocated medium-latency SRv6 paths (≤50ms), and their IPv4 traffic is mapped to the corresponding quality path through tunnels; P3 and P4-level services are allocated general SRv6 paths (≤100ms), and both stack traffic is forwarded in the default manner.

[0076] The above mechanism ensures consistency in service priority orientation, so that services with the same priority can receive equal transmission quality guarantees regardless of whether the traffic type is IPv4 or IPv6.

[0077] The dual-stack collaborative scheduling component transforms the decision results into dynamic routing scheduling instructions and sends them to the SDN-WAN controller. Each instruction contains the following core information: instruction identifier (unique ID), service-related information (service ID, service priority label, service data transmission volume), dual-stack traffic splitting information (IPv4 / IPv6 target splitting ratio, splitting adjustment range, adjustment time), link allocation information (target link identifier, link type, link bandwidth limit), execution requirements (immediate execution / scheduled execution, execution timeout threshold), and verification information (checksum, instruction generation timestamp).

[0078] V. Execution of Routing Scheduling Commands and Real-time Feedback Adjustment After receiving dynamic routing scheduling instructions, the SDN-WAN controller adjusts the routing policies of each WAN link based on the path scheduling capabilities of the SRv6 protocol. The controller allocates dual-stack traffic according to the instructions, controls bandwidth usage on each link, and ensures that core service traffic is prioritized. Specifically, the controller modifies the access control lists and forwarding policies of the SRv6 forwarding devices to forward service traffic of different protocols (IPv4 / IPv6) and priorities to the corresponding SRv6 paths according to the required distribution ratio. Simultaneously, abnormal traffic is restricted or blocked to avoid affecting normal service transmission.

[0079] After the scheduling command is executed, the link status acquisition component and the dual-stack collaborative scheduling component collect the link status, dual-stack traffic distribution, and service transmission status in real time. Key monitoring focuses on transmission metrics for core services, including service latency, transaction success rate, and packet loss rate. This data is uploaded in real time to the dual-stack collaborative scheduling component and the SDN-WAN controller. If issues such as excessive core service latency (exceeding 50ms), link overload (bandwidth utilization exceeding 75%), or unreasonable dual-stack traffic distribution occur, a feedback mechanism is immediately triggered.

[0080] The dual-stack collaborative scheduling component compares the differences in metrics before and after scheduling and analyzes them in conjunction with traffic prediction results. If it finds that a link is still overloaded, a certain type of service transmission metric is not up to standard, or the dual-stack traffic distribution is unreasonable, it immediately adjusts the scheduling instructions (such as adjusting the traffic splitting ratio, switching links, and optimizing SRv6 paths) and reissues them to the SDN-WAN controller for execution. This forms a closed-loop process of "collection-identification-decision-execution-feedback-adjustment" to ensure the dynamic adaptability of routing scheduling.

[0081] VI. Collaborative Fault Tolerance and Traffic Reversal for Link Failures See Figure 4The link status acquisition component monitors the fault status of each WAN link and SRv6 path in real time. It adopts a dual detection mechanism of "link heartbeat detection + traffic anomaly monitoring": the link heartbeat detection sends a heartbeat packet to each link every 10ms. If no response is received for 3 consecutive times (i.e., within 30ms), it is determined to be a link fault; the traffic anomaly monitoring monitors the packet loss rate and latency changes of dual-stack traffic in real time. If the packet loss rate of P1 and P2 level services suddenly exceeds 1% or the latency suddenly increases by more than 20ms, a fault warning is immediately triggered.

[0082] Once a fault is detected (such as link interruption, latency spike to over 100ms, packet loss rate exceeding the standard, or path unavailability), the link status acquisition component immediately sends a fault alarm to the dual-stack collaborative scheduling component and the SDN-WAN controller, specifying the fault type, faulty link, and scope of impact (such as a core link interruption affecting cross-regional core transactions).

[0083] Upon receiving a fault alarm, the dual-stack collaborative scheduling component generates a synchronous fault switching command based on service priorities. The SDN-WAN controller immediately disconnects the dual-stack traffic forwarding of the faulty link, prioritizes switching the core service traffic corresponding to the faulty link to the backup high-quality link, and adjusts the SRv6 path configuration information. Important service and ordinary service traffic are switched sequentially according to priority. The dual-stack collaborative scheduling component has a built-in "fault pre-decision cache library" that pre-stores the optimal switching strategies corresponding to various fault scenarios. When a fault occurs, there is no need to recalculate the decision; the corresponding strategy is directly called from the cache library, ensuring that the core service switching latency is controlled within 100ms, and the dual-stack traffic switching is completed synchronously, avoiding transaction interruption.

[0084] Once the faulty link or SRv6 path returns to normal, the link status acquisition component confirms that the link status meets the standards (latency, packet loss rate, bandwidth utilization, and other indicators meet preset thresholds). The dual-stack collaborative scheduling component gradually adjusts routing instructions, smoothly switching dual-stack traffic back to the restored link according to service priority, adjusting the traffic splitting ratio to avoid link overload during the switchback process and ensure a smooth transition of service transmission. Simultaneously, the SRv6 path configuration is optimized to restore low-latency transmission for core services.

[0085] VII. Actual Operation Results During the year-end settlement peak period, the traffic prediction component predicts that IPv6 core service traffic will reach its peak (accounting for 75% of total traffic) in the next 10 minutes. The dual-stack collaborative scheduling component immediately adjusts the dual-stack traffic splitting ratio to IPv4:IPv6=3:7, allocating core service traffic to two core leased lines (latency approximately 25ms, packet loss rate approximately 0.05%), forwarding it via the SRv6 low-latency path; ordinary service traffic is allocated to a backup internet leased line to avoid consuming core link resources. When one of the core leased lines suddenly fails (latency suddenly rises to over 100ms), the link status acquisition component immediately sends an alarm, and the dual-stack collaborative scheduling component synchronously triggers a failover, switching the dual-stack core service traffic of that link to the other core leased line. The failover latency is controlled within 80ms, better than the preset 100ms threshold, with no interruption or packet loss in core transactions, and the transaction response time remains within 40ms. Based on actual deployment and testing, the latency of core business operations is reduced by approximately 35% compared to existing technologies, the transaction success rate is increased to over 99.99%, the link resource utilization rate is increased by approximately 30%, and the dual-stack traffic conflict rate is reduced to below 0.01%.

[0086] Example 2 This embodiment provides a dynamic routing and scheduling system based on service priority in a dual-stack environment, used to implement the method described in Embodiment 1. The overall architecture of this system is as follows: Figure 5 As shown, the internal structure of the capability layer is as follows: Figure 6 As shown, inter-module communication and data interaction are as follows: Figure 7 As shown.

[0087] I. System Overall Architecture This system adopts a four-layer architecture, from top to bottom: Northbound Interface Layer, Business Layer, Capability Layer, and Control Layer.

[0088] The northbound interface layer is used to receive calls from business systems and return configuration result messages to business systems. It is implemented using a RESTful API interface and is called via URL. It has strong scalability and clear logic.

[0089] The service layer is used to analyze and process the network configuration parameters of the service system received from the northbound interface layer, including IP type, CE side address, peer PE address, bandwidth rate, QoS parameters, etc.

[0090] The capability layer includes units that support routing management using both IPv4 and IPv6 technology stacks, and is the core functional layer of this system.

[0091] The control layer is used to control the network devices southbound of the SDN control system, including issuing configuration information, collecting topology information, routing information, TE information, SRv6 information, etc.

[0092] II. Core Module Composition This system includes the following core modules: (a) SDN-WAN Controller The SDN-WAN controller supports IPv4 / IPv6 dual-stack and SRv6 protocols. Deployed in the branch's core computer room, it manages all WAN links (including core leased lines and backup internet leased lines). The SDN-WAN controller has a built-in SRv6 forwarding control module, used to allocate different SRv6 segment identifiers (SIDs) based on service priority, configuring low-latency paths for core services and general paths for ordinary services. The SDN-WAN controller is responsible for receiving and executing dynamic routing scheduling commands, adjusting the routing policies and dual-stack traffic allocation of WAN links.

[0093] (II) Business Priority Management Module The business priority management module is deployed between the SDN-WAN controller and the bank's core business system. It is used to receive business requests issued by the business system, identify the business type and dynamically generate business priority labels (P1 to P4), collect business transmission requirements, and upload business information to the dual-stack collaborative scheduling module and the SDN-WAN controller in real time.

[0094] The business priority management module employs a combination of "active query + passive reception" to acquire business data. Specifically, financial business request messages are received passively; they are automatically pushed to the module's message receiving interface when various financial business terminals initiate business requests. This interface uses the TCP protocol for listening. The financial business ledger database is accessed actively; the module has a built-in database query interface that actively accesses the ledger database at preset intervals (default every 5 minutes), extracting basic business attribute data using SQL statements, while simultaneously establishing a caching mechanism. The real-time transaction log stream is received passively, connecting to the log collection nodes of the SDN-WAN network.

[0095] The mapping rule from business priority identification to priority tag generation adopts a three-dimensional mapping rule of "business type + business attribute + processing time limit", which exists in a dual form of "configurable XML configuration file + database storage". After the module completes the data source collection, it parses the business data, extracts core features such as business type, transaction amount, and processing time limit, first calls the basic mapping rule in the XML configuration file for preliminary matching to generate temporary priority tags, and then calls the dynamic mapping rule in the database to verify and correct the temporary tags. After the verification is successful, the final priority tag is generated, and the tag is associated with the core data of the business and stored, and at the same time pushed to the dual-stack collaborative scheduling module.

[0096] (III) Dual-stack Cooperative Scheduling Module The dual-stack collaborative scheduling module is integrated within the SDN-WAN controller. It is used to collect dual-stack traffic data in real time (once per second), receiving service information uploaded by the service priority management module, link status data uploaded by the link status acquisition module, and traffic prediction results uploaded by the traffic prediction module. This module performs multi-dimensional collaborative decision-making based on service priority, generates dynamic routing scheduling instructions, and sends them to the SDN-WAN controller.

[0097] The dual-stack collaborative scheduling module incorporates an SRv6 path resolution module to generate optimal SRv6-based forwarding paths according to service priority and link status. The module employs a combination of a rule-based decision-making system and dynamic weight adjustment for collaborative decision-making, quantifying service priority, link utilization, and traffic prediction results into weight factors to dynamically adjust the traffic distribution ratio. Dynamic routing scheduling commands are encapsulated in a structured binary format and sent to the SDN-WAN controller in real time via UDP protocol.

[0098] After receiving multiple types of data, the dual-stack collaborative scheduling module performs comprehensive processing according to a four-level process: data verification, classification and parsing, association and integration, and standardized storage. The data verification stage removes abnormal data and completes incomplete data. The classification and parsing stage extracts the core features of each type of data. The association and integration stage uses a "business ID as the core index" association method to establish a four-dimensional association model of "business - dual-stack traffic - link status - traffic prediction". The standardized storage stage standardizes the integrated decision data records according to JSON format and stores them in the module's built-in decision data cache.

[0099] (iv) Link Status Acquisition Module The link status acquisition module is deployed at each WAN link node (WAN access node of each branch) to collect real-time operational status indicators of each link, including link bandwidth utilization, latency, jitter, packet loss rate, dual-stack support status, and link load. The acquisition frequency is once per second, and the link status data is synchronized in real time to the dual-stack collaborative scheduling module and the SDN-WAN controller.

[0100] The link status acquisition module employs a dual detection mechanism combining link heartbeat detection and traffic anomaly monitoring for fault detection. Link heartbeat detection sends a heartbeat packet to each link every 10ms; if no response is received after three consecutive heartbeats, the link is considered faulty. Traffic anomaly monitoring tracks packet loss rate and latency changes in dual-stack traffic in real time.

[0101] (v) Traffic Prediction Module The traffic prediction module has a built-in LSTM (Long Short-Term Memory) prediction model, which is used to collect historical and real-time traffic data, predict the peak traffic and trend of dual-stack traffic in the next preset time period (10 minutes, 30 minutes, 1 hour), and upload the prediction results to the dual-stack collaborative scheduling module.

[0102] The input feature vector of the LSTM model adopts multi-dimensional time series features, including 12 specific dimensions: real-time traffic rate of IPv4 stack, real-time traffic rate of IPv6 stack, traffic fluctuation value of IPv4 stack, traffic fluctuation value of IPv6 stack, core link bandwidth utilization, average link latency, link jitter value, link failure frequency, proportion of high-priority service traffic, frequency of service initiation, distribution proportion of service type, and historical traffic coefficient for the same period. The training data covers 180 days of continuous operation data, with a total data volume of approximately 2.592 million records, of which 80% is used for model training, 10% for model validation, and 10% for model testing.

[0103] The prediction results are output in a standardized JSON format, including the prediction period, peak traffic volume for both IPv4 and IPv6 stacks, traffic trend, prediction accuracy, and anomaly warning indicators (0 = no anomaly, 1 = traffic surge warning, 2 = traffic drop warning). The prediction results are pushed to the dual-stack collaborative scheduling module in real time and stored in the prediction result database.

[0104] III. Inter-module communication and interface definition The core data interactions between the components of this system are all implemented through RESTful API interfaces. The definitions of the three core interfaces are as follows: (1) Business Priority Tag Push Interface (Business Priority Management Module → Dual-Stack Collaborative Scheduling Module): URI is / api / sdn-wan / business / priority / push, using the POST method. The request body includes businessId (unique business identifier), priorityTag (priority tags P1-P4), businessType (business type), dataVolume (business data transmission volume), createTime (tag generation time), and isEffective (tag validity status). The response body includes code (response status code), message (response prompt information), receiveTime (receive time), and businessId (associated business ID).

[0105] (2) Traffic Prediction Result Push Interface (Traffic Prediction Module → Dual-Stack Cooperative Scheduling Module): URI is / api / sdn-wan / traffic / prediction / push, using the POST method. The request body includes predictionId (unique identifier for the prediction result), predictTime (time when the prediction result is generated), predictPeriod (prediction period), ipv4Peak (peak traffic prediction value for the IPv4 stack), ipv6Peak (peak traffic prediction value for the IPv6 stack), trend (traffic change trend), accuracy (prediction accuracy), and warningFlag (anomaly warning flag). The response body includes code, message, predictionId, and isAccepted (whether the prediction result is accepted).

[0106] (3) Dynamic routing scheduling command query interface (SDN-WAN controller → dual-stack collaborative scheduling module): The URI is / api / sdn-wan / scheduling / command / query / {commandId}, using the GET method. The response body includes commandId, commandType (command type), businessId, priorityTag, commandContent (core command content), createTime, executeStatus (command execution status), and executeTime (actual execution time of the command).

[0107] IV. SRv6 Protocol Integration Details This system achieves deep integration between the SDN-WAN controller and the dual-stack collaborative scheduling module through SRv6 path programming. The dual-stack collaborative scheduling module generates a corresponding SRv6 segment identifier list (SegmentList) based on service priorities and sends this list as a core parameter to the SDN-WAN controller. After parsing the command, the SDN-WAN controller binds the service priority label to the corresponding segment identifier list using SRv6 policies (SRv6Policy), forming a relationship of "priority label → segment identifier list → forwarding path".

[0108] Specifically, this system adopts a "hierarchical SID allocation + priority binding" approach. Different SID prefixes are assigned to the four service levels, P1 to P4: P1 level SID prefix is ​​2001:db8:0001:: / 64, P2 level is 2001:db8:0002:: / 64, P3 level is 2001:db8:0003:: / 64, and P4 level is 2001:db8:0004:: / 64. Based on the priority prefixes, a unique suffix identifier is assigned to each network node and link, forming a complete SID. The SDN-WAN controller distinguishes service paths of different priorities through SRv6Policies. Each SRv6Policy corresponds to a priority level, including traffic matching rules (based on service priority labels) and path selection strategies (bound to a dedicated SegmentList, setting path priority weights).

[0109] To ensure the separation of core business and ordinary business paths, the SDN-WAN controller reserves dedicated link bandwidth for the SegmentList of P1 and P2 level services through SRv6Policy (e.g., reserving 80% of the bandwidth of a dedicated high-speed link for P1 level services), prohibiting ordinary business traffic from occupying core path resources, and ensuring low latency and high reliability of core business paths.

[0110] When service traffic enters the SDN-WAN network, the SDN-WAN controller extracts the service priority label from the traffic, queries the SID association table, quickly matches the corresponding SegmentList, and encapsulates the SegmentList into the SRv6 header of the IPv6 packet to guide the forwarding device to forward the traffic according to the SID list.

[0111] V. Collaborative Fault Tolerance Mechanism This system also includes a collaborative fault tolerance mechanism. When the link status acquisition module detects a link or SRv6 path failure, the dual-stack collaborative scheduling module generates a collaborative fault switching instruction, synchronously switching dual-stack traffic to a backup link or backup path according to service priority, controlling the core service switching latency to within 100ms. The system adopts a pre-decision caching mechanism, pre-storing the optimal switching strategy corresponding to various fault scenarios. When a fault occurs, there is no need to recalculate the decision; the corresponding strategy is directly called from the cache. When the faulty link or path returns to normal, dual-stack traffic is smoothly switched back.

[0112] VI. System Variants The technical solution of this application can be flexibly varied according to the SDN-WAN deployment scale, business needs, and link resource conditions of different banks, while the core collaborative scheduling logic and business priority orientation remain unchanged. The specific variations are as follows: (1) Component deployment variants: The business priority management module can be integrated into the SDN-WAN controller (no need for independent deployment), reducing hardware resource consumption and suitable for small and medium-sized banks; the link status acquisition module can use lightweight components to adapt to deployment scenarios with a small number of branches and simple link resources.

[0113] (2) Traffic prediction module variant: If the bank does not have sufficient historical traffic data, the traffic prediction module can be replaced with the "real-time traffic monitoring + threshold trigger" mode, and the LSTM prediction model can be canceled. When the dual-stack traffic of a certain priority reaches 80% of the preset link threshold, dynamic scheduling will be triggered immediately.

[0114] (3) Business priority variants: Business priority rules can be adjusted according to the actual business needs of the bank. For example, "emergency business" (loss reporting, payment suspension, emergency fund transfer) can be added with higher priority than core business. For banks with simple business types, priority classification can be simplified (only core business and ordinary business are distinguished).

[0115] (4) Dual-stack adaptation variant: If the bank has not yet completed the full-link dual-stack transformation (some links only support IPv4), the dual-stack collaborative scheduling function can be turned off, and only the single protocol (IPv4) based on service priority routing scheduling can be retained. After the dual-stack transformation is completed, the dual-stack adaptation function can be directly enabled.

[0116] (5) SRv6 adaptation variant: If the bank's SDN-WAN environment does not deploy the SRv6 protocol (using the traditional routing protocol), the SRv6 path optimization function can be turned off, and only dynamic routing scheduling based on link status and service priority can be retained. After the SRv6 protocol is deployed, the path optimization function can be directly enabled.

[0117] (6) Fault-tolerant variant: For scenarios with extremely high availability requirements (such as the core links between the head office and branches), a "multi-link redundancy" mechanism can be added to the fault-tolerant collaborative steps to deploy 3 or more core links to achieve multi-path backup of core business traffic.

[0118] Example 3 This embodiment takes a cross-regional SDN-WAN deployment scenario of a provincial bank as an example to illustrate the specific application of the technical solution of this application in a real financial environment.

[0119] I. Scene Description The bank has a head office data center in City A and branches in Cities B, C, and D, each with 5 to 8 sub-branches. The head office and branches are interconnected via two core leased lines (each with a bandwidth of 1000Mbps, both supporting IPv4 / IPv6 dual-stack and SRv6 protocols). Branches and sub-branches are interconnected via one core leased line (500Mbps bandwidth) and one backup internet leased line (200Mbps bandwidth). The bank's business types include: large-amount cross-regional transfers (single transaction ≥ 1 million RMB), real-time payments, ordinary cross-regional transfers (single transaction 10,000-1 million RMB), cross-regional redemption of wealth management products, branch office document transfer, branch data backup, and remote employee work.

[0120] Before adopting the technical solution of this application, the bank used a traditional SDN-WAN dual-stack scheduling solution, which had the following problems: large cross-regional transfers often had a latency of more than 100ms during peak business hours (such as monthly paydays and year-end settlement days), and occasional transaction timeouts; the IPv6 core link was congested during peak hours, while the IPv4 backup link resources were idle; a core leased line failure caused cross-regional transactions to be interrupted for about 3 minutes, resulting in a significant impact on business.

[0121] II. Plan Deployment The bank deployed the dynamic routing and scheduling system based on business priority in a dual-stack environment according to the technical solutions described in Embodiment 1 and Embodiment 2.

[0122] The deployment process is as follows: Deploy an SDN-WAN controller (supporting IPv4 / IPv6 dual stack and SRv6 protocol) in the data center of the head office in City A; deploy a business priority management module next to the core transaction system; integrate the dual-stack collaborative scheduling module into the SDN-WAN controller; deploy a link status acquisition module in the WAN access nodes of each branch and sub-branch; deploy a traffic prediction module and access the bank's traffic database for the past 6 months.

[0123] Initial Configuration: Preset business priority rules—large cross-regional transfers (≥1 million RMB) and real-time payments are classified as P1-level core businesses; ordinary cross-regional transfers (10,000-1 million RMB) and cross-regional redemption of wealth management products are classified as P2-level important businesses; branch office transmission and data backup are classified as P3-level ordinary businesses; remote employee work is classified as P4-level low-priority businesses. Preset link status thresholds: core leased line latency ≤50ms, packet loss rate ≤0.1%, bandwidth utilization ≤75%; backup internet leased line latency ≤100ms, packet loss rate ≤1%, bandwidth utilization ≤90%. Preset initial dual-stack traffic splitting ratio: IPv4:IPv6=4:6. Configure SRv6 path configuration information: P1-level businesses are assigned low-latency path SIDs (path latency ≤30ms), P2-level businesses are assigned medium-latency path SIDs (path latency ≤50ms), and P3 and P4-level businesses are assigned general SIDs (path latency ≤100ms).

[0124] III. Operational Results After the system went live, the following operational data was collected during a three-month continuous operation period: (1) Peak business performance: On paydays (the 5th and 25th of each month) and year-end settlement days (December 31st), the volume of large-amount cross-regional transfers increased by about 3 times compared to normal days. The traffic prediction module predicted 10 minutes in advance that the IPv6 core business traffic would reach its peak (accounting for about 70% of the total traffic). The dual-stack collaborative scheduling module automatically adjusted the dual-stack traffic splitting ratio to IPv4:IPv6=3:7, prioritizing the allocation of P1-level core businesses to two core leased lines (with latency stabilized at 25-35ms), and allocating P3 and P4-level businesses to backup internet leased lines. The average latency of core businesses was controlled at 42ms, and no transaction timeout events occurred.

[0125] (2) Fault handover performance: During operation, a core leased line from City B to City A experienced a link interruption due to operator issues (latency surged to over 500ms). The link status acquisition module detected the fault and sent an alarm within 30ms. The dual-stack collaborative scheduling module invoked the handover strategy in the pre-decision cache and completed the dual-stack traffic handover within 80ms, switching P1 and P2 level services of the City B branch to another core leased line, and switching P3 and P4 level services to the backup internet leased line. During the handover, large cross-regional transfer transactions were uninterrupted and without packet loss, and users were unaware of the interruption.

[0126] (3) Resource utilization performance: Compared with before the launch, the dual-stack link resource utilization rate increased from an average of 55% to 72%, the IPv6 link idle rate decreased from 30% to 8%, and the dual-stack traffic forwarding failure rate decreased from 0.5% to below 0.01%.

[0127] The specific bank names, location names, and monetary amounts mentioned in this embodiment are for the purpose of describing the technical solution and do not constitute a reference to or limitation of any particular financial institution. Those skilled in the art will understand that the technical solution of this application is applicable to any financial institution or enterprise scenario with similar dual-stack wide area network deployment requirements.

[0128] The specific embodiments described above are merely exemplary embodiments of this application and are not intended to limit the scope of protection of this application. The scope of protection of this application is determined by the claims. Those skilled in the art should understand that various equivalent substitutions, modifications, and combinations can be made to the technical features in the above embodiments without departing from the spirit and principles of this application, and all technical solutions formed by such equivalent substitutions, modifications, and combinations should be included within the scope of protection of this application.

[0129] Specifically, the modules, units, components, and their connections in the technical solution of this application are shown as a specific implementation method. Those skilled in the art can make appropriate adjustments to the module division method and deployment location (such as integrating the service priority management module into the SDN-WAN controller or deploying the dual-stack collaborative scheduling module independently) according to actual deployment needs. As long as the core functions of service priority identification, multi-dimensional collaborative decision-making, and dynamic routing scheduling described in this application can be achieved, they should all fall within the protection scope of this application.

[0130] The various preferred features described in this application (such as the LSTM traffic prediction model, SRv6 path optimization, dynamic weight adjustment algorithm, and collaborative fault tolerance mechanism) are not essential technical features for achieving the basic purpose of this application. Even without the aforementioned preferred features, as long as the core technical concept of "business priority orientation + dual-stack collaborative scheduling" is implemented, it still constitutes part of the technical solution of this application and should be protected by the patent rights of this application.

[0131] The specific values ​​recorded in this application (such as link status threshold, switching latency threshold, traffic splitting percentage, model training data volume, etc.) are all exemplary parameters. Those skilled in the art can make reasonable adjustments according to actual application scenarios (such as the business needs of different financial institutions and the hardware performance of different links). As long as the adjusted parameters can achieve the technical effects described in this application, they should all fall within the protection scope of this application.

[0132] Any technical solution obtained by conventional, non-inventive improvement based on the technical solution disclosed in this application, including but not limited to: appropriately adjusting the order of steps in the method of this application, merging or splitting modules in the system of this application, or simply combining the technical solution of this application with known technologies in the prior art, shall be deemed not to have departed from the protection scope of this application.

Claims

1. A dynamic routing and scheduling method based on service priority in a dual-stack environment, characterized in that, include: Step S1: Preset service priority rules, dual-stack adaptation rules, link status thresholds and SRv6 path configuration information, and preset the initial IPv4 / IPv6 traffic splitting ratio; Step S2: Receive service requests, identify service types and mark service priority tags; collect dual-stack traffic data, link operation status indicators and SRv6 path operation status; Predict the peak and trend of dual-stack traffic in future time periods using a built-in prediction model; Step S3: Based on service priority, and combined with dual-stack traffic distribution, link status and traffic prediction results, determine the dual-stack routing allocation rules for services with different priorities, dynamically adjust the IPv4 / IPv6 traffic splitting ratio, and generate dynamic routing scheduling instructions. Step S4: Send the instruction to the software-defined wide area network controller to adjust the routing strategy; collect the link status and service transmission status after scheduling, compare the differences before and after scheduling, and if there is an anomaly, adjust the instruction and resend it; Step S5: Detect link and SRv6 path faults, generate fault alarms, and generate synchronous fault switching instructions in combination with service priorities; After the fault is recovered, the dual-stack traffic will be smoothly switched back according to the service priority.

2. The dynamic routing and scheduling method based on service priority in a dual-stack environment according to claim 1, characterized in that, In step S3, differentiated SRv6 paths are allocated according to different priority services: core services are allocated to low-latency paths, and ordinary services are allocated to general paths.

3. The dynamic routing and scheduling method based on service priority in a dual-stack environment according to claim 1, characterized in that, In step S2, the built-in prediction model is a long short-term memory network prediction model. Its input feature vector includes real-time traffic rate of IPv4 stack, real-time traffic rate of IPv6 stack, traffic fluctuation value of IPv4 stack, traffic fluctuation value of IPv6 stack, core link bandwidth utilization, average link latency, link jitter value, link failure frequency, proportion of high-priority service traffic, frequency of service initiation, proportion of service type distribution, and historical traffic coefficient for the same period.

4. The dynamic routing and scheduling method based on service priority in a dual-stack environment according to claim 1, characterized in that, In step S3, the dynamic adjustment of the IPv4 / IPv6 traffic offloading ratio adopts a dynamic weight adjustment algorithm, which introduces three core weight factors: service priority weight, link utilization weight, and traffic prediction weight.

5. The dynamic routing and scheduling method based on service priority in a dual-stack environment according to claim 1, characterized in that, In step S5, fault detection adopts a dual detection mechanism that combines link heartbeat detection and traffic anomaly monitoring; fault switching adopts a pre-decision caching mechanism, which stores the optimal switching strategy corresponding to various fault scenarios in advance, and directly calls the corresponding strategy from the cache library when a fault occurs.

6. The dynamic routing and scheduling method based on service priority in a dual-stack environment according to claim 1, characterized in that, In step S4, when comparing the differences in indicators before and after scheduling, if the latency of the core service exceeds 50ms, or the link bandwidth utilization exceeds 75%, or the dual-stack traffic distribution is unreasonable, the scheduling instruction will be adjusted immediately and reissued for execution.

7. A dynamic routing and scheduling system based on service priority in a dual-stack environment, characterized in that, The system includes: The software-defined wide area network controller supports IPv4 / IPv6 dual-stack and SRv6 protocol, and is used to receive and execute dynamic routing scheduling instructions. The service priority management module is deployed between the software-defined wide area network controller and the business system to identify service types and dynamically generate service priority labels; The dual-stack collaborative scheduling module, integrated into the software-defined wide area network controller, is used to make multi-dimensional collaborative decisions based on service priorities and generate dynamic routing and scheduling instructions. The link status acquisition module is deployed at each WAN link node to collect real-time operational status indicators of each link. The traffic prediction module has a built-in long short-term memory network prediction model to predict the peak and trend of dual-stack traffic within a preset time period.

8. The dynamic routing and scheduling system based on service priority in a dual-stack environment according to claim 7, characterized in that, The dual-stack collaborative scheduling module has a built-in SRv6 path parsing module, which is used to generate the optimal forwarding path based on SRv6 according to service priority and link status; the dual-stack collaborative scheduling module adopts a combination of rule-based decision system and dynamic weight adjustment for collaborative decision-making.

9. The dynamic routing and scheduling system based on service priority in a dual-stack environment according to claim 7, characterized in that, The software-defined wide area network (SDWAN) controller and the dual-stack collaborative scheduling module are deeply integrated through SRv6 path programming: the dual-stack collaborative scheduling module generates a corresponding SRv6 segment identifier list based on service priority, and sends the segment identifier list as the core parameter of the instruction to the SWAN controller; after parsing the instruction, the SWAN controller binds the service priority label with the corresponding segment identifier list through SRv6 strategy.

10. The dynamic routing and scheduling system based on service priority in a dual-stack environment according to claim 7, characterized in that, The system also includes a collaborative fault tolerance mechanism: when the link status acquisition module detects a link or SRv6 path failure, the dual-stack collaborative scheduling module generates a collaborative fault switching instruction, and synchronously switches dual-stack traffic to the backup link or backup path according to service priority, controlling the core service switching latency to within 100ms; when the faulty link or path returns to normal, the dual-stack traffic is smoothly switched back.

Images