Routing data transmission method and apparatus, device, and storage medium

Abstract

The application discloses a routing data transmission method and device, equipment and storage medium, relates to the field of data transmission, and is applied to a routing node in a routing domain. The method comprises the following steps: receiving a service data packet, analyzing the service data packet, obtaining label information carried in the service data packet, and transmitting the service data packet in the routing domain based on the label information. Since the routing node analyzes the service data packet, and transmits the service data packet in the routing domain based on the label information carried by the service data packet, the safety and flexibility of data packet transmission in the routing domain are effectively improved, and the path failure problem caused by the node failure problem in the routing domain is effectively avoided.

Description

Technical Field

[0001] This invention relates to the field of data transmission technology, and in particular to a method, apparatus, device, and storage medium for routing data transmission. Background Technology

[0002] Technological innovations such as the Internet, big data, cloud computing, artificial intelligence, and blockchain have accelerated the development of the digital economy. The development of the data economy will drive the generation of massive amounts of data, and data processing requires powerful computing power and extensive network connectivity through the collaboration of cloud, edge, and terminal devices.

[0003] Computing power networks are a new type of information infrastructure that allocates and flexibly schedules computing, storage, and network resources on demand across the cloud, edge, and endpoints based on business needs. Essentially, computing power networks provide a computing resource service. In the future, enterprise customers and individual users will not only need networks and the cloud, but also the flexibility to schedule computing tasks to suitable locations. Currently, computing power routing primarily transmits data via fixed paths. This transmission method has low flexibility, requires reserved resources for specific transmission scenarios, thus necessitating high resource demands and resulting in low data transmission efficiency.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a routing data transmission method, apparatus, device, and storage medium, aiming to solve the technical problems of low flexibility, the need to reserve resources for transmission scenarios, and the resulting high resource requirements and low data transmission efficiency in the existing technology of transmitting data through fixed paths.

[0006] To achieve the above objectives, the present invention provides a routing data transmission method, which is applied to routing nodes in a routing domain;

[0007] The routing data transmission method includes:

[0008] Receive service data packets;

[0009] The service data packet is parsed to obtain the tag information carried in the service data packet;

[0010] The service data packets are transmitted in the routing domain based on the tag information.

[0011] Optionally, before transmitting the service data packet in the routing domain based on the tag information, the method further includes:

[0012] Extract the tag identifier carried in the service data packet based on the tag information;

[0013] Determine whether the label identifier is an intra-domain identifier of the routing domain to which the routing node belongs;

[0014] If the label identifier is not an intra-domain identifier, then the routing node is determined to be the first node in its routing domain to receive the service data packet, and the step of transmitting the service data packet in the routing domain based on the label information is executed;

[0015] If the label identifier is an intra-domain identifier, then it is determined that the routing node is not the first node in its routing domain to receive the service data packet, and the step of transmitting the service data packet in the routing domain based on the label information is executed.

[0016] Optionally, before transmitting the service data packet in the routing domain based on the tag information, the method further includes:

[0017] Determine whether the service data packet carries a service data path;

[0018] If the service data path is not carried, the routing node is determined to be the first node in its routing domain to receive the service data packet, and the step of transmitting the service data packet in the routing domain based on the tag information is executed;

[0019] If the service data path is carried, it is determined that the routing node is not the first node in its routing domain to receive the service data packet, and the service data packet is transmitted based on the service data path.

[0020] Optionally, before transmitting the service data packet in the routing domain based on the tag information, the method further includes:

[0021] Based on the parsing results, determine whether the business data packet carries business requirement information;

[0022] If the service data packet carries service requirement information, the service data packet is transmitted in the routing domain based on the service requirement information;

[0023] If the service data packet does not carry service requirement information, then the step of transmitting the service data packet in the routing domain based on the tag information is performed.

[0024] Optionally, if the service data packet carries service requirement information, then transmitting the service data packet in the routing domain based on the service requirement information includes:

[0025] Obtain the local routing requirement information and local policy information of the routing domain;

[0026] The business data path is determined based on the business requirement information, the local routing requirement information, and the local policy information;

[0027] The service data packets are transmitted in the routing domain based on the service data path.

[0028] Optionally, transmitting the service data packet within the routing domain based on the service data path includes:

[0029] The header field of the business data packet is expanded based on the business data path;

[0030] The service data packet is transmitted in the routing domain based on the extended header field of the service data packet.

[0031] Optionally, expanding the header field of the service data packet based on the service data path includes:

[0032] The nodes to be traversed in the routing domain are determined based on the business data path;

[0033] Obtain the node label information of each node to be traversed;

[0034] The header field of the service data packet is expanded based on the node label information.

[0035] Furthermore, to achieve the above objectives, the present invention also proposes a routing data transmission device, the routing data transmission device comprising:

[0036] The data packet receiving module is used to receive business data packets;

[0037] The data packet parsing module is used to parse the service data packet and obtain the tag information carried in the service data packet;

[0038] A data packet transmission module is used to transmit the service data packets in the routing domain based on the tag information.

[0039] Furthermore, to achieve the above objectives, the present invention also proposes a routing data transmission device, which includes: a memory, a processor, and a routing data transmission program stored in the memory and executable on the processor, wherein the routing data transmission program is configured to implement the steps of the routing data transmission method described above.

[0040] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a routing data transmission program, which, when executed by a processor, implements the steps of the routing data transmission method described above.

[0041] This invention is applied to routing nodes in a routing domain. It receives service data packets, parses them to obtain tag information carried within the packets, and then transmits the packets within the routing domain based on this tag information. Because this invention parses service data packets at routing nodes and transmits them within the routing domain based on the tag information carried by the packets, it effectively improves the security and flexibility of data packet transmission within the routing domain and effectively avoids path failures caused by node failures within the routing domain. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the structure of the routing data transmission device in the hardware operating environment involved in the embodiments of the present invention;

[0043] Figure 2 This is a flowchart illustrating the first embodiment of the routing data transmission method of the present invention;

[0044] Figure 3 This is a schematic diagram of label allocation in the first embodiment of the routing data transmission method of the present invention;

[0045] Figure 4 This is a data forwarding diagram of the first embodiment of the routing data transmission method of the present invention;

[0046] Figure 5 This is a schematic diagram of data packet transmission in the first embodiment of the routing data transmission method of the present invention;

[0047] Figure 6 This is a data encapsulation diagram of the first embodiment of the routing data transmission method of the present invention;

[0048] Figure 7 This is a schematic diagram of header field expansion in the first embodiment of the routing data transmission method of the present invention;

[0049] Figure 8 This is a schematic diagram of the encapsulation of the first embodiment of the routing data transmission method of the present invention;

[0050] Figure 9 This is a flowchart illustrating the second embodiment of the routing data transmission method of the present invention;

[0051] Figure 10 This is a schematic diagram of data transmission in a routing autonomous domain according to a second embodiment of the routing data transmission method of the present invention;

[0052] Figure 11 This is a schematic diagram of the encapsulation of data by the end node in the second embodiment of the routing data transmission method of the present invention;

[0053] Figure 12This is a schematic diagram of message encapsulation in the second embodiment of the routing data transmission method of the present invention;

[0054] Figure 13 This is a schematic diagram showing the addition of an outer packet header in the second embodiment of the routing data transmission method of the present invention;

[0055] Figure 14 This is a structural block diagram of the first embodiment of the routing data transmission device of the present invention.

[0056] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0057] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0058] Reference Figure 1 , Figure 1 This is a schematic diagram of the routing data transmission device structure in the hardware operating environment involved in the embodiments of the present invention.

[0059] like Figure 1 As shown, the routing data transmission device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk drive. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.

[0060] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the routing data transmission device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0061] like Figure 1As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and a routing data transmission program.

[0062] exist Figure 1 In the routing data transmission device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in the routing data transmission device of the present invention can be set in the routing data transmission device, and the routing data transmission device calls the routing data transmission program stored in the memory 1005 through the processor 1001 and executes the routing data transmission method provided in the embodiment of the present invention.

[0063] This invention provides a method for routing data transmission, referring to... Figure 2 , Figure 2 This is a flowchart illustrating a first embodiment of a routing data transmission method according to the present invention.

[0064] In this embodiment, the routing data transmission method is applied to routing nodes in a routing domain; the routing data transmission method includes the following steps:

[0065] Step S10: Receive service data packets.

[0066] It should be noted that this embodiment can establish patchwork routing autonomous systems (AAS) in the network. The controller determines the routing nodes or routing autonomous systems / autonomous routing domains that data needs to pass through based on service requirements, security considerations, or other routing policy requirements. The path does not specify specific entry and exit devices for the routing autonomous systems it traverses. Flexible configuration of intra-domain routing is possible within the routing autonomous system; that is, intra-domain routing policies can be set according to actual conditions, such as load balancing, shortest path, minimum latency, and resource conservation.

[0067] In large-scale computing network systems, when services need to route through a specific routing autonomy (SADA), they can select only the SADA through which the service data passes, without specifying the particular devices within that SADA. Furthermore, the service requirements are determined by information carried by MPLS labels or SIDs, or the intra-domain routing path is autonomously determined based on these requirements. This allows for more flexible service routing while also partially shielding the topology information of routing devices within the domain, facilitating autonomous domain updates and management, enabling different routing policies for different SADAs, and resolving path failures caused by node failures within the SADA. Simultaneously, based on security monitoring or route redirection considerations, policies requiring services to pass through a specific SADA can be implemented.

[0068] It should be understood that the execution subject of the method in this embodiment can be a routing data transmission device with data processing, network communication and program running functions, such as a computer, or other devices or equipment that can achieve the same or similar functions. Here, the routing data transmission device (hereinafter referred to as the entry device) is used as an example for explanation.

[0069] It should be noted that the routing domain through which a service data packet is transmitted can be one or more. If the routing domain that receives the service data packet is the first routing domain through which the service data packet passes, an entry node can be set for that routing domain. The entry node is the first routing node in the first routing domain that receives the service data packet.

[0070] It is understandable that a routing domain can be a routing autonomy domain or an autonomous routing domain. In a routing autonomy domain, when the first device in the domain receives an MPLS data packet sent by the source node, it can be identified as the ingress node, i.e., the data ingress device (by determining that the previous label ID is not a domain ID through the MPLS label). The domain ingress device needs to interpret the additional routing requirements of the data packet.

[0071] It should be noted that this embodiment can be applied to SR-MPLS scenarios. SR (Segment Routing) adopts a source path selection mechanism, pre-encapsulating the SID (SegmentIdentifier) ​​assigned by the nodes the path will pass through at the source node. When a packet passes through an SR node, the node forwards the packet according to the packet's SID. Except for the source node, other nodes do not need to maintain path state.

[0072] SR-TE (Segment Routing-Traffic Engineering) is a new type of TE tunneling technology that uses SR as the control protocol. It distinguishes between strictly explicit and loosely explicit paths. It is primarily implemented through Adjacency SID or AdjacencySID + Node SID.

[0073] Reference Figure 3 , Figure 3 The diagram illustrates label allocation. IGPSR capabilities are enabled on devices PE1, P1, P2, P3, P4, and PE2, establishing neighbor relationships between them. For IGP instances using SR capabilities, SR adjacency labels are assigned to all outgoing interfaces with the IGP protocol enabled. These adjacency labels are then flooded throughout the network via IGP's SR protocol extension. As shown in the diagram, taking device P3 as an example, the specific process of IGP label allocation is as follows:

[0074] PE1, P1, P2, P3, and P4 allocate and publish adjacency labels according to the P3 method, generating a label forwarding table. After the device and the controller are configured with the BGP-LS protocol and a neighbor relationship is established, BGP-LS imports the topology with SR label information and reports it to the controller.

[0075] by Figure 4 This section uses an example to illustrate the data forwarding process of SR-MPLS TE in the adjacency label mode. Figure 4 The diagram illustrates data forwarding. The controller calculates the SR-MPLS TE tunnel path as ABCDEF, corresponding to two label stacks: {1003, 1006, 100} and {1005, 1009, 1010}. These are then distributed to the ingress node A and the adjacent node C, respectively. Label 100 is the adjacent label, associated with label stack {1005, 1009, 1010}, while the others are adjacency labels.

[0076] As can be seen from the above description, by manually specifying the adjacent labels, the device will forward the data hop-by-hop strictly according to the explicit path specified in the label stack. Therefore, this is also called the strict path method of SR-MPLS TE.

[0077] However, SR-MPLS TE with strict path mode cannot perform load balancing when equivalent paths exist. Introducing node labels into the SR-MPLS TE path can make up for the above deficiency.

[0078] The manual label assignment of node labels and adjacency labels allows for the specification of node labels across network elements. The controller sends these labels to the first node of the repeater via PCEP or NETCONF. Based on this label stack, the repeater searches for the interface labels hop by hop and pops them out to guide the forwarding of data packets to the tunnel destination address.

[0079] Step S20: Parse the service data packet to obtain the tag information carried in the service data packet.

[0080] It should be noted that this embodiment is for an SR-MPLS scenario, referring to... Figure 5 , Figure 5 This is a schematic diagram of data packet transmission in this embodiment. The controller, based on service requirements, security considerations, or other routing policy requirements, determines the routing nodes and patch active routing autonomy domains through which the data needs to pass, and sends them to end node A. End node A then encapsulates the data with an SR-MPLS header field. For example... Figure 5 As shown, the routing path for service 1 determined by the controller is: Device A - Routing Autonomous Domain X - Device F. Two of these paths are: Device A - Routing Autonomous Domain X - Device's actual selectable path. Within the autonomous routing area, data is transmitted through these two paths, determined by the autonomous routing domain X.

[0081] It is understandable that business data packets can be data packets obtained by encapsulating the header fields of the original data packets sent by the controller by the end node, or data packets forwarded by routing nodes of other adjacent domains.

[0082] Step S30: Transmit the service data packet in the routing domain based on the label information.

[0083] It should be noted that after receiving a service data packet, the ingress device parses the service data packet and determines whether the service data packet carries service requirement information based on the parsing result. If it does not carry service requirement information, the service data packet is transmitted in the routing domain based on the tag information.

[0084] It is understood that the sending node of the service data packet includes the source node, which encapsulates the header field of the received raw data packet and sends the encapsulated service data packet to the ingress node; the sending node of the service data packet can also be a routing node in the autonomous routing domain, such as other routing nodes in the routing domain and / or other routing nodes in the previous routing domain.

[0085] Furthermore, in order to accurately determine whether a routing node is an ingress node, the following steps are included before step S30:

[0086] Extract the tag identifier carried in the service data packet based on the tag information;

[0087] Determine whether the label identifier is an intra-domain identifier of the routing domain to which the routing node belongs;

[0088] If the label identifier is not an intra-domain identifier, then the routing node is determined to be the first node in its routing domain to receive the service data packet, and the step of transmitting the service data packet in the routing domain based on the label information is executed;

[0089] If the label identifier is an intra-domain identifier, then it is determined that the routing node is not the first node in its routing domain to receive the service data packet, and the step of transmitting the service data packet in the routing domain based on the label information is executed.

[0090] It should be noted that the first node in the routing domain to receive the service data packet can be the ingress node. The aforementioned label identifier can be a label ID and / or a label SID, etc. The aforementioned domain identifier can be the identifier of a node within an autonomous routing domain.

[0091] Understandably, a routing node can determine whether the previous node is a node in the routing domain to which it belongs (i.e., whether the previous node is a node in its own domain) based on the tag information carried in the service data packet. If it is not a node in its own domain, then the routing node itself is determined to be the first entry node in the routing domain to receive the service data packet. The entry node needs to interpret the service requirement information in the service data packet in order to perform path planning in the routing domain.

[0092] For example, a routing node can determine that the previous label ID / SID is not the ID of its own domain based on the MPLS label / SRv6 segment list in the service data packet, thereby determining that it is the first node device in its own domain to receive the data packet.

[0093] Furthermore, to improve routing transmission efficiency, the following steps are included before step S30:

[0094] Determine whether the service data packet carries a service data path;

[0095] If the service data path is not carried, the routing node is determined to be the first node in its routing domain to receive the service data packet, and the step of transmitting the service data packet in the routing domain based on the tag information is executed;

[0096] If the service data path is carried, it is determined that the routing node is not the first node in its routing domain to receive the service data packet, and the service data packet is transmitted based on the service data path.

[0097] It should be noted that the sending node of a service data packet can be either the source node or a routing node in the previous routing domain. When the sending node of a service data packet is a routing node in the previous routing domain, the current routing domain is the routing autonomy domain to which the packet is passed. In this case, the routing autonomy domain to which the packet is passed does not set specific ingress and egress nodes. When the first node device in the routing autonomy domain receives the data packet, it can determine that it is the first node device in its autonomy domain to receive the data packet based on the MPLS label / SRv6 Segment list, and thus interpret the routing requirement information carried by the data packet.

[0098] It is understandable that when a routing node determines that it is the first node in its routing domain to receive a service data packet, it generates a service data path (i.e., the transmission path of the service data packet in the routing domain) based on the demand information carried in the service data packet and the local policy information of the routing domain. When a routing node determines that it is not the first node in its routing domain to receive a service data packet, it transmits the service data packet based on the behavior information or path information carried in the service data packet.

[0099] Furthermore, in order to flexibly route and transmit service data packets, the following steps are included before step S30:

[0100] Step S31: Determine whether the service data packet carries service requirement information based on the parsing result;

[0101] Step S32: If the service data packet carries service requirement information, then the service data packet is transmitted in the routing domain based on the service requirement information;

[0102] Step S33: If the service data packet does not carry service requirement information, then perform the step of transmitting the service data packet in the routing domain based on the tag information.

[0103] It should be noted that after receiving data from the ingress device, the ingress device needs to interpret the additional routing requirements of the data packets. The domain ingress device processes business data as follows:

[0104] If the data packet does not carry additional routing requirement information, it is forwarded to the next routing segment or autonomous routing area slice indicated by the next label, based on the label information in the MPLS label.

[0105] If the data packet carries additional routing requirement information, such as in the 20 bits of the MPLS header label, the ingress device combines the service's routing requirement information within its routing autonomy domain with local policy information for the routing area to determine the path of the service data. It then implements data routing within the autonomy domain by extending the MPLS header field, adding an MPLS label, or adding an outer MPLS header. Alternatively, data forwarding can be performed through the routing configuration table that is updated in real-time within the switches of the routing autonomy domain.

[0106] Furthermore, in order to effectively meet the service requirements for data transmission and to flexibly transmit data, step S32 above may include:

[0107] Step S321: Obtain the local routing requirement information and local policy information of the routing domain;

[0108] Step S322: Determine the business data path based on the business requirement information, the local routing requirement information, and the local policy information;

[0109] Step S323: Transmit the service data packet in the routing domain based on the service data path.

[0110] It should be noted that, in scenarios where data packets carry additional routing requirement information, the method for identifying the routing autonomous system and its routing requirements at the source node is illustrated below:

[0111] The source node carries the patch routing home domain identification information in the first x bits of the 20-bit MPLS label of the data packet, and carries the routing requirements information of the service in the routing home domain in the last 20-x bits of the 20-bit MPLS label, such as whether the minimum latency, minimum jitter, shortest path, highest reliability and / or security requirements are required.

[0112] Furthermore, in order to improve data transmission efficiency, step S323 above may include:

[0113] Step S3231: Expand the header field of the service data packet based on the service data path;

[0114] Step S3232: Transmit the service data packet in the routing domain based on the extended header field of the service data packet.

[0115] It should be noted that the source node encapsulates the data before sending it, referring to... Figure 6 , Figure 6 This is a diagram illustrating data encapsulation, where X represents the identification information of the routing home domain. In MPLS, the routing home domain information is identified by extending the MPLS label type.

[0116] Understandably, referring to Figure 7 , Figure 7 This is a diagram illustrating header field extension. The ingress device extends the MPLS label of the service data packet based on the service data path, and transmits the service data packet in the routing domain based on the extended header field of the service data packet.

[0117] Furthermore, in order to accurately expand the header field of the service data packet, step S3231 above may include:

[0118] The nodes to be traversed in the routing domain are determined based on the business data path;

[0119] Obtain the node label information of each node to be traversed;

[0120] The header field of the service data packet is expanded based on the node label information.

[0121] It is understandable that routing ingress devices in an autonomous domain achieve data routing within the autonomous free domain by adding MPLS labels, as referenced. Figure 8 , Figure 8This diagram illustrates the encapsulation process during data forwarding within a sharded routing autonomous domain in an SR-MPLS scenario. The left side shows the encapsulation of data packets received by the ingress node device of routing autonomous domain X from the source node. The right side shows the encapsulation of the data packets determined by the ingress node device of routing autonomous domain X, based on the service's routing requirements within the routing autonomous domain and the local policy information of the routing area. Among these encapsulations, 1006, 1005, 1009, and 1010 represent the adjacency label information that the ingress node of the routing autonomous domain determines needs to traverse within the routing autonomous domain.

[0122] This embodiment is applied to the entry node in a routing domain, which is the first node in the routing domain to receive service data packets. This embodiment receives service data packets, parses them to obtain the tag information carried in the service data packets, and transmits the service data packets in the routing domain based on the tag information. Because this embodiment parses service data packets through the entry node and transmits them in the routing domain based on the tag information carried by the service data packets, it effectively improves the security and flexibility of data packet transmission in the routing domain and effectively avoids path failure problems caused by node failures within the routing domain.

[0123] refer to Figure 9 , Figure 9 This is a flowchart illustrating a second embodiment of a routing data transmission method according to the present invention.

[0124] Based on the first embodiment described above, in this embodiment, the sending node of the service data packet further includes a routing node in the previous routing domain, wherein the routing node in the previous routing domain is a routing node in the adjacent domain of the routing domain that forwards the service data packet.

[0125] When the sending node is a routing node in the previous routing domain, the routing data transmission method further includes:

[0126] Step S40: Receive service data packets sent by the routing node in the previous routing domain;

[0127] Step S50: Parse the service data packet to obtain the tag information carried in the service data packet;

[0128] Step S60: Based on the parsing result, determine whether the service data packet carries the local routing requirement information of the previous routing domain;

[0129] Step S70: If the service data packet carries local routing requirement information of the previous routing domain, then the header field of the service data packet is re-encapsulated.

[0130] Step S80: If the service data packet does not carry local routing requirement information of the previous routing domain, the service data packet is transmitted in the routing domain based on the label information.

[0131] It should be noted that this embodiment can be applied to SRv6 scenarios. SRv6 (Segment Routing IPv6) is a next-generation IP bearer protocol defined by the IETF, which is SR (Segment Routing) + IPv6. SRv6 refers to implementing SR based on the IPv6 forwarding plane. SRv6 explicitly specifies the forwarding path of an IPv6 packet by inserting a routing extension header SRH (Segment Routing Header) into the IPv6 packet and adding the SIDs of all segments the path will traverse (i.e., a SID List) to the SRH. It adopts existing IPv6 forwarding technology and achieves network programmability through flexible IPv6 extension headers.

[0132] This forwarding process demonstrates that SRv6 forwarding is simpler and clearer than SR-MPLS. During packet forwarding, SRv6 does not require popping segments; instead, it uses the SL field in the SRH as a pointer to the active segment, updates the destination address in the IPv6 header to the active segment in the segment list, and forwards the packet according to standard IPv6 routing. When there are nodes in the network that do not support SRv6, these nodes can perform standard IPv6 forwarding based on the packet's destination address. This means that SRv6 can achieve seamless compatibility with existing IPv6 networks, allowing for incremental deployment on traditional IPv6 networks without replacing all existing network equipment.

[0133] It should be understood that in this embodiment, the controller determines the routing nodes and patchwork active routing autonomy domains through which data needs to pass, based on business requirements, security considerations, or other routing policy requirements, and sends them to end node A. End node A then encapsulates the SRH header field. (Refer to...) Figure 10 , Figure 10 This is a schematic diagram of data transmission within a routing autonomous domain in this embodiment. The routing path for service 1 determined by the controller is: Device A - Routing Autonomous Domain X - Routing Autonomous Domain Y - Device O. (Refer to...) Figure 11 , Figure 11 This is a diagram illustrating the encapsulation of data by an end node, where X and Y represent the identification information of the routing home domain. In SRH, the information of the routing home domain is identified by extending the SID.

[0134] Within a routing autonomous domain, the first device in the domain to receive an SRV6 data packet sent by the source node can be identified as the data ingress device (by checking the SRv6 Segment list to ensure the previous SID is not from this domain). The domain ingress device needs to interpret additional routing requirements for the data packet. The ingress device processes service data as follows:

[0135] If the data packet does not carry additional routing requirement information, it will be forwarded to the next SID-indicated route segment or autonomous routing area segment based on the Segment list information in SRV6.

[0136] If the data packet carries additional routing requirement information, such as in the current Segment List or in the TLV field of the SRV6, the ingress device combines the service's routing requirement information within the routing autonomy domain and the local policy information of the routing area to determine the path of the service data. This is achieved by extending the SRV6 header field, adding a SID, or adding an outer SRV6 header to implement data routing within the autonomous domain. Alternatively, data forwarding can be performed through the routing configuration table that is updated in real-time within the switch of the routing autonomy domain.

[0137] Understandably, in scenarios where data packets carry additional routing requirement information, the following is an example of how SRv6 data packets identify the routing autonomy and the routing requirements of the routing autonomy at the source node:

[0138] Method a: The source node carries the patch routing home domain identifier information in the SID's Locator field, and carries the service's routing requirements information in the routing home domain in the Function or Arguments field, such as whether the minimum latency, minimum jitter, shortest path, highest reliability and / or security requirements are required.

[0139] Method b: The source node carries the patch routing home domain identifier information in the SID, and carries the service's routing requirements information in the routing home domain in the Optional Type LengthValue objects field, such as whether the minimum latency, minimum jitter, shortest path, highest reliability and / or security requirements are required.

[0140] The following is an example of how SRv6 packets are forwarded within a routing autonomy domain:

[0141] Method a: Routing the autonomous domain ingress device achieves autonomous free domain data routing by adding a domain-specific SID to the SRV6 header field. The domain-specific SID can be a user-defined identifier within the domain or the IPv6 address of a device within the domain; this invention does not impose any limitations. For example... Figure 12 As shown, Figure 12This is a diagram illustrating message encapsulation. The SRV6 message encapsulation on the left is the message encapsulation determined by the source node based on the controller, where X and Y represent the routing autonomy domains that the source node needs to traverse. The SRV6 message encapsulation on the right is the message encapsulation determined by the ingress device node of routing autonomy domain Y, which combines the service's routing requirements within the routing autonomy domain with the local policy information of the routing area to determine the path of the service data. Here, x1, x2, and x3 represent the SID information of the devices that the ingress node of the routing autonomy domain needs to traverse within the routing autonomy domain.

[0142] Method b: Routing within an autonomous domain ingress device achieves data routing within the autonomous free domain by adding an outer SRV6 header. For example... Figure 13 As shown, Figure 13 To illustrate the addition of an outer header, the encapsulation of the SRV6 packet on the left is the packet encapsulation determined by the source node based on the controller, where X and Y represent the routing autonomy domains that the source node needs to traverse. The encapsulation of the SRV6 packet on the right is the secondary SRv6 header encapsulation performed by the ingress device node of routing autonomy domain Y, combining the service's routing requirements within this routing autonomy domain and the local policy information of this routing area, to determine the path of the service data. Here, x1, x2, and x3 represent the SID information of the devices that the ingress node of the routing autonomy domain determines need to traverse within the routing autonomy domain. The destination address in the IPv6 packet header can be either the X field identifier or the address of the next-hop device x2 for forwarding data from the ingress device in routing autonomy domain X.

[0143] This embodiment receives service data packets sent by routing nodes in the previous routing domain, parses the service data packets to obtain the tag information carried in the service data packets, and determines whether the service data packets carry local routing requirement information of the previous routing domain based on the parsing result. If the service data packets carry local routing requirement information of the previous routing domain, the header field of the service data packets is re-encapsulated. If the service data packets do not carry local routing requirement information of the previous routing domain, the service data packets are transmitted in the routing domain based on the tag information. This improves the flexibility of routing path selection, and takes into account the data detectability brought by security management, the network efficiency improvement brought by load balancing, and the service experience improvement brought by fixed path transmission.

[0144] Furthermore, this embodiment of the invention also proposes a storage medium storing a routing data transmission program, which, when executed by a processor, implements the steps of the routing data transmission method described above.

[0145] Since this storage medium adopts all the technical solutions of all the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.

[0146] Reference Figure 14 , Figure 14 This is a structural block diagram of the first embodiment of the routing data transmission device of the present invention.

[0147] like Figure 14 As shown, the routing data transmission device proposed in this embodiment of the invention includes:

[0148] Data packet receiving module 10 is used to receive service data packets;

[0149] The data packet parsing module 20 is used to parse the service data packet and obtain the tag information carried in the service data packet;

[0150] The data packet transmission module 30 is used to transmit the service data packet in the routing domain based on the tag information.

[0151] Furthermore, the data packet transmission module 30 is also configured to extract the tag identifier carried in the service data packet based on the tag information; determine whether the tag identifier is an intra-domain identifier of the routing domain to which the routing node belongs; if the tag identifier is not an intra-domain identifier, determine that the routing node is the first node in its routing domain to receive the service data packet, and execute the step of transmitting the service data packet in the routing domain based on the tag information; if the tag identifier is an intra-domain identifier, determine that the routing node is not the first node in its routing domain to receive the service data packet, and execute the step of transmitting the service data packet in the routing domain based on the tag information.

[0152] Furthermore, the data packet transmission module 30 is also used to determine whether the service data packet carries a service data path; if it does not carry the service data path, it determines that the routing node is the first node in its routing domain to receive the service data packet, and performs the step of transmitting the service data packet in the routing domain based on the tag information; if it carries the service data path, it determines that the routing node is not the first node in its routing domain to receive the service data packet, and transmits the service data packet based on the service data path.

[0153] Furthermore, the data packet transmission module 30 is also used to determine whether the service data packet carries service requirement information based on the parsing result; if the service data packet carries service requirement information, the service data packet is transmitted in the routing domain based on the service requirement information; if the service data packet does not carry service requirement information, the step of transmitting the service data packet in the routing domain based on the tag information is executed.

[0154] Furthermore, the data packet transmission module 30 is also used to acquire local routing requirement information and local policy information of the routing domain; determine the service data path based on the service requirement information, the local routing requirement information and the local policy information; and transmit the service data packet in the routing domain based on the service data path.

[0155] Furthermore, the data packet transmission module 30 is also used to extend the header field of the service data packet based on the service data path; and to transmit the service data packet in the routing domain based on the extended header field of the service data packet.

[0156] Furthermore, the data packet transmission module 30 is also used to determine the nodes to be traversed in the routing domain based on the service data path; obtain the node label information of each node to be traversed; and expand the header field of the service data packet based on the node label information.

[0157] Furthermore, the sending node of the service data packet includes a source node, which encapsulates the header field of the received raw data packet and sends the encapsulated service data packet to the ingress node.

[0158] Furthermore, the sending node of the service data packet also includes a routing node in the previous routing domain, which is a routing node in an adjacent domain of the routing domain that forwards the service data packet; when the sending node is a routing node in the previous routing domain, the data packet transmission module 30 is also used to receive the service data packet sent by the routing node in the previous routing domain; parse the service data packet to obtain the tag information carried in the service data packet; determine whether the service data packet carries the local routing requirement information of the previous routing domain based on the parsing result; if the service data packet carries the local routing requirement information of the previous routing domain, then the header field of the service data packet is re-encapsulated; if the service data packet does not carry the local routing requirement information of the previous routing domain, then the service data packet is transmitted in the routing domain based on the tag information.

[0159] This embodiment is applied to the entry node in a routing domain, which is the first node in the routing domain to receive service data packets. This embodiment receives service data packets, parses them to obtain the tag information carried in the service data packets, and transmits the service data packets in the routing domain based on the tag information. Because this embodiment parses service data packets through the entry node and transmits them in the routing domain based on the tag information carried by the service data packets, it effectively improves the security and flexibility of data packet transmission in the routing domain and effectively avoids path failure problems caused by node failures within the routing domain.

[0160] It should be understood that the above are merely illustrative examples and do not constitute any limitation on the technical solutions of the present invention. In specific applications, those skilled in the art can make settings as needed, and the present invention does not impose any restrictions on this.

[0161] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this invention. In practical applications, those skilled in the art can select some or all of the workflow to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.

[0162] In addition, for technical details not described in detail in this embodiment, please refer to the routing data transmission method provided in any embodiment of the present invention, which will not be repeated here.

[0163] Furthermore, it should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0164] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0165] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0166] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for routing data transmission, characterized in that, The routing data transmission method is applied to routing nodes in a routing domain; The routing data transmission method includes: Receive service data packets; The service data packet is parsed to obtain the tag information carried in the service data packet; The service data packets are transmitted in the routing domain based on the tag information; Before transmitting the service data packet in the routing domain based on the tag information, the method further includes: Extract the tag identifier carried in the service data packet based on the tag information; Determine whether the label identifier is an intra-domain identifier of the routing domain to which the routing node belongs; If the label identifier is not an intra-domain identifier, then the routing node is determined to be the first node in its routing domain to receive the service data packet, and the step of transmitting the service data packet in the routing domain based on the label information is executed; If the label identifier is an intra-domain identifier, then it is determined that the routing node is not the first node in its routing domain to receive the service data packet, and the step of transmitting the service data packet in the routing domain based on the label information is executed.

2. The routing data transmission method as described in claim 1, characterized in that, Before transmitting the service data packet in the routing domain based on the tag information, the method further includes: Determine whether the service data packet carries a service data path; If the service data path is not carried, the routing node is determined to be the first node in its routing domain to receive the service data packet, and the step of transmitting the service data packet in the routing domain based on the tag information is executed; If the service data path is carried, it is determined that the routing node is not the first node in its routing domain to receive the service data packet, and the service data packet is transmitted based on the service data path.

3. The routing data transmission method as described in claim 1, characterized in that, Before transmitting the service data packet in the routing domain based on the tag information, the method further includes: Based on the parsing results, determine whether the business data packet carries business requirement information; If the service data packet carries service requirement information, the service data packet is transmitted in the routing domain based on the service requirement information; If the service data packet does not carry service requirement information, then the step of transmitting the service data packet in the routing domain based on the tag information is performed.

4. The routing data transmission method as described in claim 3, characterized in that, If the service data packet carries service requirement information, then transmitting the service data packet in the routing domain based on the service requirement information includes: Obtain the local routing requirement information and local policy information of the routing domain; The business data path is determined based on the business requirement information, the local routing requirement information, and the local policy information; The service data packets are transmitted in the routing domain based on the service data path.

5. The routing data transmission method as described in claim 4, characterized in that, The transmission of the service data packet within the routing domain based on the service data path includes: The header field of the business data packet is expanded based on the business data path; The service data packet is transmitted in the routing domain based on the extended header field of the service data packet.

6. The routing data transmission method as described in claim 5, characterized in that, The expansion of the header field of the service data packet based on the service data path includes: The nodes to be traversed in the routing domain are determined based on the business data path; Obtain the node label information of each node to be traversed; The header field of the service data packet is expanded based on the node label information.

7. A routing data transmission device, characterized in that, The routing data transmission device includes: The data packet receiving module is used to receive business data packets; The data packet parsing module is used to parse the service data packet and obtain the tag information carried in the service data packet; A data packet transmission module is used to transmit the service data packet in a routing domain based on the tag information. The data packet transmission module is also used to extract the tag identifier carried in the service data packet based on the tag information; determine whether the tag identifier is an intra-domain identifier of the routing domain to which the routing node belongs; if the tag identifier is not an intra-domain identifier, determine that the routing node is the first node in its routing domain to receive the service data packet, and execute the step of transmitting the service data packet in the routing domain based on the tag information; if the tag identifier is an intra-domain identifier, determine that the routing node is not the first node in its routing domain to receive the service data packet, and execute the step of transmitting the service data packet in the routing domain based on the tag information.

8. A routing data transmission device, characterized in that, The routing data transmission device includes: a memory, a processor, and a routing data transmission program stored in the memory and executable on the processor, the routing data transmission program being configured to implement the routing data transmission method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores a routing data transmission program, which, when executed by a processor, implements the routing data transmission method as described in any one of claims 1 to 6.

Images