Service network message cross-domain transmission method and system based on SRv6 SID function extension

Abstract

The invention belongs to the technical field of network communication, and discloses a service network message cross-domain transmission method and system based on SRv6SID function extension. According to the method, a service network identifier is embedded in an Args field of the SRv6SID, the service network identifier comprises a service network type (TYPE) and a service virtual group tag (VGT), and service awareness transmission of a cross-domain network is realized in combination with an intelligent routing decision driven by deep reinforcement learning. Compared with the prior art, the protocol compatibility can be ensured, the transmission delay and the protocol overhead can be remarkably reduced, the transmission flexibility, the high efficiency and the customizability of the service network message among different network domains can be improved, and the method and the device are suitable for scenes such as 5G, industrial internet and the like.

Description

Technical Field

[0001] The present invention belongs to the technical field of network communication, and particularly relates to a method and system for cross-domain transmission of service network packets based on the function extension of Segment Routing over IPv6 (SRv6) Segment Identifier (SID), which is used to improve the flexibility, efficiency, and customizability of service network packets during transmission between different network domains, and is applicable to scenarios such as 5G bearer networks, cloud-network collaboration, and industrial Internet scenarios. Background Art

[0002] With the rapid development of the Internet and the diversification of services, the demand for cross-domain transmission of service network packets is increasing day by day. Traditional network transmission technologies have many deficiencies in dealing with complex and changing service requirements. In cross-domain transmission scenarios, different network domains may adopt different network protocols, topological structures, and management strategies, which pose challenges to the compatibility and interoperability of packet cross-domain transmission. However, existing solutions such as MPLS / VXLAN require multiple-layer encapsulation, resulting in high protocol overhead and a lack of service awareness capabilities.

[0003] As an emerging source routing technology, SRv6 provides a certain degree of flexibility for cross-domain transmission by carrying a list of SIDs in the IPv6 header to specify the forwarding path of packets. However, the standard SRv6 SID does not define a service identification field and cannot support the specific requirements of diverse service types (such as delay-sensitive and computing-intensive types), such as differential processing of different service types and Quality of Service (QoS) guarantee.

[0004] Therefore, a method and system that can extend the SRv6 SID function are needed to achieve more efficient and flexible cross-domain transmission of service network packets. Summary of the Invention

[0005] The purpose of the present invention is to provide a method and system for cross-domain transmission of service network packets based on the function extension of SRv6 SID. By extending the function of SRv6 SID, it can support more service processing logics and QoS policies, thereby improving the performance and flexibility of cross-domain transmission of service network packets.

[0006] The technical solution adopted by the present invention is as follows:

[0007] A method for cross-domain transmission of service network packets based on the function extension of SRv6 SID includes the following steps:

[0008] Embed a service network identifier in the Args field of the SRv6 SID, where the service network identifier includes a service network type TYPE and a service virtual group tag VGT;

[0009] Dynamically generate a cross - domain path policy through a deep reinforcement learning model and map it to the SID list;

[0010] Perform cross - domain transmission of service network packets based on the SID list of the generated cross - domain path policy.

[0011] Furthermore, the service network identifier is a 128 - bit enhanced SID structure, including a 64 - bit IPv6 global routing prefix field, a 16 - bit local service function identifier field, and a 48 - bit Args field; the format of the Args field is: the first 16 bits are the Ethernet TYPE field, the middle 16 bits are the VGT field, and the last 16 bits are the reserved field.

[0012] Furthermore, the dynamically generating a cross - domain path policy through a deep reinforcement learning model includes:

[0013] Input state information, including network layer information, service layer information, and computing layer information;

[0014] Based on the input state information, use a deep reinforcement learning model to make action decisions, where the actions include: selecting a primary path, that is, generating an optimal end - to - end cross - domain primary path based on the SID list; triggering protection switching, that is, generating a backup SID list after detecting a fault; adjusting weights, that is, adjusting the path weights according to the service type.

[0015] Execute the path, calculate the reward according to the reward mechanism, and update the parameters of the deep reinforcement learning model according to the reward calculation result.

[0016] Furthermore, the network layer information includes link delay, bandwidth utilization rate, and packet loss rate; the service layer information includes service priority and SLA constraints.

[0017] Furthermore, the reward mechanism includes positive rewards and negative penalties; the positive rewards include reduced delay and increased bandwidth utilization rate; the negative penalties include too high packet loss rate and frequent path switching.

[0018] Furthermore, use a centralized SDN controller and a local DRL agent to cooperate in cross - domain path calculation.

[0019] Furthermore, the performing cross - domain transmission of service network packets based on the SID list of the generated cross - domain path policy includes:

[0020] The Ingress node encapsulates the SRH according to the SID list of the generated optimal cross - domain path;

[0021] The Transit node forwards the SRH according to the standard SRv6 without parsing the extended field;

[0022] The Egress node reconstructs the Ethernet frame header according to the TYPE field and injects the VGT label into the specified position of the data packet;

[0023] Based on VGT and TYPE, trigger the corresponding routing table entry locally at the Egress node to implement the forwarding of the packet subnet.

[0024] A service network packet cross-domain transmission system based on the SRv6 SID function extension using the above method, characterized in that it includes a service awareness encapsulation module and a local DRL agent provided at the Ingress node, a standard SRv6 forwarding engine and a network status collection module provided at the Transit node, a service context recovery module and a local forwarding module provided at the Egress node, and a centralized controller;

[0025] The service awareness encapsulation module is responsible for extracting and encapsulating the TYPE and VGT fields;

[0026] The local DRL agent is responsible for training and reasoning based on the DRL model to achieve cross-domain path optimization, receiving the global policy issued by the centralized controller, and fine-tuning the weights of the SID list in combination with the local status;

[0027] The service context recovery module is responsible for decapsulating the SRH, restoring the Ethernet header according to TYPE and VGT in the SID, and injecting the VGT into the specified position of the data packet;

[0028] The centralized controller is responsible for global topology management, updating the DRL model, and issuing a dynamic SID list to the Ingress node;

[0029] The standard SRv6 forwarding engine is responsible for forwarding the SRH according to the RFC 8986 specification;

[0030] The network status collection module is responsible for real-time monitoring of the link status information and reporting it to the centralized controller through the NETCONF protocol;

[0031] The local forwarding module is responsible for parsing the TYPE and VGT fields corresponding to the SRv6 packet and completing the packet subnet forwarding according to the local corresponding routing information table entry of the Egress node.

[0032] The beneficial effects of the present invention are as follows:

[0033] The present invention discloses a method and system for cross-domain transmission of service network packets based on SRv6 SID function extension. By embedding a service network identifier (TYPE / VGT) in the Args field of SRv6 SID and combining intelligent routing decision-making driven by deep reinforcement learning, service-aware transmission of cross-domain networks is achieved. Compared with the prior art, the present invention significantly reduces transmission delay and protocol overhead while ensuring protocol compatibility, and is applicable to scenarios such as 5G and industrial Internet. Brief Description of the Drawings

[0034] Figure 1 It is the system architecture diagram of the present invention, which schematically shows the interaction relationship between Ingress, Transit, Egress nodes and the controller.

[0035] Figure 2 It is the cross-domain path calculation flowchart, which schematically shows the state input, action output and reward mechanism of the DRL model. Detailed Embodiments

[0036] To make the above objects, features and advantages of the present invention more obvious and understandable, the present invention will be further described in detail below through specific embodiments and drawings.

[0037] I. Technical Solution

[0038] The core of the present invention lies in the SRv6 SID function extension mechanism and the cross-domain routing system, which are achieved through the following innovative points:

[0039] 1. Service network identifier encoding: Embed the service network type (TYPE) and service virtual group tag (VGT, Virtual Group Tag) in the Args field of SRv6 SID to form a 128-bit enhanced SID structure.

[0040] 2. Dynamic policy mapping engine: Based on deep reinforcement learning (DRL), generate cross-domain path policies in real time and encode the cross-domain path policies into the SID list.

[0041] 3. Compatibility: Intermediate nodes can achieve standard forwarding without parsing the extended fields and are interoperable with traditional SRv6 networks.

[0042] II. Method Steps

[0043] Step 1: Service network identifier encapsulation

[0044] 1) Input: Original Ethernet packet (including TYPE field) and service virtual group tag (VGT).

[0045] 2) SID construction rules:

[0046] The SID construction rules are shown in Table 1, and the descriptions of each field of the 128-bit SID are as follows:

[0047] Locator(64bits): The IPv6 address prefix, which identifies the network location (such as an AS domain or an edge node).

[0048] Function(16bits): Defines the SRv6 endpoint behavior (such as End.DT4 indicating IPv4 decapsulation).

[0049] Args(48bits):

[0050] a) TYPE(16bits): The original Ethernet frame type (such as 0x0800 = IPv4, 0x86DD = IPv6).

[0051] b) VGT(16bits): The service virtual group label (used for service chain identification or tenant isolation, such as high-priority real-time service 0xA001, low-priority service 0xB002, which are planned and assigned by the administrator).

[0052] c) Reserved(16bits): The reserved field (default is 0).

[0053] Table 1

[0054]

[0055] 3) Encapsulation process (Ingress node):

[0056] a) Ethernet frame parsing: Parse the Ethernet frame header of the data packet and extract the TYPE field.

[0057] b) Service virtual group matching: Match the VGT label according to the service policy library. An example of the service policy library is shown in Table 2.

[0058] Table 2

[0059]

[0060] c) SID construction:

[0061] Select the target SID Locator and Function according to the routing policy.

[0062] Encode according to TYPE and VGT into the Args field according to the SID construction rules (shown in Table 1), that is, the Args field is TYPE:VGT:Reserved, and finally the SID is Locator:Function:Args.

[0063] d) SRH encapsulation:

[0064] Add an IPv6 header and an SRH (Segment Routing Header), with the destination address being the constructed SID.

[0065] Strip the original Ethernet frame header and retain the Payload (payload data).

[0066] Step 2: Cross-domain path calculation

[0067] 1) Controller architecture: Adopt a collaborative approach between a centralized SDN (Software Defined Network) controller and distributed agents (i.e., local DRL agents):

[0068] a) Centralized controller: Maintain the global topology and service policy library. Each node can report its node SID information through the BGP-LS extension protocol.

[0069] b) Distributed agent: Deployed on domain boundary network devices (such as ASBRs), it calculates the optimal cross-domain path in real time based on the DRL model.

[0070] 2) DRL model:

[0071] a) Input: St = {link delay, bandwidth utilization, service priority, SLA constraint}

[0072] Among them, the link delay refers to the end-to-end link transmission delay; the bandwidth utilization refers to the ratio of the actual bandwidth usage to the total available bandwidth. For example, if the total bandwidth is 100 Mbps and the actual usage is 50 Mbps, then the bandwidth utilization is 50%; the service priority refers to the response delay level of the data, given by the lower four bits of the VGT, with a value of VGT & 0x000F; the SLA constraint refers to QoS requirements, such as a bandwidth requirement of not less than 1 Gbps and a packet loss rate of not less than 0.05%.

[0073] b) Action space: At = {select the next-hop domain boundary network device ASBR, adjust the path weight, trigger protection switching}

[0074] c) Output: {generate the optimal cross-domain primary path, generate a backup SID list, adjust the path weight}

[0075] Figure 2 is the cross-domain path calculation flowchart, which shows the state input, action output, and reward mechanism of the DRL model. As Figure 2 shown, the specific steps of cross-domain path calculation are as follows:

[0076] 1) State input:

[0077] a) Network layer information: Link delay, bandwidth utilization, packet loss rate, etc. The parameter types can be customized according to requirements.

[0078] b) Service layer information: service priority, SLA constraints (such as latency < 10ms), and parameter types can be customized according to requirements.

[0079] c) Computing layer information: utilization rate of computing power such as CPU / GPU, etc., and parameter types can be customized according to requirements.

[0080] 2) DRL action decision and output:

[0081] a) Main path selection: Generate the optimal end-to-end cross-domain main path based on the SID list.

[0082] b) Protection switching: Generate a backup SID list after detecting a fault. Detecting a fault mainly refers to detecting faults in Transit nodes, including possible interruptions, congestion, or poor signal quality in the links between Transit nodes and adjacent nodes. These faults will affect the forwarding and transmission of packets.

[0083] c) Dynamic weight adjustment: Adjust the path weight according to the service type (such as adding 30% to the path weight for latency-sensitive services).

[0084] 3) Reward mechanism:

[0085] a) Positive reward:

[0086] Latency reduction: R delay = 1 / (T delay + 1), where T delay represents the link latency.

[0087] Bandwidth utilization improvement: R bw = tanh(U bw ), where U bw represents the bandwidth utilization.

[0088] b) Negative penalty:

[0089] High packet loss rate: P loss = -10*R loss where R loss represents the packet loss rate.

[0090] Frequent path switching: P switch = -5*N switch where N switch represents the number of path switches.

[0091] c) Total reward function:

[0092] R total = αR delay + βR bw + P loss + P switch

[0093] Among them, α and β take values in [0, 1], and α and β can be adjusted according to the actual changes in delay and bandwidth utilization, as well as the learning effects of the model on different reward items, so that the model can better adapt to the environment.

[0094] Step 3: Policy execution and packet forwarding

[0095] 1) Data plane processing:

[0096] a) The Ingress node encapsulates the SRH according to the SID list of the generated optimal cross-domain path.

[0097] b) The Transit node forwards the SRH according to the standard SRv6 without parsing the extended fields.

[0098] c) The Egress node decapsulates the SRH and restores the original Ethernet frame, and injects the VGT into the data packet.

[0099] 2) Decapsulation process (Egress node)

[0100] a) SRH parsing: Extract the Args field in the destination SID, and decode TYPE and VGT.

[0101] b) Ethernet frame reconstruction: Reconstruct the Ethernet frame header according to the TYPE field. Inject the VGT label into the specified position of the data packet (such as the Ethernet frame header or custom field).

[0102] c) Forwarding decision: Based on the VGT and TYPE, trigger the corresponding local routing table entry of the Egress node (such as QoS queue selection, service chain jump) to implement the forwarding of the packet in the subnet.

[0103] III. System composition

[0104] The service network packet cross-domain transmission system based on the SRv6 SID function extension of the present invention is as Figure 1 shown, which shows the interaction relationship between the Ingress node (the ingress node of the SRv6 path), the Transit node (the IPv6 forwarding node in the SRv6 path), the Egress node (the tail node of the SRv6 path), and the centralized controller. Among them, the Ingress node is responsible for generating SRv6 packets, the Transit node is required to support at least the IPv6 protocol and is responsible for forwarding packets according to the IPv6 protocol, and the Egress node is responsible for terminating SRv6 packets and performing packet parsing according to the SID behavior.

[0105] As Figure 1As shown in the figure, the system includes a service awareness encapsulation module and a local DRL agent installed at the Ingress node, a standard SRv6 forwarding engine and a network status collection module installed at the Transit node, a service context restoration module and a local forwarding module installed at the Egress node, and a centralized controller. The specific description is as follows:

[0106] 1) Service awareness encapsulation module

[0107] a) An ASIC chip that supports programmable pipelines.

[0108] b) Realize line-speed extraction and encapsulation of TYPE / VGT fields (≤1 μs delay).

[0109] 2) Local DRL agent

[0110] a) Based on DRL model training / inference, achieve millisecond-level cross-domain path optimization.

[0111] b) Receive the global policy issued by the controller and fine-tune the SID list weights in combination with the local status (such as port congestion).

[0112] 3) Service context restoration module

[0113] Decapsulate the SRH, restore the Ethernet header according to the TYPE / VGT in the SID, and inject the VGT into the specified position of the data packet.

[0114] 4) Centralized controller

[0115] a) Global topology management: Collect the topology and resource status of each AS domain through BGP-LS, construct a weighted directed graph, and mark the cross-domain link delay / cost.

[0116] b) DRL model training / inference: Based on the TD3 algorithm, update the policy model every 5 minutes.

[0117] c) Policy distribution: Issue a dynamic SID list to the Ingress node through the PCEP protocol.

[0118] 5) Standard SRv6 forwarding engine

[0119] The standard SRv6 forwarding engine is an existing capability of the Transit node. It processes the SRH according to the RFC 8986 specification without parsing the TYPE / VGT fields to achieve stateless forwarding.

[0120] 6) Network status collection module

[0121] The network status collection module monitors the link bandwidth utilization rate, delay, packet loss rate, etc. in real time and reports them to the controller through the NETCONF protocol.

[0122] 7) Local forwarding module

[0123] The local forwarding module refers to the Egress node terminating the SRv6 packet and parsing the corresponding TYPE / VGT fields, and then completing the subnet forwarding of the packet according to the local corresponding routing information table entry (such as FIB) of the Egress node.

[0124] Figure 1 In it, BGP-LS means reporting and collecting information such as node SIDs based on the BGP-LS extended protocol. FIB refers to the forwarding information table, which is used to forward data frames or data packets. NETCONF is a standard network configuration management protocol defined by the IETF (Internet Engineering Task Force), which automates the configuration management and operation of various network devices (such as routers, switches, firewalls, etc.), and is mainly used to monitor the link bandwidth utilization rate, delay, packet loss rate in real time and report to the controller. PCEP (Path Computation Element Protocol) is an application layer protocol defined by the IETF, which is used to establish, maintain and manage explicit paths in the network. Here, a dynamic SID list is sent to the Ingress node through the PCEP protocol.

[0125] Figure 1 It includes the forward data flow, control flow and exception handling flow, and the specific descriptions are as follows:

[0126] 1) Forward data flow

[0127] Service packet transmission: Terminal device (data packet) → Ingress node (encapsulating SID) → Transit node (hop-by-hop forwarding) → Egress node (decapsulating) → Target system.

[0128] 2) Control flow

[0129] Policy interaction:

[0130] Centralized controller ←→ Ingress node (SRv6 SID list update, configuration management);

[0131] Centralized controller ←→ Transit node (status information collection);

[0132] Centralized controller ←→ Egress node (configuration management).

[0133] 3) Exception handling flow

[0134] Path protection switching:

[0135] The Transit node detects a fault → reports to the controller → the DRL model generates a new SID list → the PCEP protocol is sent to the Ingress node → the path is switched.

[0136] Embodiment 1: 5G UPF Cross-Domain Traffic Scheduling

[0137] Scenario: The User Plane Function (UPF) needs to be migrated between multiple data centers to ensure the Service Level Agreement (SLA) of the Ultra-Reliable and Low-Latency Communications (URLLC, one of the three major 5G scenarios) service.

[0138] Implementation steps:

[0139] 1) When the UPF is instantiated, the controller assigns VGT = 0xA001 to identify high-priority services.

[0140] 2) The Ingress node encapsulates the SID list:

[0141] [AS1-SID (TYPE = 0x88F7, VGT = 0xA001), AS2-SID].

[0142] 3) The intermediate path selects a low-latency link according to the TYPE / VGT field, and the latency ≤ 5 ms.

[0143] Embodiment 2: Cloud Network Intelligent Operation and Maintenance

[0144] Input: Network congestion alarm (bandwidth utilization rate > 90%).

[0145] DRL response:

[0146] 1) Action: Switch part of the VGT = 0xB002 (background traffic) to the backup path.

[0147] 2) Result: The utilization rate of the main path drops to 70%, and there is zero packet loss for critical services.

[0148] It should be understood that the methods and systems disclosed in the above embodiments provided by the present invention can be implemented in other ways. For example, the above module division may have other division methods in specific implementations, and multiple modules can be combined or integrated into another system, or some features can be ignored or not executed. Each module in the present invention can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium, including several instructions for causing a computer device to execute some or all of the steps of the method described in the present invention. For example, an embodiment of the present invention provides a computer device (such as a computer, a server, etc.), which includes a memory and a processor, the memory stores a computer program, the computer program is configured to be executed by the processor, and the computer program includes instructions for executing each step in the method of the present invention. For example, another embodiment of the present invention provides a computer-readable storage medium (such as ROM / RAM, disk, optical disc, etc.), the computer-readable storage medium stores a computer program, and when the computer program is executed by the computer, each step of the method of the present invention is implemented.

[0149] The specific embodiments of the present invention disclosed above are intended to help understand the content of the present invention and implement it accordingly. Those of ordinary skill in the art can understand that various substitutions, changes, and modifications are possible without departing from the spirit and scope of the present invention. The present invention should not be limited to the content disclosed in the embodiments of this specification, and the protection scope of the present invention shall be subject to the scope defined by the claims.

Claims

1. A cross-domain transmission method for service network messages based on SRv6 SID function extension, characterized in that: The following steps are involved: Embed a service network identifier in the Args field of the SRv6 SID, where the service network identifier includes a service network type TYPE and a service virtual group tag VGT; Dynamically generate cross-domain path strategies through deep reinforcement learning models and map them to SID lists; The cross-domain transmission of service network messages is performed based on the SID list of the generated cross-domain path policy.

2. The method according to claim 1, characterized in that The service network identifier is a 128-bit enhanced SID structure, including a 64-bit IPv6 global routing prefix field, a 16-bit local service function identifier field, and a 48-bit Args field; the format of the Args field is: the first 16 bits are the Ethernet TYPE field, the middle 16 bits are the VGT field, and the last 16 bits are the reserved field.

3. The method according to claim 1, characterized in that The cross-domain path strategy is dynamically generated by the deep reinforcement learning model, including: Input status information, including network layer information, business layer information and computing layer information; Based on the input status information, a deep reinforcement learning model is used to make action decisions, including: selecting the primary path, that is, generating the optimal end-to-end cross-domain primary path based on the SID list; triggering protection switching, that is, generating a backup SID list after detecting a fault; adjusting the weight, that is, adjusting the path weight according to the service type; The execution path is executed, and the reward is calculated according to the reward mechanism. The parameters of the deep reinforcement learning model are updated according to the reward calculation results.

4. The method according to claim 3, characterized in that The network layer information includes link delay, bandwidth utilization, and packet loss rate; the service layer information includes service priority and SLA constraints.

5. The method according to claim 3, characterized in that: The reward mechanism includes positive rewards and negative penalties; the positive rewards include reduced latency and improved bandwidth utilization; the negative penalties include excessively high packet loss rate and frequent path switching.

6. The method according to claim 3, characterized in that A centralized SDN controller is used to collaborate with local DRL agents to perform cross-domain path calculations.

7. The method according to claim 1, characterized in that The cross-domain transmission of the service network message based on the SID list of the generated cross-domain path strategy includes: The Ingress node encapsulates the SRH based on the SID list of the generated optimal cross-domain path; The transit node forwards the SRH according to standard SRv6, without parsing the extended field; The egress node reconstructs the Ethernet frame header according to the TYPE field and injects the VGT label into the specified position of the data message. Based on the VGT and TYPE, the corresponding routing table entry of the egress node is triggered to realize the forwarding of the message subnet.

8. A service network message cross-domain transmission system based on SRv6 SID function extension using the method described in any one of claims 1 to 7, characterized in that: It includes a service perception encapsulation module and a local DRL agent located at the Ingress node, a standard SRv6 forwarding engine and a network status collection module located at the Transit node, a service context recovery module and a local forwarding module located at the Egress node, and a centralized controller; The business-aware encapsulation module is responsible for extracting and encapsulating the TYPE and VGT fields; The local DRL agent is responsible for training and reasoning based on the DRL model to achieve cross-domain path optimization, and receives the global strategy issued by the centralized controller, and fine-tunes the weight of the SID list in combination with the local state; The service context recovery module is responsible for decapsulating the SRH, recovering the Ethernet header according to the TYPE and VGT in the SID, and injecting the VGT into the specified position of the data message; The centralized controller is responsible for global topology management, updating the DRL model, and sending dynamic SID lists to Ingress nodes; The standard SRv6 forwarding engine is responsible for forwarding SRH according to RFC 8986 specification; The network status collection module is responsible for real-time monitoring of link status information and reporting to the centralized controller through the NETCONF protocol; The local forwarding module is responsible for parsing the TYPE and VGT fields corresponding to the SRv6 message, and completing the message subnet forwarding according to the local corresponding routing information table entry of the Egress node.

9. A computer device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, the computer program is configured to be executed by the processor, and the computer program comprises instructions for executing the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a computer, the method according to any one of claims 1 to 7 is implemented.

Images