Fault notification message transmission method and device, equipment, medium and program product

Abstract

The application provides a fault notification message transmission method and device, equipment, medium and program product, relates to the technical field of communication, and is used for low overhead of fault detection result transmission while meeting low delay. The specific technical scheme is as follows: in the case of receiving a data packet, a segment routing header of the data packet is analyzed to obtain first segment identification information corresponding to a source node device of the data packet, and the first node device is an intermediate node device on a transmission link of the data packet; in the case of detecting a data packet transmission link fault and the first segment identification information indicating that the source node device is configured with a network fault protection function, a fault reverse tunnel between the first node device and the source node device is constructed; a fault notification message is sent to the source node device through the fault reverse tunnel, and the fault notification message is used to indicate the data packet transmission link fault. The application is applied to a fault notification message transmission scene.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus, device, medium and program product for transmitting fault notification messages. Background Technology

[0002] With the evolution of network technology, segment routing IPv6 (SRv6) technology is being used more and more widely in building highly reliable wide area networks. In this technology, the ability to quickly detect and switch over service path failures is crucial to ensuring service continuity.

[0003] Currently, the mainstream implementation involves the business head node sending probe packets along the monitored SRv6 path according to a set period, and then listening for responses from the end of the path within a specified time. If no response is received before the timeout, the head node determines that the path is faulty and performs a switch to the backup path.

[0004] However, in existing technologies, there is a conflict between the real-time performance of fault detection and network overhead. Increasing the detection frequency to reduce fault detection latency generates a massive number of protocol packets, excessively consuming network bandwidth and equipment resources. Conversely, reducing the detection frequency to lower overhead directly increases fault detection latency, failing to meet the rapid recovery requirements of highly reliable services. Thus, existing technologies conflict between the real-time performance of fault detection result transmission and network overhead. How to achieve low latency while maintaining low overhead in fault detection result transmission is a problem that urgently needs to be solved. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and program product for transmitting fault notification messages, which enables low-overhead transmission of fault detection results while ensuring low transmission latency.

[0006] In a first aspect, embodiments of this application provide a method for transmitting fault notification messages, applied to a first node device, the method comprising:

[0007] Upon receiving a data packet, the segment routing header of the data packet is parsed to obtain the first segment identification information corresponding to the source node device of the data packet. The first node device is an intermediate node device on the transmission link of the data packet.

[0008] If the above-mentioned data packet transmission link failure is detected and the above-mentioned first segment identification information indicates that the above-mentioned source node device is configured with network fault protection function, a fault reverse tunnel is constructed between the above-mentioned first node device and the above-mentioned source node device.

[0009] The aforementioned fault notification message is sent to the aforementioned source node device through the aforementioned fault reverse tunnel. The aforementioned fault notification message is used to indicate the aforementioned data packet transmission link failure.

[0010] The technical solution provided in this application brings at least the following beneficial effects: Since intermediate node devices can directly parse the segment routing header of the received service data packets to obtain the first segment identification information corresponding to the source node device, and quickly construct a fault reverse tunnel between the source node device and the source node device when a data packet transmission link failure is detected and the source node device is determined to have network fault protection capabilities, fault notification messages are transmitted point-to-point through this dedicated reverse tunnel. This eliminates the need for additional high-frequency fault detection mechanisms and network-wide flooding of fault information, significantly reducing redundant message interactions and bandwidth resource consumption, and effectively lowering the transmission overhead of fault detection results. Furthermore, this solution relies on real-time triggering of tunnel establishment and fault reporting via service packets, eliminating the need for complex route recalculation and path negotiation processes. Fault information can be quickly transmitted back to the source node, thus avoiding the contradiction in traditional fault transmission schemes where low-latency transmission requires sacrificing network overhead and low-overhead transmission cannot meet real-time requirements. This achieves a balance between low-overhead and low-latency performance in fault detection result transmission.

[0011] In one possible implementation, before the first node device sends a fault notification message to the source node device through the fault reverse tunnel, the fault notification message transmission method provided in this application embodiment further includes:

[0012] A second segment of identification information is generated, which is used to indicate the node device related to the aforementioned data packet transmission link failure.

[0013] A fault notification message is constructed based on the second identifier mentioned above, and the fault notification message carries the second identifier mentioned above.

[0014] Another possible implementation, the fault notification message transmission method provided in this application embodiment further includes:

[0015] When the first node device and the source node device belong to different AS domains, the data packets sent by the source node device through inter-AS domain flooding are received.

[0016] Secondly, embodiments of this application provide a method for transmitting fault notification messages, applied to a source node device, the method comprising:

[0017] Send a data packet, the segment routing header of the aforementioned data packet including a first segment identification information, the aforementioned first segment identification information being used to indicate that the aforementioned source node device is configured with network fault protection function;

[0018] The device receives a fault notification message sent by the first node device through the fault reverse tunnel. The fault notification message is used to indicate a fault in the data packet transmission link. The first node device is an intermediate node device on the data packet transmission link.

[0019] In one possible implementation, the fault notification message carries a second segment of identification information; after receiving the fault notification message sent by the first node device through the fault reverse tunnel, the fault notification message transmission method provided in this application embodiment further includes:

[0020] Parsing the above fault notification message yields the second segment of identification information, which is used to indicate the node device related to the above data packet transmission link failure.

[0021] Based on the second segment of identification information mentioned above, the node devices related to the aforementioned data packet transmission link failure are identified.

[0022] Another possible implementation, after determining the node device related to the data packet transmission link failure based on the second segment of identification information, includes the following fault notification message transmission method provided in this application embodiment:

[0023] Mark all target forwarding paths in the transmission link of the aforementioned data packets that contain node devices related to the aforementioned data packet transmission link failure as unavailable;

[0024] If the aforementioned target forwarding path is currently in use, a path switch will be performed, and an available forwarding path in the transmission link of the aforementioned data packet will be used for data transmission.

[0025] Another possible implementation is to send data packets to the first node device through inter-AS domain flooding when the source node device and the first node device belong to different AS domains.

[0026] Thirdly, embodiments of this application provide a fault notification message transmission apparatus, including:

[0027] The first parsing module is used to parse the segment routing header of the received data packet to obtain the first segment identification information corresponding to the source node device of the data packet, wherein the first node device is an intermediate node device on the transmission link of the data packet.

[0028] The construction module is used to construct a fault reverse tunnel between the first node device and the source node device when the above-mentioned data packet transmission link failure is detected and the above-mentioned first segment identification information indicates that the source node device is configured with network fault protection function.

[0029] The first sending module is used to send a fault notification message to the source node device through the aforementioned fault reverse tunnel. The fault notification message is used to indicate the failure of the aforementioned data packet transmission link.

[0030] In one possible implementation, the aforementioned fault notification message transmission device further includes:

[0031] The generation module is used to generate a second segment of identification information, which is used to indicate the node device related to the aforementioned data packet transmission link failure.

[0032] The construction module is used to construct a fault notification message based on the second segment identifier mentioned above, wherein the fault notification message carries the second segment identifier mentioned above.

[0033] Another possible implementation, the aforementioned fault notification message transmission device further includes:

[0034] The second receiving module is used to receive data packets sent by the source node device through inter-autonomous system domain flooding when the first node device and the source node device belong to different autonomous system domains.

[0035] Fourthly, embodiments of this application provide a fault notification message transmission device, including:

[0036] The second sending module is used to send data packets. The segment routing header of the data packets includes a first segment identification information, which is used to indicate that the source node device is configured with network fault protection function.

[0037] The first receiving module is used to receive a fault notification message sent by the first node device through the fault reverse tunnel. The fault notification message is used to indicate a fault in the data packet transmission link. The first node device is an intermediate node device on the data packet transmission link.

[0038] One possible implementation is that the aforementioned fault notification message carries a second segment of identification information; the fault notification message transmission device provided in this application embodiment further includes:

[0039] The second parsing module is used to parse the above-mentioned fault notification message and obtain the above-mentioned second segment identification information. The above-mentioned second segment identification information is used to indicate the node device related to the above-mentioned data packet transmission link failure.

[0040] The determination module is used to determine the node devices related to the aforementioned data packet transmission link failure based on the second segment of identification information.

[0041] Another possible implementation, the fault notification message transmission device provided in this application embodiment further includes:

[0042] The marking module is used to mark all target forwarding paths in the transmission link of the above-mentioned data packets that contain node devices related to the failure of the above-mentioned data packet transmission link as unavailable;

[0043] The switching module is used to switch paths when the aforementioned target forwarding path is currently in use, and to use an available forwarding path in the transmission link of the aforementioned data packets for data transmission.

[0044] Another possible implementation, the fault notification message transmission device provided in this application embodiment further includes:

[0045] The third sending module is used to send data packets to the first node device through inter-autonomous system domain flooding when the source node device and the first node device belong to different autonomous system domains.

[0046] Fifthly, this application provides a communication system, comprising:

[0047] The source node device is used to perform the fault notification message transmission method as described in any of the second aspects.

[0048] The first node device is used to perform the fault notification message transmission method as described in any of the first aspects.

[0049] In a sixth aspect, this application provides an electronic device comprising: a processor and a memory; the memory storing a program or instructions executable on the processor, wherein the program or instructions, when executed by the processor, implement the methods of the first or second aspect described above.

[0050] In a seventh aspect, this application provides a readable storage medium on which a program or instructions are stored, which, when executed by a computer, implement the methods of the first or second aspect described above.

[0051] Eighthly, this application provides a computer program product that is stored in a storage medium and, when executed by a computer, implements the methods of the first or second aspect described above.

[0052] Ninthly, embodiments of this application provide a chip including a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the methods described in the first or second aspect.

[0053] The beneficial effects of the third to ninth aspects mentioned above are described in the corresponding descriptions of the first or second aspects, and will not be repeated here. Attached Figure Description

[0054] Figure 1 A schematic diagram of the network architecture for an application of a fault notification message transmission method provided in this application embodiment;

[0055] Figure 2A flowchart illustrating a fault notification message transmission method provided in an embodiment of this application;

[0056] Figure 3 A flowchart illustrating another fault notification message transmission method provided in an embodiment of this application;

[0057] Figure 4 A flowchart illustrating another fault notification message transmission method provided in this application embodiment;

[0058] Figure 5 A flowchart illustrating another fault notification message transmission method provided in this application embodiment;

[0059] Figure 6 A flowchart illustrating another fault notification message transmission method provided in this application embodiment;

[0060] Figure 7 A flowchart illustrating another fault notification message transmission method provided in this application embodiment;

[0061] Figure 8 A flowchart illustrating another fault notification message transmission method provided in this application embodiment;

[0062] Figure 9 This application provides a schematic diagram of data interaction for a fault notification message transmission method.

[0063] Figure 10 This application provides a method for fast reverse notification of wide-area faults based on SRv6 End.FR behavior;

[0064] Figure 11 A schematic diagram of a network architecture provided in an embodiment of this application;

[0065] Figure 12 This is a schematic diagram of another network architecture provided in an embodiment of this application;

[0066] Figure 13 A schematic diagram of a fault notification message transmission device provided in an embodiment of this application;

[0067] Figure 14 A schematic diagram of another fault notification message transmission device provided in this application embodiment;

[0068] Figure 15 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0069] The following will describe in detail, with reference to the accompanying drawings, the fault notification message transmission method, apparatus, equipment, medium, and program products provided in this application.

[0070] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0071] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0072] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0073] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0074] The present application provides a method, apparatus, device, medium, and program product for transmitting fault notification messages, which can be applied to fault notification message transmission scenarios.

[0075] In the SRv6 wide area network (WAN) technology field, rapid fault information transmission and path switching are crucial for ensuring highly reliable services. However, existing fault handling technologies have the following significant drawbacks: In existing SRv6 multi-path load balancing or primary / backup transmission scenarios, connectivity detection often relies on Bidirectional Forwarding Detection (BFD) packets. Header nodes periodically send probe packets using SBFD for SRv6 segment list technology to check link reachability. If the head node does not receive a response within the timeout period, it determines that the path is faulty and triggers the backup path. The main problem with the current solution is its over-reliance on Segment Bidirectional Forwarding Detection (SBFD) probe packets. When service volume increases, if the BFD detection time is set too short, such as 10ms, then metropolitan area boundary devices and backbone network points need to forward a large number of BFD packets, resulting in significant overhead. If the BFD detection time is set too long, it leads to excessively long detection cycles, hindering rapid failover.

[0076] To address the aforementioned technical issues, this application provides a method, apparatus, device, medium, and program product for transmitting fault notification messages. In this solution, the intermediate node device can directly parse the segment routing header of the data packet to obtain the first segment identification information corresponding to the source node device when receiving the service data packet. When a data packet transmission link failure is detected and it is determined that the source node device has network fault protection function, a fault reverse tunnel between the intermediate node device and the source node device is quickly constructed. The fault notification message is transmitted point-to-point through this dedicated reverse tunnel. There is no need to deploy a high-frequency fault detection mechanism or flood the entire network with fault information, which greatly reduces redundant message interaction and bandwidth resource occupation, and effectively reduces the transmission overhead of fault detection results. At the same time, this solution relies on the real-time triggering of tunnel establishment and fault reporting by the service packet, without the need for complex route recalculation and path negotiation processes. Fault information can be quickly transmitted back to the source node. Therefore, it avoids the contradiction in traditional fault transmission schemes where low-latency transmission requires sacrificing network overhead and low-overhead transmission cannot meet real-time requirements, thus balancing low-overhead and low-latency performance in fault detection result transmission.

[0077] The following description, in conjunction with the accompanying drawings, details the fault notification message transmission method, apparatus, device, medium, and program products provided in the embodiments of this application.

[0078] Figure 1 This illustration shows a network architecture for a fault notification message transmission method provided in an embodiment of this application. For example... Figure 1 As shown, the network architecture includes multiple node devices 101.

[0079] In some embodiments, the node device 101 may be a server, a computer, or a processor or processing unit, routing device, etc., within a server or computer. The server may be a single server or a server cluster consisting of multiple servers. It should be noted that the specific device form of the node device 101 is not limited in the embodiments of this application. Figure 1 The example shown is a single routing device, node device 101.

[0080] In some embodiments, the source node device is configured to send data packets, the segment routing header of which includes first segment identification information indicating that the source node device is configured with network fault protection; and to receive fault notification messages sent by intermediate node devices through a fault reverse tunnel, the fault notification messages indicating a fault in the data packet transmission link, wherein the intermediate node devices are intermediate node devices on the data packet transmission link. Upon receiving a data packet, the intermediate node device is configured to parse the segment routing header of the data packet to obtain first segment identification information corresponding to the source node device of the data packet, wherein the intermediate node device is an intermediate node device on the data packet transmission link; and, upon detecting a fault in the data packet transmission link and the first segment identification information indicating that the source node device is configured with network fault protection, to construct a fault reverse tunnel between the first node device and the source node device; and to send a fault notification message to the source node device through the fault reverse tunnel, the fault notification message indicating a fault in the data packet transmission link.

[0081] It should be noted that the network architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As network architectures evolve, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0082] See Figure 2 This is a flowchart illustrating a fault notification message transmission method provided in an embodiment of this application. Figure 2 As shown, the fault notification message transmission method provided in this application embodiment is applied to the first node device and can be implemented by the above-mentioned fault notification message transmission device, specifically including the following steps 201 to 203.

[0083] Step 201: When the first node device receives the data packet, it parses the segment routing header of the data packet to obtain the first segment identification information corresponding to the source node device of the data packet. The first node device is an intermediate node device on the transmission link of the data packet.

[0084] In some embodiments, the first segment identification information is located in the segment list of the segment routing header of the data packet, and is used to identify whether the source node device has the ability to receive, parse, and process fault notification messages and path switching.

[0085] In some embodiments, the segment routing header is an IPv6 routing extension header, a dedicated control header for SRv6 packets, used to carry path forwarding related control information, and is the core header carrier for implementing segmented forwarding and fault information transmission. The segment list is an ordered set of segment identifiers stored inside the segment routing header, composed of multiple segment identifiers with different functions arranged sequentially, used to plan the complete end-to-end forwarding transmission path of packets.

[0086] In some embodiments, after receiving an SRv6 data packet, the first node device first identifies and parses the segment routing header in the packet, reads the segment list stored in the segment routing header, and extracts the first functional segment identifier of the corresponding source node device from the segment list. This identifier is the first segment identifier information, thereby determining whether the source node has configured fault protection related functions.

[0087] Step 202: When the first node device detects the above-mentioned data packet transmission link failure and the above-mentioned first segment identification information indicates that the above-mentioned source node device is configured with network fault protection function, the first node device constructs a fault reverse tunnel between the first node device and the above-mentioned source node device.

[0088] In some embodiments, the first node device establishes a direct fault reverse tunnel between itself and the source node device based on the IP address of the source node device indicated by the first segment of identification information.

[0089] In some embodiments, if the first node device carries the service traffic of multiple source node devices, a fault reverse tunnel is established with each source node device based on the corresponding segment identification information.

[0090] In some embodiments, if the segment identification information carried by the data packets sent by multiple source node devices is the same, a source node device is selected to establish a fault reverse tunnel with the first node device according to the proximity of each source node device to the first node device in the topology. For example, the source node device closest to the first node device is selected to establish a fault reverse tunnel.

[0091] In some embodiments, the first node device monitors the operating status of the local interface and associated links in real time to determine whether the data packet transmission link is faulty.

[0092] Step 203: The first node device sends a fault notification message to the source node device through the aforementioned fault reverse tunnel. The fault notification message is used to indicate the failure of the aforementioned data packet transmission link.

[0093] In some embodiments, the packet transmission link fault association behavior, one type of fault association behavior segment identification information, is encapsulated in the packet payload of the aforementioned fault notification message. The packet payload is the data portion following the segment routing header, carrying the actual service data or fault indication information. It is not part of the forwarding control header and is only parsed and used by the destination processing node.

[0094] In some embodiments, combined with Figure 2 ,like Figure 3 As shown, before step 203, the fault notification message transmission method provided in this application embodiment further includes steps 301 and 302:

[0095] Step 301: The first node device generates a second segment of identification information, which is used to indicate the node device related to the above-mentioned data packet transmission link failure.

[0096] In some embodiments, the second segment of identification information corresponds to the execution behavior associated with a failure in the data packet transmission link.

[0097] Step 302: The first node device constructs a fault notification message based on the second segment identifier mentioned above, and the fault notification message carries the second segment identifier mentioned above.

[0098] Thus, by including the identifier of the execution behavior associated with the failure of the data packet transmission link in the fault notification message as the second segment of identification information, the fault-related node device and its specific forwarding operation can be directly and accurately indicated, which significantly improves the efficiency and accuracy of SRv6 network fault location and greatly shortens the time for fault investigation and service recovery.

[0099] In the fault notification message transmission method provided in this application, since the intermediate node device can directly parse the segment routing header of the data packet to obtain the first segment identification information corresponding to the source node device when receiving the service data packet, and quickly build a fault reverse tunnel between the source node device and the source node device when a data packet transmission link failure is detected and it is determined that the source node device has network fault protection function, the fault notification message is transmitted point-to-point through this dedicated reverse tunnel. There is no need to deploy a high-frequency fault detection mechanism or flood the entire network with fault information, which greatly reduces redundant message interaction and bandwidth resource occupation, and effectively reduces the transmission overhead of fault detection results. At the same time, this scheme relies on the real-time triggering of tunnel establishment and fault reporting by the service packet, without the need for complex route recalculation and path negotiation process, and the fault information can be quickly transmitted back to the source node. Therefore, it avoids the contradiction problem in traditional fault transmission schemes where low-latency transmission requires sacrificing network overhead and low-overhead transmission cannot meet real-time requirements, thus taking into account both low-overhead and low-latency performance of fault detection result transmission.

[0100] In some embodiments, combined with Figure 2,like Figure 4 As shown, the fault notification message transmission method may also include the following step 401.

[0101] Step 401: When the first node device and the source node device belong to different AS domains, the first node device receives the data packets sent by the source node device through inter-AS domain flooding.

[0102] In some embodiments, an Autonomous System (AS) is the core routing partitioning unit of the Internet, referring to a set of IP networks that are uniformly controlled by a single management entity and execute the same routing policies.

[0103] In some embodiments, when it is detected that the first node device and the service source node device belong to different AS domains, the source node device uses the BGP protocol as a cross-domain flooding carrier so that the first node device can receive the data packets sent by the source node device through inter-AS domain flooding.

[0104] See Figure 5 This is a flowchart illustrating another fault notification message transmission method provided in an embodiment of this application. Figure 5 As shown, the fault notification message transmission method provided in this application embodiment is applied to the source node device and can be implemented by the above-mentioned fault notification message transmission device, specifically including the following steps 501 to 502.

[0105] Step 501: The source node device sends a data packet. The segment routing header of the data packet includes a first segment identification information, which is used to indicate that the source node device is configured with network fault protection function.

[0106] Step 502: Receive a fault notification message sent by the first node device through the fault reverse tunnel. The fault notification message is used to indicate that the above-mentioned data packet transmission link is faulty. The first node device is an intermediate node device on the transmission link of the above-mentioned data packet.

[0107] It should be noted that a detailed description of the above fault notification message transmission method can be found in the relevant description above, and will not be repeated here.

[0108] In some embodiments, the aforementioned fault notification message carries a second segment of identification information; combined with Figure 5 ,like Figure 6 As shown, the fault notification message transmission method provided in this application embodiment may further include the following steps 601 and 602.

[0109] Step 601: The source node device parses the above fault notification message to obtain the second segment of identification information. The second segment of identification information is used to indicate the node device related to the above data packet transmission link failure.

[0110] Step 602: Based on the second segment of identification information mentioned above, the source node device determines the node device related to the aforementioned data packet transmission link failure.

[0111] It should be noted that a detailed description of the above fault notification message transmission method can be found in the relevant description above, and will not be repeated here.

[0112] In some embodiments, combined with Figure 5 ,like Figure 7 As shown, the fault notification message transmission method provided in this application embodiment may further include the following steps 701 and 702.

[0113] Step 701: The source node device marks all target forwarding paths in the transmission link of the above data packet that contain the node devices related to the above data packet transmission link failure as unavailable;

[0114] In some embodiments, the source node device completes the process by marking the target forwarding path containing the faulty associated node as unavailable in the local SRv6 path forwarding table. This unavailable status indicates that such a path is suspended from participating in data forwarding scheduling and is no longer selected as a service transmission path.

[0115] Step 702: If the target forwarding path is currently in use, the source node device performs path switching and uses the available forwarding path in the transmission link of the data packet for data transmission.

[0116] In some embodiments, path switching by the source node device includes, but is not limited to, using hot standby path switching.

[0117] In some embodiments, combined with Figure 5 ,like Figure 8 As shown, the fault notification message transmission method may further include the following step 801.

[0118] Step 801: When the source node device and the first node device belong to different AS domains, the source node device sends data packets to the first node device through inter-AS domain flooding.

[0119] In some embodiments, data packets are flooded between AS domains based on the IGP protocol so that the first node device can receive data packets across domains.

[0120] In this way, when transmitting data packets across different autonomous system domains, the forwarding method relies on inter-domain flooding, and the information synchronization within the domain is achieved with the help of the IGP protocol. This can ensure smooth transmission of cross-domain data packets and improve the stability and connectivity of cross-domain data interaction.

[0121] See Figure 5This is a flowchart illustrating another fault notification message transmission method provided in an embodiment of this application. Figure 9 As shown, the fault notification message transmission method provided in this application embodiment is applied to the source node device and can be implemented by the above-mentioned fault notification message transmission device, specifically including the following steps S1 to S5.

[0122] S1: Send data packet.

[0123] S2: Upon receiving a data packet, parse the segment routing header of the data packet to obtain the first segment identification information corresponding to the source node device of the data packet.

[0124] S3: If a data packet transmission link failure is detected and the first segment identification information indicates that the source node device is configured with network fault protection function, a fault reverse tunnel is constructed between the first node device and the source node device.

[0125] S4: Send a fault notification message to the source node device through the fault reverse tunnel.

[0126] S5: Receive the fault notification message sent by the first node device through the fault reverse tunnel.

[0127] The following describes the fault notification message transmission method of this application through specific embodiments.

[0128] like Figure 10 As shown in the embodiments of this application, the implementation process of a wide-area fault fast reverse notification method based on SRv6 End.FR behavior includes:

[0129] The device defines End.FR behavior based on its own capabilities and performs intra-domain and inter-domain flooding through protocols such as IGP / BGP.

[0130] In some embodiments, Figure 11 This is a schematic diagram of a network architecture provided in an embodiment of this application. To more clearly explain the above steps, combined with... Figure 11The following illustrative example illustrates this: The device is a node device, and some head nodes in the link (such as R1 and R7, i.e., source node devices) define End.FR behavior (Endpoint for Fault Reporting), which is a network fault protection function. This End.FR behavior, by extending the semantic fields of SRv6 behavior, has two main functions: first, it participates in SRv6 Policy path orchestration and can be included in the path list as the first-hop behavior; second, it identifies the head node's ability to receive, parse, and handle fault signals and path switching. After the head node generates End.FR behavior, it is flooded within the domain via the IGP protocol and between domains via the BGP protocol to ensure that all intermediate nodes, i.e., first-node devices, can obtain this End.FR behavior and the corresponding head node address information. In scenarios where services are carried by SRv6 policies, End.FR behavior participates in path orchestration.

[0131] In some embodiments, combined with Figure 11 The following exemplary description is provided: After receiving service messages or data packets carried by the SRv6 policy, the intermediate node parses the Segment List in the SRH header, filters out the End.FRbehaviour, and identifies the nearest End.FR behavior (i.e., the End.FR behavior of the head node corresponding to the service traffic) based on the path topology. The intermediate node automatically triggers the establishment of an SRv6 fault reverse tunnel (the tunnel type can be selected as SRv6 BE or SRv6 Policy) with this End.FR behavior as the destination IP for subsequent directed transmission of fault information. If the intermediate node carries service traffic from multiple head nodes, it identifies the corresponding End.FRbehaviour for each and establishes an independent fault reverse tunnel.

[0132] Intermediate nodes parse the SRH header in the SRv6 Policy to analyze the capabilities of upstream and downstream nodes.

[0133] In some embodiments, combined with Figure 11The following exemplary description is provided: Intermediate nodes monitor the operational status of their local interfaces and associated links in real time. When a link failure (such as an interruption in the link between R4 and R6) or a node failure is detected, the associated SRv6 behavior (such as R4.END.X behavior corresponding to the failed link) is extracted, and a fault notification message is constructed. The payload of this message carries the fault-associated behavior. The constructed fault notification message is encapsulated as an SRv6 BE or SRv6 policy message. The last hop of the SRv6 policy is set to the previously identified End.FR behavior. In the SRv6 BE scenario, the destination IP of the message is encapsulated as End.FR, and the message is sent to a node capable of processing the message. After receiving the SRv6 fault notification message, the head node parses the SRH header and finds that the destination behavior is the local End.FR behavior. It then pops the SRH header and extracts the fault-associated behavior (such as R4.END.X) from the payload. The head node searches for all local SRv6Policy paths, filters out paths containing the behavior associated with the fault, marks them as unavailable, and immediately triggers hot standby path switching to achieve rapid service recovery.

[0134] Thus, by supporting device-defined End.FR behavior and cross-domain flooding, intermediate node SRH parsing to establish reverse tunnels, local fault detection and notification, and upstream and downstream capability analysis, the accuracy and recovery speed of cross-domain fault detection in SRv6 networks are significantly improved.

[0135] In some embodiments, combined with Figure 11 A specific scenario for transmitting fault notification messages is given, including: Figure 11 The network architecture is as follows: head nodes R1 and R7, intermediate nodes R2, R3, R4, and R5, and destination node R6; R1's SRv6 policy path includes the primary path {R1.END.X,R2.END.X,R4.END.X,R6.End} and the backup path {R1.End.FR,R1.END.X (to R3),R3.END.X,R4.END.X,R6.End}; R7's SRv6 policy path includes the primary path {R7.End.FR,R7.END.X,R2.END.X,R4.END.X,R6.End} and the backup path {R7.End.FR,R1.END.X (to R3),R2.END.X,R4.END.X,R6.End}.

[0136] For example, R1 generates End.FR behavior (R1.End.FR), and R7 generates End.FR behavior (R7.End.FR). R1 ​​and R7 flood their respective End.FR behaviors within the domain through the IGP protocol, and R2, R3, R4, and R5 all obtain these two behaviors and their corresponding head node information. After receiving the service message from R1, intermediate node R4 parses the Segment List ({R1.End.FR, R1.END.X, R2.END.X, R4.END.X, R6.End}) in the SRH header, identifies the nearest End.FR behavior as R1.End.FR, and automatically triggers the establishment of an SRv6 BE fault reverse tunnel pointing to R1.End.FR; after receiving the service message from R7, R4 parses the Segment List ({R7.End.FR,R7.END.X, R2.END.X, R4.END.X, R6.End}) in the SRH header, identifies the nearest End.FR behavior as R7.End.FR, and establishes an independent fault reverse tunnel pointing to R7.End.FR. When a link failure occurs between R4 and R6, R4's fault detection module immediately detects the link interruption and extracts the fault-related behavior as R4.END.X. R4 then constructs fault notification messages for both R1 and R7, with the payload carrying the R4.END.X behavior. R4 encapsulates the fault notification message for R1 into an SRv6 message, with the last hop of the SRH header being R1.End.FR, and sends it to R1 through the corresponding fault reverse tunnel. Simultaneously, R4 encapsulates the fault notification message for R7 into an SRv6 message, with the last hop of the SRH header being R7.End.FR, and sends it to R7 through another fault reverse tunnel. After receiving the message, R1 parses out the fault association behavior R4.END.X, searches the local SRv6 Policy path, and finds that the main path {R1.End.FR, R1.END.X, R2.END.X, R4.END.X, R6.End} contains this behavior. It marks it as unavailable and triggers a hot standby switch to the path {R1.End.FR, R1.END.X (to R3), R3.END.X, R4.END.X, R6.End}.

[0137] Figure 12 This is a schematic diagram of another network architecture provided in an embodiment of this application. Figure 12 This paper specifically demonstrates a cross-AS domain application scenario of the network advertisement message transmission method of this application. Figure 12This diagram illustrates a cross-Autonomous System (AS) network architecture based on L3EVPN over SRv6 policy. It showcases a typical deployment where three independent management domains interconnect across a carrier backbone network to achieve Layer 3 VPN service interconnection, illustrating the application scenarios of SRv6 cross-domain fault detection and notification technology. The diagram includes three autonomous system domains: AS 1000 is the service initiation side intelligent metropolitan area network A, AS2000 is the cross-domain interconnection 169 backbone network, and AS 3000 is the service termination side intelligent metropolitan area network B. All three are controlled by a single management entity and internally run SRv6 intra-domain routing protocols. In terms of network equipment, the CPE, as the user-side access device, is located at the edge of AS 1000, responsible for connecting user service traffic to intelligent metropolitan area network A; PE1 to PE4 are deployed at the boundary between AS 1000 and AS 2000, and PE5 to PE8 are deployed at the boundary between AS 2000 and AS3000, all acting as Autonomous System Border Routers (ASBRs) responsible for the encapsulation and forwarding of SRv6 packets between domains. Key technical identifiers include EPE SID1 and EPE SID2. EPE SID1 is the edge peer endpoint SID of PE1, the side boundary node of AS 1000, used to identify the cross-domain adjacency between PE1 and PE3, guiding SRv6 packets from AS1000 to AS 2000. EPE SID2 is the edge peer endpoint SID of PE7, the side boundary node of AS 3000, used to identify the cross-domain adjacency between PE5 and PE7, guiding SRv6 packets from AS 2000 to AS 3000. Regarding service transport links, the L3EVPN over SRv6 Policy tunnel traversing the three AS domains is an end-to-end service transport tunnel, built based on SRv6 Policy technology, used to carry cross-domain L3VPN service traffic. The Segment List, as a core component of SRv6 Policy, contains a series of ordered SIDs used to specify the hop-by-hop forwarding path of service traffic. The red triangles in the diagram are located at the access point between CPE and Smart Metropolitan Area Network A, and the connection point between PE1 and Smart Metropolitan Area Network A, respectively. These represent key detection locations in the SRv6 network where link or node failures may occur, and are also the locations where fault-related endpoint behaviors are generated. Combined with... Figure 12 An application example is provided, which includes: establishing an end-to-end SRv6 policy across domains using binding sid, where each AS domain provides a binding sid externally. The binding sid can be expanded to include multiple lists. In this scenario, the head node of each AS can also define a behavior of type End.FR, and fault information within the domain can be announced to the head node within the same domain.

[0138] It should be noted that the descriptions of each step in this embodiment can be found in the above embodiments, and will not be repeated here.

[0139] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there is no conflict, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0140] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0141] This application embodiment can divide the fault notification message transmission device into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0142] In some embodiments, this application also provides a fault notification message transmission apparatus. This fault notification message transmission apparatus may include one or more functional modules for implementing the fault notification message transmission method of the above method embodiments.

[0143] For example, Figure 13 This is a schematic diagram of a fault notification message transmission device provided in an embodiment of this application. Figure 13 As shown, the fault notification message transmission device 900 includes: a first parsing module 901, a construction module 902, and a first sending module 903.

[0144] The first parsing module 901 is used to parse the segment routing header of the received data packet to obtain the first segment identification information corresponding to the source node device of the data packet, wherein the first node device is an intermediate node device on the transmission link of the data packet.

[0145] The construction module 902 is used to construct a fault reverse tunnel between the first node device and the source node device when the data packet transmission link failure is detected and the first segment identification information indicates that the source node device is configured with network fault protection function.

[0146] The first sending module 903 is used to send a fault notification message to the source node device through the fault reverse tunnel, the fault notification message being used to indicate the failure of the data packet transmission link.

[0147] In the fault notification message transmission device provided in this application, the intermediate node device can directly parse the segment routing header of the data packet to obtain the first segment identification information corresponding to the source node device when receiving the service data packet. When a fault is detected in the data packet transmission link and it is determined that the source node device has network fault protection function, a fault reverse tunnel between the intermediate node device and the source node device is quickly constructed. The fault notification message is transmitted point-to-point through this dedicated reverse tunnel. There is no need to deploy a high-frequency fault detection mechanism or flood the fault information across the entire network. This greatly reduces redundant message interaction and bandwidth resource occupation, and effectively reduces the transmission overhead of fault detection results. At the same time, this solution relies on the real-time triggering of tunnel establishment and fault reporting by the service packet. There is no need for complex route recalculation and path negotiation process. Fault information can be quickly transmitted back to the source node. Therefore, it avoids the contradiction problem in traditional fault transmission schemes where low-latency transmission requires sacrificing network overhead and low-overhead transmission cannot meet real-time requirements. Thus, it takes into account both low-overhead and low-latency performance of fault detection result transmission.

[0148] In some embodiments, the above-mentioned fault notification message transmission device further includes:

[0149] A generation module is used to generate a second segment of identification information, which is used to indicate the node device related to the data packet transmission link failure.

[0150] A construction module is used to construct a fault notification message based on the second segment identifier, wherein the fault notification message carries the second segment identifier.

[0151] In other embodiments, the above-mentioned fault notification message transmission device further includes:

[0152] The second receiving module is used to receive data packets sent by the source node device through inter-AS domain flooding when the first node device and the source node device belong to different AS domains.

[0153] For example, Figure 13 This is a schematic diagram of another fault notification message transmission device provided in an embodiment of this application. Figure 13 As shown, the fault notification message transmission device 910 includes: a first parsing module 911 and a construction module 912.

[0154] The second sending module 911 is used to send data packets. The segment routing header of the data packets includes a first segment identification information, which is used to indicate that the source node device is configured with network fault protection function.

[0155] The first receiving module 912 is used to receive a fault notification message sent by the first node device through the fault reverse tunnel. The fault notification message is used to indicate that the data packet transmission link is faulty. The first node device is an intermediate node device on the data packet transmission link.

[0156] In some embodiments, the fault notification message carries a second segment of identification information, and the fault notification message transmission device includes:

[0157] The second parsing module is used to parse the fault notification message to obtain the second segment of identification information, which is used to indicate the node device related to the data packet transmission link failure.

[0158] The determination module is used to determine the node device related to the data packet transmission link failure based on the second segment of identification information.

[0159] In other embodiments, the fault notification message transmission device further includes:

[0160] A marking module is used to mark all target forwarding paths in the transmission link of the data packet that contain node devices related to the failure of the data packet transmission link as unavailable;

[0161] The switching module is used to switch paths when the target forwarding path is currently in use, and to use an available forwarding path in the transmission link of the data packet for data transmission.

[0162] In some other embodiments, the fault notification message transmission device includes:

[0163] The third sending module is used to send data packets to the first node device through inter-AS domain flooding when the source node device and the first node device belong to different AS domains.

[0164] It should be noted that the fault notification message transmission device can implement all the processes implemented in the above method embodiments and achieve the same beneficial effects. To avoid repetition, it will not be described again here.

[0165] In the case where the functions of the integrated modules described above are implemented in hardware, this application provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 15 As shown, the electronic device 90 includes: a processor 92, a communication interface 93, and a bus 94. Optionally, the electronic device 90 may also include a memory 91.

[0166] Processor 92 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0167] Communication interface 93 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0168] The memory 91 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0169] As one possible implementation, the memory 91 can exist independently of the processor 92. The memory 91 can be connected to the processor 92 via a bus 94 and is used to store instructions or program code. When the processor 92 calls and executes the instructions or program code stored in the memory 91, it can implement the fault notification message transmission method provided in the embodiments of this application.

[0170] In another possible implementation, memory 91 can also be integrated with processor 92.

[0171] Bus 94 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 94 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 15 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0172] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0173] This application embodiment also provides a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the above. Fault notification message transmission method The various processes in the embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0174] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0175] This application also provides a readable storage medium storing a program or instructions, which, when executed by a computer, implements the fault notification message transmission method provided in the above embodiments. It is understood that all or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; the readable storage medium can be any of the foregoing embodiments or memory; the readable storage medium can also be an external storage device of the service invocation device, such as a pluggable hard drive, SmartMedia Card (SMC), Secure Digital (SD) card, flash card, etc., equipped on the service invocation device. Further, the readable storage medium can include both internal storage units of the service invocation device and external storage devices. The readable storage medium is used to store the computer program and other programs and data required by the service invocation device. The readable storage medium can also be used to temporarily store data that has been output or will be output.

[0176] This application also provides a computer program product, which is stored in a storage medium and, when executed by a computer, implements the fault notification message transmission method provided in the above embodiments.

[0177] 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 apparatus 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 apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0178] 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 this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0179] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for transmitting fault notification messages, characterized in that, Applied to a first-node device, the method includes: Upon receiving a data packet, the segment routing header of the data packet is parsed to obtain the first segment identification information corresponding to the source node device of the data packet, wherein the first node device is an intermediate node device on the transmission link of the data packet; If a data packet transmission link failure is detected and the first segment identification information indicates that the source node device is configured with network fault protection function, a fault reverse tunnel is constructed between the first node device and the source node device. A fault notification message is sent to the source node device through the fault reverse tunnel. The fault notification message is used to indicate that the data packet transmission link is faulty.

2. The fault notification message transmission method according to claim 1, characterized in that, Before the first node device sends a fault notification message to the source node device through the fault reverse tunnel, the method further includes: A second segment of identification information is generated, which is used to indicate the node device related to the data packet transmission link failure; A fault notification message is constructed based on the second segment identifier, and the fault notification message carries the second segment identifier.

3. The fault notification message transmission method according to claim 1 or 2, characterized in that, The method further includes: When the first node device and the source node device belong to different autonomous system domains, the data packets sent by the source node device through inter-autonomous system domain flooding are received.

4. A method for transmitting fault notification messages, characterized in that, Applied to a source node device, the method includes: Send a data packet, wherein the segment routing header of the data packet includes a first segment identification information, which is used to indicate that the source node device is configured with a network fault protection function; The system receives a fault notification message sent by a first node device through a fault reverse tunnel. The fault notification message is used to indicate a fault in the data packet transmission link. The first node device is an intermediate node device on the data packet transmission link.

5. The fault notification message transmission method according to claim 4, characterized in that, The fault notification message carries a second segment of identification information; After receiving the fault notification message sent by the first node device through the fault reverse tunnel, the method further includes: Parse the fault notification message to obtain the second segment of identification information, which is used to indicate the node device related to the data packet transmission link failure; Based on the second segment of identification information, the node device related to the data packet transmission link failure is identified.

6. The fault notification message transmission method according to claim 5, characterized in that, After determining the node device related to the data packet transmission link failure based on the second segment of identification information, the method further includes: Mark all target forwarding paths in the transmission link of the data packet that contain node devices related to the failure of the data packet transmission link as unavailable; If the target forwarding path is currently in use, a path switch is performed, and an available forwarding path in the transmission link of the data packet is used for data transmission.

7. The fault notification message transmission method according to any one of claims 4 to 6, characterized in that, When the source node device and the first node device belong to different AS domains, data packets are sent to the first node device through inter-AS domain flooding.

8. A fault notification message transmission device, characterized in that, include: The first parsing module is used to parse the segment routing header of the received data packet to obtain the first segment identification information corresponding to the source node device of the data packet, wherein the first node device is an intermediate node device on the transmission link of the data packet; The construction module is used to construct a fault reverse tunnel between the first node device and the source node device when the data packet transmission link failure is detected and the first segment identification information indicates that the source node device is configured with network fault protection function; The first sending module is used to send a fault notification message to the source node device through the fault reverse tunnel, the fault notification message being used to indicate the failure of the data packet transmission link.

9. A fault notification message transmission device, characterized in that, include: The second sending module is used to send data packets. The segment routing header of the data packets includes a first segment identification information, which is used to indicate that the source node device is configured with network fault protection function. The first receiving module is used to receive a fault notification message sent by the first node device through the fault reverse tunnel. The fault notification message is used to indicate that the data packet transmission link is faulty. The first node device is an intermediate node device on the data packet transmission link.

10. A communication system, characterized in that, The communication system includes: A source node device, the source node device being configured to perform the fault notification message transmission method as described in any one of claims 4-7; The first node device is configured to perform the fault notification message transmission method as described in any one of claims 1-3.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the fault notification message transmission method as described in any one of claims 1-3, or to implement the fault notification message transmission method as described in any one of claims 4-7.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions, which, when executed by a computer, implement the fault notification message transmission method as described in any one of claims 1-3, or implement the fault notification message transmission method as described in any one of claims 4-7.

13. A computer program product, characterized in that, When the product is executed by a computer, it implements the fault notification message transmission method as described in any one of claims 1-3, or implements the fault notification message transmission method as described in any one of claims 4-7.

Images