CN114513429A

CN114513429A - Transmission method for detection message, and method and equipment for determining reverse path

Info

Publication number: CN114513429A
Application number: CN202011165552.XA
Authority: CN
Inventors: 张华�
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-10-27
Filing date: 2020-10-27
Publication date: 2022-05-17

Abstract

The application provides a transmission method of a detection message, a method and equipment for determining a reverse path, and belongs to the technical field of networks. In the process of forwarding the detection message, the intermediate node adds the path information of the reverse path to the detection message, so that the path information of the reverse path is transmitted to the tail node along with the detection message, the tail node is helped to automatically find the reverse path by using the path information in the detection message, and the cost generated by manual deployment or manual planning of the reverse path by a controller is avoided.

Description

Transmission method for detection message, and method and equipment for determining reverse path

Technical Field

The present application relates to the field of network technologies, and in particular, to a transmission method of a detection packet, a method and a device for determining a reverse path.

Background

In many scenarios, the forwarding process of the packet is bidirectional, for example, the forwarding process is divided into two directions, i.e., an uplink direction and a downlink direction, or a forward direction and a backhaul direction, where the uplink direction is sent from the first network device to the second network device, and the downlink direction is sent from the second network device to the first network device. It is generally desirable to keep forwarding paths in both directions as consistent as possible to prevent bidirectional traffic from being carried on links of inconsistent quality.

In the related art, network management personnel may perform configuration operations on a controller, thereby manually deploying a reverse path corresponding to each forwarding path. The controller determines a reverse path according to the configuration operation and issues the reverse path to the network device. And the network equipment receives the reverse path issued by the controller so as to obtain the reverse path.

The method depends on a large amount of manual configuration, wastes time and labor, and influences the efficiency of obtaining the reverse path by the network equipment.

Disclosure of Invention

The embodiment of the application provides a transmission method of a detection message, a determination method of a reverse path and equipment, which can improve the efficiency of obtaining the reverse path by network equipment. The technical scheme is as follows.

In a first aspect, a transmission method of a detection packet is provided, in which a first network device receives a first detection packet, and an intermediate node of a forwarding path of the first detection packet includes the first network device; the first network device adds path information of a reverse path to the first detection packet to obtain a second detection packet, where the transmission directions of the reverse path and the forwarding path are opposite, the reverse path and the forwarding path have the same set of constraints, the constraints include nodes or links, the path information is used to indicate the constraints corresponding to the first network device in the reverse path, and the second detection packet includes the path information; and the first network equipment sends the second detection message.

In the method provided above, the intermediate node adds the path information of the reverse path to the detection packet in the process of forwarding the detection packet, so that the path information of the reverse path is transmitted to the tail node along with the detection packet, thereby helping the tail node determine the reverse path by using the path information in the detection packet. The method supports the tail node to automatically find the reverse path, avoids the expense generated by manual deployment of a controller or manual planning of the reverse path, and reduces the complexity of network configuration, thereby improving the efficiency of obtaining the reverse path.

In a possible implementation manner, the first detection packet includes a destination option header, and the adding, by the first network device, path information to the first detection packet to obtain a second detection packet includes: and the first network equipment adds the path information to a destination option header of the first detection message to obtain the second detection message.

By using the destination option header to record the path information of the reverse path, after receiving the detection message, the unsupported node automatically skips the newly added destination option and continues to process other parts of the message, thereby being beneficial to improving the compatibility.

In a possible implementation manner, the destination option header includes indication information, where the indication information is used to indicate that path information of the reverse path is added to the first detection packet.

In a possible implementation manner, the path information includes an internet protocol version 6 segment routing end point segment identifier srv6end.sid, and the adding, by the first network device, the path information to the first detection packet to obtain a second detection packet includes:

and if the destination address of the first detection message is a local end.SID, the first network device adds the local end.SID to the first detection message, wherein the local end.SID is a type of SRv6end.SID used for identifying the first network device.

And when the destination address is the local end.SID, adding the local end.SID to the detection message, so that the node constrained in the forward direction is consistent with the node constrained in the return direction, and the accuracy of path restoration is improved.

In a possible implementation manner, the path information includes SRv6 end-point three-layer cross-connect segment identifier end.x SID, and the adding, by the first network device, the path information to the first detection packet to obtain a second detection packet includes: if the destination address of the first detection packet is a local end.X SID, the first network device adds an opposite end end.X SID to the first detection packet, where the local end.X SID is SRv6end.X SID used to identify a three-layer connection from the first network device to a second network device, and the opposite end end.X SID is SRv6end.X SID used to identify a three-layer connection from the second network device to the first network device.

By adding the local end.X SID to the detection message under the condition that the destination address is the local end.X SID, the constrained link in the outbound direction is consistent with the constrained link in the return direction, and the accuracy of path restoration is improved.

In a possible implementation manner, before the first network device adds peer device information to the first detection packet, the method further includes: and the first network equipment queries a Traffic Engineering Database (TEDB) according to the local end.X SID to obtain an opposite end end.X SID corresponding to the local end.X SID, wherein the TEDB stores a corresponding relation between the local end.X SID and the opposite end end.X SID.

The intermediate node can obtain the information of the link of the intermediate node and the opposite end through the TEDB to further complete the task of adding the path information without requiring an end-to-end view angle, so that the implementation scheme of the cross-domain forwarding scene is supported, and the application scene is richer.

In a possible implementation manner, the first detection packet uses one of the following protocol packets: the method comprises the steps of Bidirectional Forwarding Detection (BFD) messages, operation, maintenance and management (OAM) detection messages, channel-associated OAM performance measurement iFit messages based on internet protocol data flow, bidirectional active measurement protocol (TWAMP) detection messages and internet packet explorer ping detection messages.

By the method, the consistency of the back-and-forth paths of the BFD message, the OAM detection message, the iFit message, the TWAMP detection message and the ping detection message can be ensured, and the back-and-forth flow is prevented from being borne on different paths respectively to cause the error detection of the BFD, the OAM, the iFit, the TWAMP and the ping.

In a second aspect, a method for determining a reverse path is provided, in which a network device receives a detection packet, a tail node of a forwarding path through which the detection packet passes is the network device, the detection packet includes path information of the reverse path, the reverse path and the forwarding path have opposite transmission directions, the reverse path and the forwarding path have a same set of constraints, and the constraints include nodes or links; and the network equipment determines the reverse path according to the path information.

In the method provided above, the tail node can automatically and accurately acquire the reverse path by using the path information carried in the detection packet, thereby avoiding the overhead generated by manual deployment of the controller or manual planning of the reverse path, and reducing the complexity of network configuration, thereby improving the efficiency of acquiring the reverse path.

In a possible implementation manner, after the network device determines the reverse path according to the path information, the method further includes: the network equipment generates a response message, wherein the response message is used for responding to the detection message, the response message comprises a Segment Routing Header (SRH), and a segment list in the SRH is used for indicating the reverse path; and the network equipment sends the response message.

In a possible implementation manner, after the network device receives the detection packet, the method further includes: the network device sends the path information to a controller in a network.

In a possible implementation manner, the detection packet includes a first destination option header, and the first destination option header includes path information of the reverse path.

In a possible implementation manner, the detection packet includes a segment routing header SRH, and the first destination option header precedes the SRH.

In a possible implementation manner, the detection packet includes a second destination option header, where the second destination option header includes service information, where the service information is used to indicate an attribute of the forwarding path or a service carried by the detection packet, and after the network device receives the detection packet, the method further includes: and the network equipment carries out service processing according to the service information.

In a possible implementation manner, the detecting packet includes a second destination option header, the second destination option header includes service information, and the service information is color information, priority information, or a descriptor, and the generating, by the network device, the response packet includes: and the network equipment encapsulates the response message according to the service information.

In a possible implementation manner, the detection packet includes a payload, and the second destination option header is before the payload and after the SRH.

In one possible implementation, the constraint of the reverse path is part of the constraint of the forwarding path.

In a third aspect, a method for transmitting a detection packet is provided, in which a network device generates a detection packet, a head node of a forwarding path of the detection packet is the network device, the detection packet includes path information of a reverse path, a transmission direction of the reverse path is opposite to that of the forwarding path, the reverse path and the forwarding path have a same set of constraints, the constraints include nodes or links, and the path information is used to indicate a constraint corresponding to the network device in the reverse path; and the network equipment sends the detection message.

In the method provided above, the head node helps the tail node to determine the reverse path by using the path information in the detection message by carrying the path information of the reverse path in the detection message, which helps the tail node to automatically find the reverse path, avoids the overhead generated by manual deployment of a controller or manual planning of the reverse path, and reduces the complexity of network configuration, thereby improving the efficiency of obtaining the reverse path.

In a possible implementation manner, the first destination option header includes indication information, where the indication information is used to indicate that path information of the reverse path is added to the detection packet.

In a possible implementation manner, the detection packet includes a second destination option header, where the second destination option header includes service information, and the service information is used to indicate an attribute of the forwarding path or a service carried by the detection packet.

In a possible implementation manner, the generating, by the network device, the detection packet includes:

and when the forwarding path is established for the first time or when the forwarding path is changed, the network equipment generates the detection message.

In a fourth aspect, there is provided a network device having functionality to implement the first aspect or any one of the alternatives of the first aspect. The network device comprises at least one unit configured to implement the method provided by the first aspect or any one of the alternatives of the first aspect.

In some embodiments, the unit in the network device provided in the fourth aspect is implemented by software, and the unit in the network device is a program module. In other embodiments, the unit in the network device provided in the fourth aspect is implemented by hardware or firmware. For specific details of the network device provided in the fourth aspect, reference may be made to the first aspect or any optional manner of the first aspect, and details are not described here.

In a fifth aspect, there is provided a network device having functionality to implement any of the alternatives of the second aspect or the second aspect. The network device comprises at least one unit configured to implement the method provided by the second aspect or any of the alternatives of the second aspect.

In some embodiments, the unit in the network device provided in the fifth aspect is implemented by software, and the unit in the network device is a program module. In other embodiments, the unit in the network device provided in the fifth aspect is implemented by hardware or firmware. For specific details of the network device provided in the fifth aspect, reference may be made to the second aspect or any optional manner of the second aspect, and details are not described here.

A sixth aspect provides a network device having functionality to implement the third aspect or any of the alternatives of the third aspect. The network device comprises at least one unit configured to implement the method provided in the third aspect or any of the optional manners of the third aspect.

In some embodiments, the unit in the network device provided by the sixth aspect is implemented by software, and the unit in the network device is a program module. In other embodiments, the unit in the network device provided by the sixth aspect is implemented by hardware or firmware. For specific details of the network device provided in the sixth aspect, reference may be made to the third aspect or any optional manner of the third aspect, which is not described herein again.

In a seventh aspect, a network device is provided, where the network device includes a processor and a communication interface, where the processor is configured to execute instructions to cause the network device to perform the method provided in the first aspect or any one of the alternatives of the first aspect, and the communication interface is configured to receive or send a packet. For specific details of the network device provided in the seventh aspect, reference may be made to the first aspect or any optional manner of the first aspect, and details are not described here again.

In an eighth aspect, a network device is provided, where the network device includes a processor and a communication interface, where the processor is configured to execute instructions to cause the network device to perform the method provided in the second aspect or any optional manner of the second aspect, and the communication interface is configured to receive or send a message. For specific details of the network device provided by the eighth aspect, reference may be made to the second aspect or any optional manner of the second aspect, which is not described herein again.

In a ninth aspect, there is provided a network device, where the network device includes a processor and a communication interface, where the processor is configured to execute instructions to cause the network device to perform the method provided in the third aspect or any optional manner of the third aspect, and the communication interface is configured to receive or send a packet. For specific details of the network device provided in the ninth aspect, reference may be made to the third aspect or any optional manner of the third aspect, and details are not described here.

In a tenth aspect, there is provided a network device, comprising: a main control board and an interface board. The main control board includes: a first processor and a first memory. The interface board includes: a second processor, a second memory, and an interface card. The main control board is coupled with the interface board.

The first memory may be configured to store program code, and the first processor is configured to call the program code in the first memory to perform the following: adding path information of a reverse path to a first detection message to obtain a second detection message, where the transmission directions of the reverse path and the forwarding path are opposite, the reverse path and the forwarding path have the same set of constraints, the constraints include nodes or links, the path information is used to indicate the constraints corresponding to the first network device in the reverse path, and the second detection message includes the path information.

The second memory may be configured to store program code, and the second processor may be configured to invoke the program code in the second memory to trigger the interface card to perform the following: and receiving a first detection message, wherein the intermediate node of the forwarding path of the first detection message comprises the first network equipment. And sending the second detection message.

In a possible implementation manner, an inter-process communication protocol (IPC) channel is established between the main control board and the interface board, and the main control board and the interface board communicate with each other through the IPC channel.

In an eleventh aspect, a network device is provided, which includes: a main control board and an interface board. The main control board includes: a first processor and a first memory. The interface board includes: a second processor, a second memory, and an interface card. The main control board is coupled with the interface board.

The second memory may be configured to store program code, and the second processor may be configured to invoke the program code in the second memory to trigger the interface card to perform the following: receiving a detection message, wherein a tail node of a forwarding path passed by the detection message is the network device, the detection message includes path information of a reverse path, the transmission direction of the reverse path is opposite to that of the forwarding path, the reverse path and the forwarding path have the same set of constraints, and the constraints include nodes or links.

The first memory may be configured to store program code, and the first processor is configured to call the program code in the first memory to perform the following: and determining the reverse path according to the path information.

In a possible implementation manner, an IPC channel is established between the main control board and the interface board, and the main control board and the interface board communicate with each other through the IPC channel.

In a twelfth aspect, a network device is provided, which includes: a main control board and an interface board. The main control board includes: a first processor and a first memory. The interface board includes: a second processor, a second memory, and an interface card. The main control board is coupled with the interface board.

The first memory may be configured to store program code, and the first processor is configured to call the program code in the first memory to perform the following: generating a detection message, wherein a head node of a forwarding path of the detection message is the network device, the detection message includes path information of a reverse path, a transmission direction of the reverse path is opposite to that of the forwarding path, the reverse path and the forwarding path have a same set of constraints, the constraints include nodes or links, and the path information is used for indicating the constraints corresponding to the network device in the reverse path.

The second memory may be configured to store program code, and the second processor may be configured to invoke the program code in the second memory to trigger the interface card to perform the following: and sending the detection message.

In a thirteenth aspect, a computer-readable storage medium is provided, in which at least one program code is stored, and when the program code is executed by a computer (e.g. a first network device), the computer (e.g. the first network device) is caused to execute the method provided by the first aspect or any one of the alternatives of the first aspect.

In a fourteenth aspect, a computer-readable storage medium is provided, wherein at least one program code is stored in the storage medium, and when the program code is executed by a computer (such as a network device), the computer (such as the network device) is caused to execute the method provided by the second aspect or any one of the alternatives of the second aspect.

In a fifteenth aspect, a computer-readable storage medium is provided, in which at least one program code is stored, and when the program code is executed by a computer (e.g. a network device), the computer (e.g. the network device) is caused to perform the method provided by the third aspect or any one of the alternatives of the third aspect.

In a sixteenth aspect, a computer program product is provided that includes computer instructions stored in a computer readable storage medium. The processor of the network device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, so that the network device performs the method provided by the first aspect or any one of the alternatives of the first aspect.

In a seventeenth aspect, a computer program product is provided that includes computer instructions stored in a computer-readable storage medium. The processor of the network device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions to cause the network device to perform the method provided by the second aspect or any of the alternatives of the second aspect.

In an eighteenth aspect, a computer program product is provided that includes computer instructions stored in a computer readable storage medium. The processor of the network device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the network device to perform the method provided by the third aspect or any of the alternatives of the third aspect.

In a nineteenth aspect, there is provided a chip, which when run on a network device, causes the network device to perform the method provided in the first aspect or any of the alternatives of the first aspect.

In a twentieth aspect, there is provided a chip which, when run on a network device, causes the network device to perform the method as provided in the second aspect or any one of the alternatives of the second aspect.

In a twenty-first aspect, there is provided a chip, which when run on a network device, causes the network device to perform the method provided in the third aspect or any one of the alternatives of the third aspect.

A twenty-second aspect provides a network system, where the network system includes the network device of the fourth aspect, the seventh aspect, or the tenth aspect, the network system further includes the network device of the fifth aspect, the eighth aspect, or the eleventh aspect, and the network system further includes the network device of the sixth aspect, the ninth aspect, or the twelfth aspect.

Drawings

Fig. 1 is a schematic architecture diagram of a network system 10 according to an embodiment of the present application;

fig. 2 is a schematic diagram of a message format according to an embodiment of the present application;

fig. 3 is a schematic diagram of a message format according to an embodiment of the present application;

fig. 4 is a schematic diagram of a message format according to an embodiment of the present application;

FIG. 5 is a flow chart of a method 200 provided by an embodiment of the present application;

fig. 6 is a schematic view of a scenario for forwarding a packet according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a network device 300 according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a network device 400 according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a network device 500 according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a network device 600 according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a network device 700 according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a network system 800 according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

With the evolution of networks and the introduction of Software Defined Networking (SDN) concepts, multi-protocol label switching (MPLS) technology has evolved to segment multi-protocol for label switching (SR MPLS). Conventional MPLS offers many advantages, such as end-to-end service emulation, Virtual Private Network (VPN) isolation, etc. At the same time, however, MPLS also has many inherent drawbacks, such as label forwarding is not intuitive to humans, and MPLS requires end-to-end hardware to support MPLS forwarding, creating a Data Center (DC) barrier to pull-through, and servers/switches do not support MPLS. Meanwhile, as the address resource pool of the internet protocol version four (IPv 4) of the public network is exhausted, the address of the internet protocol version six (IPv 6) of the terminal/video and data service (OTT) is accelerated, and a technology capable of inheriting the advantages of MPLS is required and the inherent defects of MPLS are solved. In view of the above, the SRv6 technology has been developed, which brings the following three advantages.

In a first aspect, SRv6 inherits the advantages of SR-MPLS. Specifically, SRv6 and SR-MPLS belong to a Segment Routing (SR) architecture, and SRv6 inherits the advantages of protocol simplification, topology-independent loop-free backup (TI-LFA)/micro-ring avoidance, traffic engineering, and SDN-oriented centralized deployment of SR-MPLS.

In a second aspect, the SRv6 technology supports large-scale networking and provides rich programming capabilities. The intermediate node only needs to support IPv6native forwarding and does not need to support SRv6, so that the SRv6 technology has good compatibility. SRv6 has natural advantages in pulling across the network, such as SRv6 from the carrier network into a DC scenario, etc.

In a third aspect, SRv6 provides SRv6 Segment Identification (SID) to identify target, content and service functions through definition of 128-bit IPv6 address, which provides possibility of application and network deep integration, so SRv6 technology has stronger innovation capability.

Returning to the traffic itself, most traffic is bi-directional, such as upstream or downstream. The requirements of Key Performance Indicators (KPIs) in two directions are usually consistent, so that the service paths in the two directions are usually required to be as consistent as possible, which can prevent bidirectional traffic from being carried on links with inconsistent quality.

In addition, with the large-scale application of traffic engineering in a network, that is, a service tunnel in a general sense, in order to implement fast protection of a service, it is also necessary to perform fast detection on a forwarding path through a detection protocol such as Bidirectional Forwarding Detection (BFD), so as to complete protection at a carrier level. Therefore, the return path and the outbound path of the detection message are required to be consistent, and the error detection of the service caused by the link failure which is not on the forwarding path is reduced.

To ensure consistency between the return and outbound paths, some studies have attempted to manually deploy using a controller or manually specify a strongly planned path. However, there are many drawbacks to this approach. Firstly, the deployment cost is high, manual strong planning is needed, and deployment errors are easy to occur. Second, customized development is required for various business models, and the controller deeply participates in business issuing in all directions. Third, for unidirectional tunnels and the like, reverse tunnels must be explicitly deployed, wasting device resources.

In some embodiments of the present application, a method for automatically discovering a backhaul path (i.e., a reverse path) under SRv6 networking is provided, by which the backhaul path (i.e., the reverse path) can be automatically learned based on traffic, and it is ensured that forward and reverse paths are consistent.

Specifically, the head node sends a detection packet. The intermediate node adds the path information of the reverse path to the designated position of the detection message, so that the detection message carrying the path information of the reverse path is transmitted to the tail node. The tail node can automatically and accurately acquire the reverse path by using the path information carried by the detection message. In addition, the tail node can further process deeply according to the learned reverse path. In this way, only a small amount of detection messages are sent by one service to complete path detection and sensing. The device cost is low, and other protocol extension support is not needed.

The concept of reverse path (reverse path) according to the present embodiment will be described below.

The reverse path is a path that is common to the forwarding path and is opposite in transmission direction to the forwarding path. In this embodiment, the reverse path discovered by the device and the forwarding path have the same set of constraints (constraints).

Constraints include nodes or links. For example, in the SR technique, a segment list (segment list) in a message indicates part or all of constraints of a path, and a segment (segment) in the segment list indicates one constraint of the path. For example, in SRv6 technology, the segment is SRv6SID, and the type of SRv6SID includes End (End), End with layer-3cross-connect (end.x), and the like. An SRv6SID of type End indicates the constraint corresponding to the node. An SRv6SID of type end.x indicates the constraint corresponding to the link.

In some embodiments, the tail node of the reverse path is the same device as the head node of the forwarding path. The tail node of the forwarding path and the head node of the reverse path are the same device. For example, the head node of the forwarding path is device a, the tail node of the forwarding path is device B, and the forwarding path is a path from device a to device B. In contrast, the head node of the reverse path is device B, the tail node of the reverse path is device a, and the reverse path is a path from device B to device a.

In some embodiments, the constraints of the reverse path are all the same as the constraints of the forwarding path. In particular, the reverse path has all the same intermediate nodes as the forwarding path. The reverse path has all the same links as the forwarding path. For example, the forwarding path is device a → device C → device D → device E → device B, and the reverse path is device B → device E → device D → device C → device a.

In other embodiments, the constraints of the reverse path are part of the constraints of the forwarding path. In particular, the reverse path has intermediate nodes that are partially identical to the forwarding path. The reverse path has partially the same links as the forwarding path. For example, the number of nodes of the reverse path may be less than the number of nodes of the forwarding path. For example, when a part of nodes on the forwarding path do not support the path information for adding the reverse path, the discovered reverse path may not include the part of nodes. In other words, for a part of nodes that do not support adding path information of a reverse path, the part of nodes appears in a forwarding path and is skipped in the reverse path. For example, if the forwarding path is device a → device C → device D → device E → device B, and device D does not support the path information for adding the reverse path, the discovered reverse path may be device B → device E → device C → device a.

The system operating environment provided by the embodiment of the present application is described below with reference to fig. 1.

Fig. 1 is a schematic architecture diagram of a network system 10 provided in an embodiment of the present application. The network system 10 includes RTA, RTB, RTC, RTD, RTE, RTF, RTG, RTH, and RTI. RTA, RTB, RTC, RTD, RTE, RTF, RTG, RTH, RTI are all network devices. The network device is for example a switch or a router. The network device is, for example, a physical device or a virtualized device.

A tunnel T is created in the network system 10. The head node of tunnel T is RTA. The intermediate nodes of the tunnel T are RTB, RTC and RTD. The tail node of the tunnel T is RTE. The transmission direction of the tunnel T is from RTA to RTE. The tunnel T is used to transmit the detection packet from the RTA to the RTE.

In some embodiments, network system 10 is an SRv6 network. The network devices in the network system 10 are all enabled SRv6, in other words, the RTA, RTB, RTC, etc. devices are all SRv6 nodes.

Specifically, the RTA is used to add SRH to the detection message. Segment list in SRH indicates that RTB, RTC, RTD and RTE need to be passed through on the forwarding path. The Destination Address (DA) field in the basic IPv6 header in the detection message indicates the next node that the detection message needs to reach. When receiving the detection message, the RTC or RTD queries a local SID table (local SID table) according to a destination address of a DA field in the detection message. When the destination address of the message is matched with the SID in the local SID table, it is confirmed that the destination address hits the local SID table, and the RTB, the RTC or the RTD will execute corresponding operation based on the hit SID, subtract 1 from SL, and update the value of the DA field to the next SID, so that the detection message is forwarded to the RTE.

Wherein, RTA, RTB, RTC, RTD and RTE respectively store local SID table. The local SID list on each device includes at least one SRv6 SID. For example, the SRv6SID implementing a tunnel T includes END (B), end.X (CD), end.X (DE), END (E). The SRv6 SIDs that implement the reverse path of tunnel T include End.X (ED), end.X (DC), end (B), and end (A).

In the following, some SIDs involved in the tunnel T and the reverse path of the tunnel T are explained in detail.

The local SID table of the RTA holds END (A). In other words, end (a) is SRv6SID local to the RTA. Sid of end (a) type is end. END (A) is used to identify the RTA. In some embodiments, the RTA issues end (a) to other devices in the network system 10 except the RTA through a routing protocol, so that the other devices forward the packet with the destination address of end (a) to the RTA in the process of routing and addressing.

The local SID table of the RTB holds END (B). In other words, end (b) is SRv6SID local to the RTB. The type of end (b) is end. END (B) is used to identify the RTB. In some embodiments, the RTB issues the end (b) to other devices in the network system 10 except the RTB through a routing protocol, so that the other devices forward the packet with the destination address of end (b) to the RTB in the process of routing and addressing.

The local SID table of the RTC holds the end.X (CD). In other words, end.x (CD) is SRv6SID local to the RTC. The type of end.x (CD) is end.x SID. X (CD) is used to identify the three-layer connection from RTC to RTD. And an output interface bound by the end.X (CD) is an output interface connected with the RTD on the RTC. The next hop for end.x (CD) binding is RTD. In some embodiments, the RTC issues the end.x (CD) to other devices in the network system 10 other than the RTC through the routing protocol, so that the other devices forward the packet with the destination address of the end.x (CD) to the RTC in the process of routing and addressing.

The local SID table for RTDs holds the end.x (DE) and end.x (DC). In other words, end.x (DE) and end.x (DC) are SRv6 SIDs local to RTDs. Both the end.x (DE) and end.x (DC) types are end.x SID. X (DE) is used to identify a three-layer connection from RTD to RTE. And the output interface bound by the end.X (DE) is the output interface connected with the RTE on the RTD. The next hop for end.x (DE) binding is RTE. X (DC) is used to identify the three-layer connection from RTD to RTC. And the output interface bound by the end.X (DC) is the output interface connected with the RTC on the RTD. The next hop bound by end.x (DC) is the RTC. Both end.x (DE) and end.x (DC) are generated and issued by RTDs. In some embodiments, the RTD issues the end.x (DE) and the end.x (DC) to other devices in the network system 10 except the RTD through a routing protocol, so that the other devices forward the packet with the destination address of the end.x (DE) or the end.x (DC) to the RTD in the routing process.

In some embodiments, the RTD advertises (advertises) the end.x (DC) to the RTC. The RTC establishes a correspondence between the end.x (CD) and the end.x (DC), and stores the correspondence between the end.x (CD) and the end.x (DC) in a traffic engineering database (TEDB, also called as a TED or TE topology database). For example, the RTC establishes an entry in the TEDB for end.x (CD) to record the end.x (DC) in the entry. Wherein the announcement may be in the form of flooding.

The local SID table of the RTE holds end (e) and End.x (ED). In other words, end (e) and End.x (ED) are SRv6 SIDs local to the RTE. Sid of end (e) type is end. The type of End.x (ED) is end.x SID. END (E) is used to identify the RTE. X (ED) is used to identify a three-layer connection from RTE to RTD. And an output interface bound by the End.X (ED) is an output interface connected with the RTD on the RTE. The next hop for End.x (ED) binding is RTD. End (e) and End.x (ED) are both generated and published by RTE. In some embodiments, the RTE issues end (e) and End.x (ED) to other devices in the network system 10 except the RTE through a routing protocol, so that the other devices forward a packet with a destination address of end (e) or End.x (ED) to the RTE in the routing process.

In some embodiments, the RTE advertises the End.x (ED) to the RTD. The RTD establishes a corresponding relation between the end.X (DE) and the End.X (ED), and the RTD saves the corresponding relation between the end.X (DE) and the End.X (ED) to the TEDB. For example, the RTD establishes an entry for recording the end.x (DE) in the TEDB, and the RTD records the End.x (ED) in the entry.

Network system 10 supports path discovery and handling for BFD. For example, BFD detection is initiated on the RTA, and BFD messages generated by the RTA are transmitted to the RTE through the tunnel T. By implementing the following method 200, the BFD packet returned by the RTE can be ensured to return to the RTA along the reverse path of the tunnel T, and the BFD detection of the tunnel T is prevented from being affected by a failure on the forwarding path of the tunnel T.

The following describes the message format provided in this embodiment.

Fig. 2 is a schematic diagram of a message format of a detection message. The detection message shown in fig. 2 can be forwarded along the tunnel T in the network system 10 shown in fig. 1.

Referring to fig. 2, the detection message includes a basic IPv6 header (IPv6 header), a destination option 1, an SRH, a destination option 2, and a payload (payload).

There are two kinds of Destination Option Headers (DOH) in the detection message. As shown in fig. 2, a destination option header precedes SRH, and is processed by the node corresponding to each segment, as shown in destination option 1 in fig. 2. Another destination option header is processed by the tail node before the payload, as shown in destination option 2 in fig. 2.

Wherein a destination option header for recording path information is located before the SRH. In addition, traffic information, such as path attributes (color, weight) or descriptors of BFD sessions, traffic Routing Targets (RTs), etc., is recorded before the payload using a destination option header (shown as destination option 2 in fig. 2) so that the tail node acquires the traffic information through the destination option header. That is, the path information is carried in a destination option header (SRH) preceding a Segment Routing Header (SRH). The path attribute or other service information is carried in the destination option header before SRH, and may also be carried in the destination option header before payload.

The format of the whole detection message is introduced above, and the format of the destination option header in the detection message is specifically introduced below.

Fig. 3 is a format diagram of a destination option header. The format of the destination option header shown in fig. 3 is applicable to destination option 1 and destination option 2 in fig. 2. In other words, destination option 1 and destination option 2 in fig. 2 can both be the destination option header shown in fig. 3.

Referring to fig. 3, the destination option header includes a next header (next header) field, a header extended length (Hdr Ext Len, also called header extension length) field, and an option field.

The information carried by the optional fields is checked by the destination node of the message. The destination option header is identified by the value (60) of the next header field in the header immediately preceding the destination option header. In this embodiment, the selectable field carries path information of the reverse path, and the format of the selectable field is specifically described below.

Fig. 4 is a diagram of the format of the selectable fields in the destination options header. The selectable fields in the destination options header in fig. 3 are, for example, the selectable fields shown in fig. 4.

Referring to fig. 4, an optional field adopts a type-length-value (TLV) structure. Specifically, the option fields include an option type (option type) field, an option length (option length) field, and an option data (option data) field.

The top two bits in the option type field define the way the node does not support the destination option header. Specifically, if the value of the highest two bits in the option type field is 00, the node that does not support the destination option skips this option and continues to process the rest of the packet. If the value of the highest two bits in the option type field is 01, the node which does not support the destination option discards the message. If the value of the highest two bits in the option type field is 10, the node that does not support the destination option discards the message, and the node sends a message with "ICMP parameter having problem, code 2" to the source address of the message, where the message points to the option type that cannot be identified, ICMP is Internet Control Message Protocol (ICMP). If the value of the highest two bits in the option type field is 11, the node which does not support the destination option discards the message, and when the destination address of the message is not the multicast address, the node sends a message of 'ICMP parameter has a problem, code is 2' to the source address of the message, and the message points to the option type which cannot be identified.

The third highest bit in the option type field defines whether the option data for the option is modifiable during forwarding. Specifically, when the highest third bit in the option type field is 0, it indicates that the option data is not changeable in the forwarding process. When the highest third bit in the option type field is1, it indicates that the option data can be changed during the forwarding process.

In the present embodiment, the highest three bits of the option type field among the option fields for recording path information are set to 001. For example, the highest three bits of the option type field in the destination option 1 in the detection message shown in fig. 3 are set to 001, so as to indicate that the node that does not support the destination option 1 skips the destination option 1 and continues to process other parts of the message, and the option data in the destination option 1 can be changed during the forwarding process.

The whole package structure of the destination option header is introduced above, and the following describes the destination option 1 and the destination option 2 in detail.

For the destination option header before SRH (i.e. destination option 1 in fig. 2), the option type field in the destination option header takes 8 bits, the highest 3 bits of the 8 bits are fixed to 001, and 001 means not to be discarded and modifiable. The value of the remaining 5 bits of the option type field is pending. The value of the option length field is pending. The format of the option data field is shown in table 1 below, and each time the detection packet passes through a node, a segment list is added to the option data field. The newly added segment list is at the bottom, so that the destination node can directly copy the content of the option data as the segment list in the SRH in the response message. That is, the segment of the corresponding destination node in the SRH of the detection packet is at the top, and the option data of the option header does not need to be adjusted in reverse order.

TABLE 1

segment list[0](128-bit IPv6 Address)
	segment list[1](128-bit IPv6 Address)
segment list[2](128-bit IPv6 Address)

For the destination option header before payload (i.e. destination option 2 in fig. 2), the option type field in the destination option header occupies 8 bits, and the highest 3 bits of the 8 bits are all fixed to 0. The value of the remaining 5 bits of the option type field is pending. The value of the option length field is pending. The option data field includes an address of a header node, color (color) information, and optional information. Wherein the color information is determined by the head node. For example, in the context of SRv6 Traffic Engineering (TE), the color information is a parameter of SRv6 TE policy (policy). The optional information is used for future extensions, e.g. for adding more service parameters.

In some embodiments, the detection message simulates a traffic message, e.g., the payload of the detection message includes traffic data.

The method 200 provided by the embodiment of the present application is described below with reference to fig. 5. Fig. 5 is a flow chart of a method 200 provided by an embodiment of the present application. In some embodiments, the method 200 is used to automatically discover a reverse path to support traffic forwarding bi-directional co-routing.

Method 200 for differentiating between descriptions of different network devices, different network devices are referred to by "first network device", "second network device", and "third network device", respectively. In the method 200, a head node of a forwarding path of a detection packet is a first network device, an intermediate node of the forwarding path of the detection packet includes a second network device, and a tail node of the forwarding path of the detection packet is a third network device. In other words, the first network device plays the role of a head node, the second network device plays the role of an intermediate node, and the third network device plays the role of a tail node.

In some embodiments, the method 200 is applied in SRv6 network, and the first network device is responsible for adding SRH in the detection message. The segment list in the SRH includes the segment corresponding to the second network device, so that the detection packet is forwarded to the second network device.

In some embodiments, the deployment scenario involving the various network devices involved in the method 200 is illustrated in fig. 1. For example, referring to fig. 1, the first network device in the method 200 is an RTA in the network system 10; the second network device in the method 200 is an RTB, RTC, or RTD in the network system 10; the third network device in method 200 is an RTE in network system 10. For example, the forwarding path in the method 200 can be simply expressed as end (a) → end (b) → end.x (CD) → end.x (DE); the reverse path in the method 200 is a reverse path of the tunnel T, and for example, the reverse path in the method 200 may be simply represented as End.x (ED) → end.x (DC) → end (b) → end (a).

The method 200 implements path discovery by way of distributed processing. Specifically, the head node and each hop intermediate node on the forwarding path add path information corresponding to the home terminal to the received detection packet. In other words, every time the detection packet passes through a node, a new path information is added to the detection packet. When the detection packet is transmitted to the end node, the detection packet carries path information corresponding to each node passing along the way. Therefore, the tail node can acquire a complete reverse path according to the path information in the detection message.

Based on this concept, the method 200 involves the actions of adding path information both by the first network device (head node) and by the second network device (intermediate node). In order to distinguish path information describing addition of different devices, in the method 200, path information of a reverse path added by a first network device is referred to as first path information, and path information of a reverse path added by a second network device is referred to as second path information. In addition, since the detection packets sent by the devices on the forwarding path may have differences, in order to distinguish the detection packets sent by different devices, the method 200 refers to the detection packet sent by the first network device as the first detection packet, and refers to the detection packet sent by the second network device as the second detection packet.

The method 200 describes how the intermediate node adds the path information of the reverse path, taking a process of adding the second path information by the second network device as an example. In a forwarding scenario where there are multiple intermediate nodes, each intermediate node may add path information using a process similar to the flow performed by the second network device.

In the method 200, the "first destination option header" refers to a destination option header carrying path information, and the "second destination option header" refers to a destination option header carrying service information. In some embodiments, the path information and the traffic information are located in different destination option headers, respectively. For example, the first destination option header is destination option 1 in fig. 2. The second destination option header is destination option 2 in fig. 2. In other embodiments, the path information and the service information are located in the same destination option header. For example, the first destination option header is destination option 1 in fig. 2. The second destination option header is also destination option 1 in fig. 2.

The method 200 includes steps S210 to S270.

Step S210, the first network device generates a first detection packet.

Step S220, the first network device sends the first detection packet.

Specifically, the first network device encapsulates the first path information into the detection packet to obtain a first detection packet. The first path information is used for indicating a constraint corresponding to the first network device in the reverse path. The first path information is specifically described below with reference to the scene a and the scene B.

Scenario A, scenario of constraint node

Under the condition of restricting the nodes, the forwarding path of the detection message restricts the head node to be the first network equipment. In this embodiment, the path information (first path information) added in the detection packet by the first network device is used to identify the first network device, so that the tail node of the reverse path is also constrained to be the first network device. Then, since the head node of the forwarding path and the tail node of the reverse path are constrained to be the same device (first network device), it is ensured that the node constrained in the backhaul direction under the constrained node scenario is consistent with the node constrained in the backhaul direction.

In some embodiments, the first path information is an Internet Protocol (IP) address of the first network device. For example, when applied to an IPv6 network, the first path information is an IPv6 address of the first network device. For example, when applied to the SRv6 network, the first path information is the local end.sid of the first network device.

Scenario B, scenario of constrained link

In the scenario of constraining links, detecting a forwarding path of a packet constrains a first link to a link between a first network device and a second network device (a first intermediate node). In this embodiment, the path information (first path information) added in the detection packet by the first network device is used to identify the link between the first network device and the second network device, so that the last link in the reverse path is also constrained to be the link between the first network device and the second network device. Then, since the first link in the forwarding path and the last link in the reverse path are constrained to be the same link, it is ensured that the constrained link in the backhaul direction under the constrained link scenario is consistent with the constrained link in the backhaul direction.

For example, an adjacency is established between the first network device and the second network device, and the first path information is any information allocated by the second network device to the adjacency. For example, when applied to the SRv6 network, the first path information is a local end.x SID of the second network device, which is used to identify a three-tier connection from the second network device to the first network device. The end.x SID binds an egress interface on the second network device that is connected to the first network device.

How the first network device obtains the first path information includes various implementations. For example, in the scenario a, the first path information is a local end.sid of the first network device, and the first network device prestores the local end.sid in a local SID table. And in the process of generating the first detection message, the first network equipment obtains the local end. For another example, in the scenario B, the second network device notifies the local end.x SID to the first network device in advance; the first network equipment receives the local end.X SID of the second network equipment, and stores the local end.X SID of the second network equipment in the TEDB; in the process of generating the first detection message, the first network device obtains the local end.x SID from the TEDB. The TEDB stores the corresponding relation between the local end.X SID of the first network equipment and the local end.X SID of the second network equipment.

There are various ways to implement how to carry the first path information in the detection message. In some embodiments, the first path information is carried through a destination option header. For example, the first network device adds a first destination option header before the SRH to obtain the first detection packet. The first detection message comprises an SRH and a first destination option header. The first destination option header precedes the SRH in the first detection message. The first destination option header includes first path information of the reverse path. The first destination option header includes an option data field including first path information. The specific format of the first destination option header can refer to the description of fig. 3 and 4 above.

In some embodiments, the first network device indicates that the intermediate node needs to perform the action of adding the path information of the reverse path by adding indication information in the detection message. Specifically, the first destination option header includes indication information, where the indication information is used to indicate that path information of a reverse path is added to the first detection packet. In some embodiments, the indication information is a type of option in the destination option header. Specifically, the first destination option header includes an option type field, and a value of the option type field is indication information.

In some embodiments, the first network device further adds service information to the detection packet according to service needs, so as to transfer the service information to the tail node along with the detection packet. Wherein, the service information is carried by the destination option header. In one possible implementation, the service information is carried via a destination header before payload. Specifically, the first network device adds a second destination option header before detecting the load of the packet and after SRH, so as to obtain the first detection packet. The first detection message comprises a second destination option header, and the second destination option header comprises service information. The second destination option header is before the payload of the first detection message and after the SRH in the first detection message. The specific format of the second destination option header can refer to the description of fig. 3.

The service information is used to indicate the attributes of the forwarding path. Or, the service information is used to indicate a service carried by the first detection packet. In some embodiments, the traffic information is color information, priority information, or a descriptor. The color information is, for example, a tunnel color. The descriptor is the service identifier. The traffic information may also include an address of the first network device.

The scenarios for the first network device to send the first detection packet include many scenarios, which are exemplified below with reference to scenarios one to two.

In a first scenario, when a forwarding path is first established, a first network device generates and sends a first detection message.

Specifically, when the forwarding path is successfully created, the first network device is triggered to execute the path discovery procedure. The first network device detects the forwarding path by using the detection message by generating and sending the detection message, so that the tail node can conveniently learn the forwarding path by using the received detection message.

In some embodiments, the first network device continuously sends a plurality of detection packets, so as to avoid an influence on the path discovery process caused by packet loss of a single detection packet. For example, the first network device continuously sends 3 detection packets. Taking the detection message as a BFD message as an example, when the BFD session is successfully created and the session state is Up, the first network device continuously sends 3 BFD messages.

And in a second scenario, when the forwarding path changes, the first network device generates and sends a first detection message.

Specifically, if the first network device senses that the forwarding path changes, the first network device resends the detection packet, so that the tail node (third network device) refreshes the forwarding path found in history to the changed forwarding path.

In step S230, the second network device receives the first detection packet.

In step S240, the second network device adds the path information of the reverse path to the first detection packet to obtain a second detection packet.

The second detection packet includes second path information (i.e., path information added by the second network device). The second path information is used to indicate a constraint corresponding to the second network device in the reverse path.

The second network device adds the path information to which position in the detection packet includes various modes. In some embodiments, the second network device adds path information to the destination option header. Specifically, the second network device adds the second path information to the first destination option header of the first detection packet to obtain the second detection packet. The second detection message includes a first destination option header. The first destination option header in the second detection message includes second path information.

The first destination option header comprises an option data field, and the second network device specifically adds the second path information to the option data field of the first destination option header. Correspondingly, after the second network device executes the action of adding the path information, the option data field of the first destination option header in the obtained second detection message includes the second path information.

How to trigger the second network device to perform the adding action of the path information includes various ways. In some embodiments, the second network device obtains indication information from the first destination option header in the first detection message, and performs the step of adding the second path information according to the indication information. For example, the second network device obtains the value of the option type field from the option type field in the first destination option header; and the second network equipment identifies the option type of the first destination option header according to the value of the option type field. If the first destination option header is an option that requires adding path information, the second network device adds the second path information.

The second path information will be specifically described below with reference to the scenario a and the scenario B.

Scenario A, scenario of constraint node

Under the condition of restricting the nodes, detecting the forwarding path of the message to restrict an intermediate node as second network equipment. In this embodiment, the path information (second path information) added in the detection packet by the second network device is also used to identify the second network device, so that an intermediate node of the reverse path is also constrained to be the second network device. Then, since one intermediate node of the forwarding path and one intermediate node of the reverse path are constrained to be the same device (second network device), it is ensured that the node constrained in the backhaul direction under the constrained node scenario is consistent with the node constrained in the backhaul direction.

In some embodiments, the second path information is an IP address of the second network device. For example, when applied to an IPv6 network, the second path information is an IPv6 address of the second network device. Wherein, when the application is in SRv6 network, the second path information is SRv6 SID.

In some embodiments, the second path information is a local end.sid of the second network device. Specifically, after the second network device receives the first detection packet, the second network device obtains the destination address of the first detection packet from a Destination Address (DA) field in an IPv6 header of the first detection packet. And the second network equipment queries the local SID table according to the destination address of the first detection message. If the destination address (destination address in IPv6 header) of the first detection packet is a local end.sid, the second network device adds the local end.sid (second path information) to the option data field in the first destination option header in the first detection packet.

The local end.sid of the second network device refers to a type SRv6end.sid used for identifying the second network device. END is a forwarding behavior in SRv6 network, and end.sid is used to send the message to the corresponding node. The specific definition of END can be found in section 4 of draft-ietf-spring-SRv 6-network-programming-15. With the scenario of this embodiment, the local end.sid added by the second network device is used to send the packet to the second network device.

The local end.sid added by the second network device and the SID carried by the DA field in the first detection message are end.sid used to identify the same intermediate node (second network device), and the specific numerical relationship between the two end.sids includes various cases.

In some embodiments, the local end.sid added by the second network device is the same as the local end.sid carried in the destination address field of the first detection packet. For example, if the second network device finds that the destination address of the first detection packet is the local end.sid, the second network device copies the local end.sid carried by the destination address field in the first detection packet to the option data field in the first destination option header, thereby multiplexing the local end.sid carried by the destination address field as path information of the reverse path. Or, if the second network device finds that the destination address of the first detection packet is the local end.sid, the second network device copies the currently active SID (active SID) in the segment list of the SRH of the first detection packet to the option data field in the first destination option header, thereby multiplexing the SID in the segment list as the path information of the reverse path.

In other embodiments, the local end.sid added by the second network device is different from the local end.sid carried in the destination address field of the first detection packet. For example, if the second network device finds that the destination address of the first detection packet is the local end.sid, the second network device selects another end.sid from the local SID list, and adds the selected end.sid to the option data field in the first destination option header.

Scenario B, scenario of constrained link

In the scenario of constraining the link, the forwarding path of the detection packet constrains the second link to be a link between the second network device and a neighboring node (second intermediate node) of the second network device. In this embodiment, the path information (second path information) added in the detection packet by the second network device is used to identify the link between the second network device and the neighboring node, so that the penultimate link in the reverse path is also constrained to be the link between the second network device and the neighboring node. Then, since the second link in the forwarding path and the penultimate link in the reverse path are constrained to be the same link, it is ensured that the constrained link in the backhaul direction under the constrained link scenario is consistent with the constrained link in the backhaul direction.

In some embodiments, the second path information is SRv6end.x SID. Specifically, the second path information is SRv6end.x SID of the neighbor node of the second network device. For simplicity, the srv6end.x SID of the neighbor node of the second network device will be referred to as the peer end.x SID hereinafter. Specifically, after the second network device receives the first detection packet, the second network device obtains the destination address of the first detection packet from a Destination Address (DA) field in an IPv6 header of the first detection packet. And the second network equipment queries the local SID table according to the destination address of the first detection message. And if the destination address (the destination address in the IPv6 header) of the first detection message is the local end.X SID of the second network equipment, the second network equipment adds the opposite end end.X SID to the first detection message.

The local end.x SID of the second network device is an SRv6end.x SID used to identify a three-tier connection from the second network device to a neighbor node of the second network device. And the end.X is the forwarding behavior in the SRv6 network, and the end.X SID is used for sending out the message through a specified link.

Specific definitions of end.x can be found in section 4 of draft-ietf-spring-SRv 6-network-programming-15.

In combination with the scenario of this embodiment, the local end.sid of the second network device is used to send the packet through a specified link on the second network device. More specifically, the local end.sid of the second network device binds to an egress interface of the second network device, the next hop bound by the local end.sid of the second network device is a neighbor node of the second network device, and the local end.sid of the second network device constrains a link between the second network device and the neighbor node.

The peer end.x SID of the second network device is an SRv6end.x SID local to the neighbor nodes of the second network device. The peer end.x SID is used to identify SRv6end.x SIDs for a three-tier connection from a neighbor node of the second network device to the second network device. In combination with the scenario of this embodiment, the end.x SID is configured to send the packet through a specified link on the neighbor node of the second network device. More specifically, the end end.x SID binds an egress interface of the neighboring node, a next hop bound by the end end.x SID is the second network device, and the end end.x SID restricts a link between the neighboring node and the second network device.

The two concepts of local end.x SID and peer end.x SID are introduced above. In this step, the link identified by the end end.x SID added by the second network device has the relationship that the end points are the same and the directions are opposite to those of the link identified by the local end.x SID carried by the DA field. And the end points of the link identified by the local end.X SID and the opposite end end.X SID are both the second network equipment and the neighbor nodes. The direction of the link identified by the local end.x SID is the direction of the forwarding path of the detection packet, i.e., the direction from the second network device to the neighbor node. The direction of the link identified by the end end.x SID is the direction of the reverse path, i.e. from the neighbor node to the second network device.

How the second network device obtains the peer end.x SID includes various implementations. In some embodiments, the second network device establishes and stores a correspondence between the local end.x SID and the end end.x SID in advance; and the second network equipment determines the opposite end end.X SID corresponding to the local end.X SID according to the local end.X SID and the corresponding relation preserved in advance.

How to construct and store the corresponding relationship between the local end.x SID and the peer end end.x SID includes various ways. In some embodiments, the neighbor node of the second network device advertises the peer end.x SID to the second network device in advance; and the second network equipment receives the end end.X SID and establishes the corresponding relation between the local end.X SID and the end end.X SID. And the second network equipment saves the corresponding relation between the local end.X SID and the opposite end end.X SID to the TEDB. And when the second network equipment receives the first detection message, the second network equipment queries the TEDB according to the local end.X SID to obtain an opposite end end.X SID corresponding to the local end.X SID. For example, a flooding manner is adopted when the neighbor node advertises the end.x SID of the opposite end.

The TEDB stores the corresponding relation between the local end.X SID and the opposite end end.X SID. The peer end.X SID in TEDB may be referred to as P2P-SRv 6-X-SID. Taking the example of the neighbor relationship established between device a and device B, the content related to device a and device B in the TEDB can be simplified and shown as table 2 below. When the second network device is device a, the neighbor node of the second network device is device B. The opposite SID of the second network device is P2P-SRv6-X-SID of device A, i.e. 108:1101:2: 107:0: 0/128. Wherein P2P represents Peer-to-Peer (Peer-to-Peer). The Function in table 2 indicates the Function, i.e., the type of SID. Similarly, when the second network device is device B, the neighbor node of the second network device is device a. The SID at the opposite end of the second network device is P2P-SRv6-X-SID of device B, i.e. 108:1101:1: 103:0: 0/128.

TABLE 2

TEDB	Local link identification	Remote link identification	P2P-SRv6-X-SID	Function
					Device A	696	53	108:1101:2::107:0:0/128	End.X
Device B	53	696	108:1101:1::103:0:0/128	End.X

Here, the local link identifier (link local identifier) in table 2 indicates a local link ID. The link remote identifier (link remote identifier) in table 2 indicates the link ID of the opposite end.

The second network device is taken as an example to describe how the intermediate node adds the path information of the reverse path in the detection message. In some scenarios, a forwarding path of a detection packet passes through a plurality of nodes, and each node adds corresponding path information to the detection packet, so that the detection packet carries multiple pieces of path information.

Under the condition that the detection message carries multiple pieces of path information, the arrangement sequence of the multiple pieces of path information in the detection message comprises multiple implementation modes. In some embodiments, the multiple pieces of path information in the detection message are forward-ordered. The forward direction arrangement means that the path information added later precedes the path information added earlier. For example, when each intermediate node in the forwarding path adds path information, each intermediate node adds its corresponding path information at the forefront of the option data in the first destination option header. Taking two nodes, i.e., a first network device and a second network device, as an example, the first network device is a node through which a detection packet passes first, and the second network device is a node through which a detection packet passes later. The first network equipment adds first path information in an option data field in the detection message, and sends the detection message containing the first path information to the second network equipment. And after the second network equipment receives the detection message, the second network equipment adds second path information before the first path information in the option data field. Therefore, the option data field in the first destination option header of the detection packet sent by the second network device has two pieces of path information, which are the first path information and the second path information, respectively, and the second path information is before the first path information.

The following describes the sequence of multiple pieces of path information in a detection message with reference to the SRv6 scenario. In the SRv6 scenario, the detection packet includes an SRH, where segment list of the SRH includes some SIDs, and the SIDs in the segment list are usually arranged in reverse. For example, the forwarding path is SID1- > SID2- > SID3- > SID4, and in the segment list, SID1 is at the bottom and SID4 is at the top. In this embodiment, the destination option header of the detection packet also includes some SIDs, and the intermediate node further back on the forwarding path puts the SID corresponding to the reverse path at the top. By the sequencing mode, when the tail node receives the detection message, the SID of the reverse path in the detection message can be directly copied into the SRH for forwarding without reordering, so that the processing overhead of the tail node is reduced.

It should be noted that detecting multiple pieces of path information forward permutations of reverse paths in a message is an optional way. In other embodiments, the multiple pieces of path information of the reverse path in the detection message are arranged in a reverse direction, and the tail node determines the reverse path by reordering the multiple pieces of path information in the detection message.

Step S250, the second network device sends a second detection packet.

The above steps S240 and S250 have described the operation of the intermediate node by taking the flow executed by one second network device as an example. In some embodiments, there are a plurality of second network devices in one forwarding path, and each second network device performs the above steps S240 and S250, so that the steps S240 and S250 are performed a plurality of times. The detection packet passes through steps S240 and S250 several times, and then reaches the third network device.

In step S260, the third network device receives the second detection packet.

After the third network device receives the second detection message, the third network device obtains the path information of the reverse path from the second detection message. In some embodiments, the third network device identifies an option data field in a destination option header (a first destination option header) of an outer layer of the second detection packet, and obtains path information of the reverse path from the option data field.

In step S270, the third network device determines a reverse path according to the path information.

Specifically, the path information obtained by the third network device includes first path information added by the first network device and second path information added by the second network device, and the third network device determines the reverse path according to the first path information and the second path information.

How the third network device applies the determined reverse path includes a plurality of scenarios, which is exemplified below in connection with two application scenarios.

And returning a response message by the first network equipment and the third network equipment based on the determined reverse path in the application scene.

For example, the third network device generates a response message according to the reverse path. The third network device sends a response message. Wherein the response message is used for responding to the second detection message. In some embodiments, the response message is an SRv6 message. The response message includes the SRH. The segment list in the SRH of the response message is used to indicate the reverse path.

In some embodiments, the third network device copies the path information of the reverse path in the second detection packet to the segment list of the SRH in the response packet, so as to obtain the response packet. For example, the first destination header in the second detection message includes SID4, SID3, SID2 and SID1, and the third network device copies SID4, SID3, SID2 and SID1 to the segment list in the response message. In other embodiments, the third network device sorts the path information of the reverse path in the second detection message, and then adds the sorted path information to the segment list of the SRH in the response message to obtain the response message.

And the application scene two and the third network equipment report the determined reverse path to the controller.

Specifically, the third network device transmits path information of the reverse path to a controller in the network.

In some embodiments, the third network device also obtains service information from the SRH header or a destination option header (second destination option header) before the payload. And the third network equipment performs service processing according to the service information. The way in which the third network device performs service processing includes many ways. For example, the third network device automatically reports a controller decision, or the third network device automatically creates a tunnel, and so on, i.e. two application scenarios: data packet forwarding, or BFD probing.

In some embodiments, the traffic information is color information, priority information, or a descriptor. After the third network device obtains the color information, the priority information or the descriptor from the second destination option header in the second detection message, the third network device encapsulates the response message according to the color information, the priority information or the descriptor, and sends the response message.

In the method provided by this embodiment, in the process of forwarding the detection packet, the intermediate node adds the path information of the reverse path to the detection packet, so that the path information of the reverse path is transmitted to the tail node along with the detection packet, thereby helping the tail node determine the reverse path by using the path information in the detection packet. The method supports the tail node to automatically find the reverse path, avoids the expense generated by manual deployment of a controller or manual planning of the reverse path, and reduces the complexity of network configuration, thereby improving the efficiency of obtaining the reverse path.

The method 200 is used to support a network device to automatically discover a reverse path. The method 200 can be applied in many scenarios, and some application scenarios supported by the method 200 are exemplified below.

Scene applying scene one and BFD detection

In a BFD detection scenario, detection packets (a first detection packet, a second detection packet, and the like) initiated by the head node and forwarded by the intermediate node in the method 200 are all BFD packets, and a response packet returned by the tail node in the method 200 is a BFD response packet. By implementing the method 200 in the BFD detection scenario, the round-trip paths of the BFD messages can be ensured to be consistent, and BFD false detection caused by the fact that the round-trip flows are respectively carried on different paths is avoided.

Application scene two, scene detected by Operation Administration and Maintenance (OAM)

In the context of OAM detection, detection packets (a first detection packet, a second detection packet, and the like) initiated by a head node and forwarded by an intermediate node in the method 200 are all OAM detection packets, and a response packet returned by a tail node in the method 200 is an OAM detection response packet. By implementing the method 200 in an OAM detection scenario, the consistency of the round-trip paths of the OAM detection messages can be ensured, and the OAM detection error detection caused by the fact that the round-trip traffic is respectively carried on different paths is avoided.

Application scenario three, scenario of in-situ flow information measurement (iFit) detection based on Internet protocol data flow

In the context of iFit detection, detection packets (first detection packet, second detection packet, etc.) initiated by the head node and forwarded by the intermediate node in the method 200 are all iFit packets, and a response packet returned by the tail node in the method 200 is an iFit response packet. By implementing the method 200 in the context of the iFit detection, the consistency of the round-trip paths of the iFit message can be ensured, and the iFit false detection caused by the fact that the round-trip flow is respectively borne on different paths is avoided.

Scene for detecting application scene four and two-way active measurement protocol (TWAMP)

In the context of TWAMP detection, detection packets (a first detection packet, a second detection packet, and the like) initiated by a head node and forwarded by an intermediate node in the method 200 are TWAMP packets, and a response packet returned by a tail node in the method 200 is a TWAMP response packet. By implementing the method 200 in the TWAMP detection scenario, the round-trip paths of TWAMP messages can be ensured to be consistent, and the TWAMP false detection caused by the fact that round-trip traffic is respectively carried on different paths is avoided.

Scene five, scene detected by internet packet explorer (ping)

In the ping detection scenario, the detection messages (the first detection message, the second detection message, and the like) initiated by the head node and forwarded by the intermediate node in the method 200 are all ping messages, and the response message returned by the tail node in the method 200 is a ping response message. By implementing the method 200 in the ping detection scenario, the round-trip paths of the ping message can be ensured to be consistent, and ping misdetection caused by the fact that the round-trip flow is respectively borne on different paths is avoided.

The following illustrates, by way of example, how the above-described method 200 may be applied in a BFD detection scenario.

The following example is applied to the network system 10 shown in fig. 1. The BFD messages in the following example are illustrative of the detection messages in method 200. The RTA in the following example is illustrative of the first network device in method 200. The RTB, RTC or RTD in the following examples are illustrative of the second network device. The RTE in the following example is illustrative of the third network device. In other words, the head node in the forwarding path of the BFD packet is RTA, the middle nodes are RTB, RTC and RTD, and the tail node is RTE. The following examples were carried out as follows.

The RTA performs the following steps A-1 through A-2.

Step A-1, after the BFD session is successfully established according to the original procedure, the state negotiates UP.

Step A-2, after BFD session negotiation UP, RTA continuously initiates 3 BFD messages, the format of BFD messages is as shown in the following table 3.

TABLE 3

The RTB performs the following steps B-1 through B-2.

And step B-1, the destination IP address in the BFD message received by the RTB is END (B), and the RTB adds the local end.SID, namely END (B), to the destination option 1. Wherein, end (b) is end.sid local to RTB. END (B) is used to identify the RTB.

And step B-2, the RTB checks the SRH of the BFD message. The RTB replaces the destination IP address with the next segment in the SRH, i.e., end.X (CD). The RTB decrements SL by 1 and sends to the next hop (RTC). The format of the BFD messages sent on the RTB is shown in table 4 below.

TABLE 4

The RTC performs the following steps C-1 to C-2.

And step C-1, the destination IP address in the BFD message received by the RTC is end.X (CD). The RTC adds end.x (DC) to destination option 1 according to the end.x correspondence. Before executing step C-1, the RTC constructs a corresponding relationship between the local end.x and the end.x of the peer interface in advance.

And step C-2, the RTC checks an SRH head of the BFD message, and the RTC replaces the destination IP address with the next segment in the SRH, namely end.X (DE). The RTC decrements SL by 1 and sends to the next hop. The format of the BFD messages sent on the RTC is shown in table 5 below.

TABLE 5

The RTD performs the following steps D-1 to D-2.

And D-1, the destination IP address in the BFD message received by the RTD is end.X (DE). And the RTD adds the End.X (ED) to the destination option 1 according to the corresponding relation of the end.X (the RTD constructs the corresponding relation of the local end.X and the opposite end interface end.X in advance).

And D-2, the RTD checks an SRH head of the BFD message, the RTD replaces the destination IP address with the next segment in the SRH, the RTD subtracts 1 from SL and sends the SL to the next hop, and the format of the BFD message sent by the RTD is shown in the following table 6.

TABLE 6

The RTE performs the following steps E-1 through E-3.

And E-1, receiving the BFD message by the RTE. The option data of the target option 1 in the BFD message obtained by the RTE includes end (a), end (b), end.x (DC), and End.x (ED). The RTE builds a label stack that includes end (a), end (b), end.x (DC), End.x (ED).

Step E-2, RTE obtains option data of the destination option 2: RTA node address + color + resolver.

And E-3, the RTE associates the BFD session with the label stack, encapsulates the BFD message of the return stroke according to the label stack, and has the format shown in the following table 7.

TABLE 7

By implementing the above example, it can be ensured that the round-trip paths of BFD under SRv6 networking are consistent.

The above scenario of BFD detection is illustrated. The BFD message in the above method may be replaced by an OAM detection message, an iFit message, a TWAMP detection message, or a ping detection message, and the corresponding processing flow is the same as the scene of BFD detection, and is not described herein again.

It should be noted that the above listed application scenarios and types of detection messages are schematic, and the detection messages may be replaced by BFD messages, OAM detection messages, iFit messages, TWAMP detection messages, and other detection messages besides ping detection messages.

The following describes advantageous effects of the above-described scheme in four aspects.

In the first aspect, because the path discovery process is processed in a distributed manner, the whole path information acquisition of the reverse path is realized by adding one hop to each node, and thus the pressure of a single device is small. And the reverse path is determined by the forwarding path of the message, and the path is accurately restored. Specifically, the path information of the reverse path is added by a node constrained in the forwarding path, and the node adds a local end.sid to the detection packet when the destination address of the detection packet is the local end.sid, and adds an opposite end end.x SID to the detection packet when the destination address of the detection packet is the local end.x SID, so that the reverse direction of the scene of the constrained node is also the constrained node, and the reverse direction of the scene of the constrained link is also the constrained link, so that the path detection result is completely consistent with the path forwarding, thereby ensuring accurate path restoration.

In the second aspect, compatibility can be ensured even if some of the nodes do not support it. Specifically, by expanding the destination option header, a type of destination option is newly added, and the path information of the reverse path is recorded using the newly added destination option. Because the highest two bits of the option type of the newly added option are 00, after the unsupported node receives the detection message, the newly added option can be automatically skipped over, and other parts of the message can be continuously processed, so that compatibility can be ensured.

In a third aspect, inter-gateway protocol (IGP) domain and inter-Autonomous System (AS) scenarios are supported natively. Specifically, when the forwarding path spans multiple domains, it is difficult for the nodes to know the end-to-end topology, which results in a difficulty in obtaining path information of the entire reverse path. In this embodiment, the node may complete the task of adding the path information by acquiring the local end.sid or the end.x SID of the opposite node. For example, referring to fig. 6, the tunnel path in the topology shown in fig. 6 is a — F, the tunnel path spans 3 IGP domains, each IGP domain is specifically an intermediate system to intermediate system (ISIS) domain, and the 3 IGP domains are ISIS1, ISIS2, and ISIS3, respectively. Because a distributed processing mode is adopted, each intermediate node only needs to know the information of the link of the intermediate node and the opposite end link, and does not need to have an end-to-end view angle, the limit of cross-IGP scenes on the implementation of the scheme is eliminated to a certain extent.

And fourthly, solving the difficult problem (such as BFD (bidirectional forwarding detection) scene) of round-trip common path of partial scenes and constructing the competitiveness of the product.

The method 200 of the embodiment of the present application is introduced above, and the network device of the embodiment of the present application is introduced below. It should be understood that the various network devices described below each have any of the functionality of the first network device, the second network device, or the third network device of the method 200 described above.

Fig. 7 shows a schematic diagram of a possible structure of the first network device involved in the above embodiment. The network device 300 shown in fig. 7 implements, for example, the function of the first network device in the method 200, or the network device 300 implements the function of the RTA in the network system 10.

Referring to fig. 7, the network device 300 includes a processing unit 301 and a transmitting unit 302. The various elements in network device 300 are implemented in whole or in part by software, hardware, firmware, or any combination thereof. Each unit in the network device 300 is configured to perform the corresponding function of the first network device or RTA in the method 200. The processing unit 301 is configured to support the network device 300 to execute S210. The sending unit 302 is configured to support the network device 300 to execute S220.

The division of the unit in the embodiment of the present application is schematic, and is only a logic function division, and there may be another division manner in actual implementation.

In some embodiments, the various elements of network device 300 are integrated into a single processing unit. For example, the units in the network device 300 are integrated on the same chip. The chip comprises a processing circuit, and an input interface and an output interface which are connected and communicated with the inside of the processing circuit. The processing unit 301 is implemented by processing circuitry in a chip. The sending unit 302 is implemented by an output interface in the chip. For example, the chip may be implemented using one or more field-programmable gate arrays (FPGAs), Programmable Logic Devices (PLDs), controllers, state machines, gate logic, discrete hardware components, any other suitable circuitry, or any combination of circuitry that is capable of performing the various functions described throughout this application.

In other embodiments, the elements of network device 300 exist physically separate. In other embodiments, a portion of the units of the network device 300 exist separately and physically, and another portion of the units are integrated into one unit. For example, in some embodiments, processing unit 301 and sending unit 302 are the same unit. In other embodiments, the processing unit 301 and the sending unit 302 are different units. In some embodiments, the integration of different units is implemented in hardware, i.e. different units correspond to the same hardware. As another example, the integration of the different units is implemented in the form of software units.

In case of being implemented in network device 300 by hardware, processing unit 301 in network device 300 is implemented by, for example, central processor 611 on main control board 610 in network device 600, as well as by processor 701 in network device 700. The sending unit 302 in the network device 300 is implemented, for example, by an interface board 630 in the network device 600, and is also implemented, for example, by a communication interface 704 in the network device 700.

In the case of being implemented by software in the network device 300, each unit in the network device 300 is, for example, software generated by a central processing unit 611 on a main control board 610 in the network device 600 or a processor 701 in the network device 700 reading program codes stored in a memory. For example, network device 300 is a virtualized device. The virtualization device includes, but is not limited to, at least one of a virtual machine, a container, and a Pod. In some embodiments, network device 300 is deployed on a hardware device (e.g., a physical server) in the form of a virtual machine. For example, network device 300 is implemented based on a general physical server in conjunction with Network Functions Virtualization (NFV) technology. When implemented as a virtual machine, the network device 300 is, for example, a virtual host, a virtual router, or a virtual switch. A person skilled in the art can simulate the network device 300 on a general physical server by combining the NFV technology through reading the present application. In other embodiments, network device 300 is deployed on a hardware device in the form of a container (e.g., a docker container). For example, the processes of network device 300 performing the above-described method embodiments are encapsulated in an image file, and the hardware device creates network device 300 by running the image file. In other embodiments, network device 300 is deployed on a hardware device in the form of a Pod. The Pod includes a plurality of containers, each container for implementing one or more functional units in the network device 300.

Fig. 8 shows a schematic diagram of a possible structure of the second network device involved in the above embodiment. The network device 400 shown in fig. 8 implements, for example, the function of the second network device in the method 200, or the network device 400 implements the function of an RTB, RTC, or RTD in the network system 10.

Referring to fig. 8, the network device 400 includes a receiving unit 401, a processing unit 402, and a transmitting unit 403. The various elements in network device 400 are implemented in whole or in part by software, hardware, firmware, or any combination thereof. The respective units in the network device 400 are configured to perform the respective functions of the first network device, RTB, RTC or RTD in the method 200. Specifically, the receiving unit 401 is configured to support the network device 400 to execute S230. The processing unit 402 is configured to support the network device 400 to execute S240. The sending unit 403 is configured to support the network device 400 to execute S250. In some embodiments, processing unit 402 is also used to support network device 400 querying the TEDB.

In some embodiments, the various elements of network device 400 are integrated into a single processing unit. For example, the units in the network device 400 are integrated on the same chip. The chip comprises a processing circuit, and an input interface and an output interface which are connected and communicated with the inside of the processing circuit. The processing unit 402 is implemented by processing circuitry in a chip. The receiving unit 401 is implemented by an input interface in the chip. The sending unit 403 is implemented by an output interface in the chip. For example, the chip may be implemented by one or more FPGAs, PLDs, controllers, state machines, gated logic, discrete hardware components, any other suitable circuitry, or any combination of circuitry capable of performing the various functions described throughout this application.

In other embodiments, the individual elements of network device 400 exist physically separate. In other embodiments, a part of the units of the network device 400 exist separately and physically, and another part of the units are integrated into one unit. For example, in some embodiments, receiving unit 401 and transmitting unit 403 are the same unit. In other embodiments, receiving unit 401 and transmitting unit 403 are different units. In some embodiments, the integration of different units is implemented in hardware, i.e. different units correspond to the same hardware. As another example, the integration of the different units is implemented in the form of software units.

In case of being implemented in network device 400 by hardware, the processing unit 402 in network device 400 is implemented by, for example, a central processor 611 on a main control board 610 in network device 600, as well as by a processor 701 in network device 700. The receiving unit 401 and the sending unit 403 in the network device 400 are implemented, for example, by an interface board 630 in the network device 600, and also by a communication interface 704 in the network device 700.

In the case of being implemented by software in the network device 400, each unit in the network device 400 is, for example, software generated after the central processing unit 611 on the main control board 610 in the network device 600 or the processor 701 in the network device 700 reads program codes stored in the memory. For example, network device 400 is a virtualized device. The virtualization device includes, but is not limited to, at least one of a virtual machine, a container, and a Pod. In some embodiments, network device 400 is deployed on a hardware device (e.g., a physical server) in the form of a virtual machine. For example, network device 400 is implemented based on a general purpose physical server in conjunction with NFV technology. When implemented as a virtual machine, network device 400 is, for example, a virtual host, a virtual router, or a virtual switch. Those skilled in the art can simulate the network device 400 on the general physical server by combining the NFV technology through reading the present application. In other embodiments, network device 400 is deployed on a hardware device in the form of a container (e.g., a docker container). For example, the processes performed by network device 400 to perform the above-described method embodiments are encapsulated in an image file, and the hardware device creates network device 400 by running the image file. In other embodiments, network device 400 is deployed on a hardware device in the form of a Pod. The Pod includes a plurality of containers, each container for implementing one or more functional units in the network device 400.

Fig. 9 shows a schematic diagram of a possible structure of the third network device involved in the above embodiment. The network device 500 shown in fig. 9 implements, for example, the function of the third network device in the method 200, or the network device 500 implements the function of the RTE in the network system 10.

Referring to fig. 9, the network device 500 includes a receiving unit 501 and a processing unit 502. The various elements in network device 500 are implemented in whole or in part by software, hardware, firmware, or any combination thereof. Various elements in network device 500 are configured to perform the corresponding functions of the first network device or RC 505 in method 200 described above. Specifically, the receiving unit 501 is configured to support the network device 500 to execute S260. The processing unit 502 is configured to support the network device 500 to execute S270. In some embodiments, the processing unit 502 is further configured to support at least one of the network device 500 generating a response message or performing a service process. In some embodiments, the network device 500 further includes a sending unit for enabling the network device 500 to send at least one of a response message or send path information of the reverse path to the controller.

In some embodiments, the various elements of network device 500 are integrated into a single processing unit. For example, the units in the network device 500 are integrated on the same chip. The chip comprises a processing circuit, and an input interface and an output interface which are connected and communicated with the inside of the processing circuit. The processing unit 502 is implemented by processing circuitry in a chip. The receiving unit 501 is implemented by an input interface in the chip. The sending unit in the network device 500 is implemented by an output interface in the chip. For example, the chip may be implemented by one or more FPGAs, PLDs, controllers, state machines, gated logic, discrete hardware components, any other suitable circuitry, or any combination of circuitry capable of performing the various functions described throughout this application.

In other embodiments, the various elements of network device 500 exist physically separate. In other embodiments, a part of the units of the network device 500 exist separately and physically, and another part of the units are integrated into one unit. For example, in some embodiments, the processing unit 502 and the receiving unit 501 are the same unit. In other embodiments, processing unit 502 and receiving unit 501 are different units. In some embodiments, the integration of different units is implemented in hardware, i.e. different units correspond to the same hardware. As another example, the integration of the different units is implemented in the form of software units.

In case of being implemented in hardware in the network device 500, the processing unit 502 in the network device 500 is implemented by, for example, a central processor 611 on a main control board 610 in the network device 600, as well as by a processor 701 in the network device 700. The receiving unit 501 and the transmitting unit in the network device 500 are implemented, for example, by an interface board 630 in the network device 600, and also by a communication interface 704 in the network device 700.

In the case of being implemented by software in the network device 500, each unit in the network device 500 is, for example, software generated by the central processor 631 in the network device 600, the central processor 611, or the processor 701 in the network device 700 reading the program code stored in the memory. For example, network device 500 is a virtualized device. The virtualization device includes, but is not limited to, at least one of a virtual machine, a container, and a Pod. In some embodiments, network appliance 500 is deployed on a hardware device (e.g., a physical server) in the form of a virtual machine. For example, network device 500 is implemented based on a general purpose physical server in conjunction with NFV technology. When implemented as a virtual machine, the network device 500 is, for example, a virtual host, a virtual router, or a virtual switch. A person skilled in the art can simulate the network device 500 on the general physical server by combining the NFV technology through reading the present application. In other embodiments, network device 500 is deployed on a hardware device in the form of a container (e.g., a docker container). For example, the processes performed by the network device 500 to perform the above-described method embodiments are encapsulated in an image file, and the hardware device creates the network device 500 by running the image file. In other embodiments, network device 500 is deployed on a hardware device in the form of a Pod. The Pod includes a plurality of containers, each container for implementing one or more functional units in the network device 500.

How to implement the first network device, the second network device, and the third network device is described above from the perspective of logical functions through the network device 300, the network device 400, and the network device 500. How to implement the first network device, the second network device, and the third network device is described below from a hardware perspective by the network device 600 and the network device 700. The network device 600 shown in fig. 10 and the network device 700 shown in fig. 11 are illustrations of the hardware configuration of a first network device, a second network device, or a third network device.

The network device 600 or the network device 700 corresponds to the first network device, the second network device, or the third network device in the method 200, and for implementing various steps and methods implemented by the first network device, the second network device, or the third network device, hardware, modules, and other operations and/or functions in the network device 600 or the network device 700, respectively, for how the network device 600 or the network device 700 transmits the detection packet or how to determine the detailed flow of the reverse path, specific details may refer to the method 200, and for brevity, no further description is provided here. The steps of method 200 are performed by instructions in the form of hardware, integrated logic circuits, or software in a processor of network device 600 or network device 700. The steps of a method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in a processor. The software module is located in a storage medium, such as a ram, a flash memory, a rom, a prom, or an eeprom, a register, etc., which are well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and performs the steps of the above method in combination with hardware thereof, which are not described in detail herein to avoid repetition.

Referring to fig. 10, fig. 10 is a schematic structural diagram of a network device provided in an exemplary embodiment of the present application, and the network device 600 is configured as, for example, a first network device, a second network device, or a third network device. The network device 600 includes: a main control board 610 and an interface board 630.

The main control board is also called a Main Processing Unit (MPU) or a route processor card (route processor card), and the main control board 610 is used for controlling and managing each component in the network device 600, including routing computation, device management, device maintenance, and protocol processing functions. The main control board 610 includes: a central processor 611 and a memory 612.

The interface board 630 is also referred to as a Line Processing Unit (LPU), a line card (line card), or a service board. The interface board 630 is used for providing various service interfaces and forwarding data packets. The service interfaces include, but are not limited to, Ethernet interfaces, such as flexible Ethernet services interfaces (Flexe clients), POS (Packet over SONET/SDH) interfaces, and the like. The interface board 630 includes: a central processor 631, a network processor 632, a forwarding table entry memory 634, and a Physical Interface Card (PIC) 633.

The central processor 631 on the interface board 630 is used for controlling and managing the interface board 630 and communicating with the central processor 611 on the main control board 610.

The network processor 632 is configured to implement a forwarding process of the packet. The network processor 632 is in the form of a forwarding chip, for example. Specifically, the network processor 632 is configured to forward the received message based on the forwarding table stored in the forwarding table entry memory 634, and if the destination address of the message is the address of the network device 600, send the message to a CPU (e.g., the central processing unit 611) for processing; if the destination address of the message is not the address of the network device 600, the next hop and the outgoing interface corresponding to the destination address are found from the forwarding table according to the destination address, and the message is forwarded to the outgoing interface corresponding to the destination address. The processing of the uplink message comprises the following steps: processing a message input interface and searching a forwarding table; and (3) downlink message processing: forwarding table lookups, and the like.

The physical interface card 633 is used to implement the interfacing function of the physical layer, from which the original traffic enters the interface board 630, and the processed messages are sent out from the physical interface card 633. The physical interface card 633, also called a daughter card, may be installed on the interface board 630, and is responsible for converting the optical signal into a message, performing validity check on the message, and forwarding the message to the network processor 632 for processing. In some embodiments, a central processor may also perform the functions of network processor 632, such as implementing software forwarding based on a general purpose CPU, so that network processor 632 is not required in physical interface card 633.

Optionally, the network device 600 includes a plurality of interface boards, for example, the network device 600 further includes an interface board 640, and the interface board 640 includes: central processor 641, network processor 642, forward entry store 644, and physical interface card 643.

Optionally, the network device 600 further comprises a switch web board 620. The switch board 620 is also called a Switch Fabric Unit (SFU), for example. In the case of a network device having a plurality of interface boards 630, the switch board 620 is used to complete data exchange between the interface boards. For example, interface board 630 and interface board 640 communicate, for example, through switch board 620.

The main control board 610 is coupled to an interface board 630. For example. The main control board 610, the interface board 630, the interface board 640, and the switch board 620 are connected to the system backplane through the system bus to realize intercommunication. In a possible implementation manner, an inter-process communication (IPC) channel is established between the main control board 610 and the interface board 630, and the main control board 610 and the interface board 630 communicate through the IPC channel.

Logically, network device 600 includes a control plane including a main control panel 610 and a central processor 631, and a forwarding plane including various components that perform forwarding, such as forwarding table entry memory 634, physical interface cards 633, and network processor 632. The control plane performs functions of a router, generating a forwarding table, processing signaling and protocol messages, configuring and maintaining the state of the device, and the like, and issues the generated forwarding table to the forwarding plane, and in the forwarding plane, the network processor 632 looks up the table of the message received by the physical interface card 633 and forwards the table based on the forwarding table issued by the control plane. The forwarding table issued by the control plane is stored in the forwarding table entry storage 634, for example. In some embodiments, the control plane and the forwarding plane are, for example, completely separate and not on the same device.

It should be understood that the operations on the interface board 640 in the embodiment of the present application are the same as the operations of the interface board 630, and therefore, for brevity, detailed descriptions are omitted. It should be understood that the network device 600 of this embodiment may correspond to the network device in each of the above method embodiments, and the main control board 610 and the interface boards 630 and/or 640 in the network device 600 implement, for example, functions and/or various steps implemented by the network device in each of the above method embodiments, and therefore, for brevity, no repeated description is provided here.

It should be noted that there may be one or more main control boards, and when there are more than one main control boards, for example, the main control boards include a main control board and a standby main control board. The interface board may have one or more blocks, and the stronger the data processing capability of the network device, the more interface boards are provided. There may also be one or more physical interface cards on an interface board. The exchange network board may not have one or more blocks, and when there are more blocks, the load sharing redundancy backup can be realized together. Under the centralized forwarding architecture, the network device does not need a switching network board, and the interface board undertakes the processing function of the service data of the whole system. Under the distributed forwarding architecture, the network device can have at least one switching network board, and the data exchange among a plurality of interface boards is realized through the switching network board, so that the high-capacity data exchange and processing capacity is provided. Therefore, the data access and processing capabilities of network devices in a distributed architecture are greater than those of devices in a centralized architecture. Optionally, the form of the network device may also be only one board card, that is, there is no switching network board, and the functions of the interface board and the main control board are integrated on the one board card, at this time, the central processing unit on the interface board and the central processing unit on the main control board may be combined into one central processing unit on the one board card to perform the function after the two are superimposed, and the data switching and processing capability of the device in this form is low (for example, network devices such as a low-end switch or a router, etc.). Which architecture is specifically adopted depends on the specific networking deployment scenario, and is not limited herein.

Referring to fig. 11, fig. 11 is a schematic structural diagram of a network device 700 according to an exemplary embodiment of the present application, where the network device 700 may be configured as a first network device, a second network device, or a third network device. Network device 700 may be a host, server, personal computer, or the like. The network device 700 may be implemented by a generic bus architecture.

Network device 700 includes at least one processor 701, a communication bus 702, memory 703, and at least one communication interface 704.

The processor 701 is, for example, a Central Processing Unit (CPU), a Network Processor (NP), a Graphics Processing Unit (GPU), a neural-Network Processing Unit (NPU), a Data Processing Unit (DPU), a microprocessor, or one or more integrated circuits for implementing the present disclosure. For example, the processor 701 may include an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. PLDs are, for example, Complex Programmable Logic Devices (CPLDs), field-programmable gate arrays (FPGAs), General Array Logic (GAL), or any combination thereof.

A communication bus 702 is used to transfer information between the above components. The communication bus 702 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in FIG. 11, but this is not intended to represent only one bus or one type of bus.

The Memory 703 is, for example, but is not limited to, a read-only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only Memory (EEPROM), a compact disk read-only Memory (CD-ROM) or other optical disk storage, optical disk storage (including compact disk, laser disk, optical disk, digital versatile disk, blu-ray disk, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory 703 is, for example, separate and coupled to the processor 701 via a communication bus 702. The memory 703 may also be integrated with the processor 701.

The communication interface 704 uses any transceiver or the like for communicating with other devices or a communication network. The communication interface 704 includes a wired communication interface, and may also include a wireless communication interface. The wired communication interface may be an ethernet interface, for example. The ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a Wireless Local Area Network (WLAN) interface, a cellular network communication interface, or a combination thereof.

In particular implementations, processor 701 may include one or more CPUs, such as CPU0 and CPU1 shown in fig. 11, as one example.

In particular implementations, network device 700 may include multiple processors, such as processor 701 and processor 705 shown in FIG. 11, for example, as an example. Each of these processors may be a single-Core Processor (CPU) or a multi-Core Processor (CPU). A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In particular implementations, network device 700 may also include an output device and an input device, as one embodiment. An output device is in communication with the processor 701 and may display information in a variety of ways. For example, the output device may be a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display device, a Cathode Ray Tube (CRT) display device, a projector (projector), or the like. An input device is in communication with the processor 701 and may receive user input in a variety of ways. For example, the input device may be a mouse, a keyboard, a touch screen device, or a sensing device, among others.

In some embodiments, the memory 703 is used for storing the program code 710 for implementing the present solution, and the processor 701 may execute the program code 710 stored in the memory 703. That is, the network device 700 may implement the method provided by the method embodiment through the processor 701 and the program code 710 in the memory 703.

The network device 700 of the present embodiment may correspond to the first network device, the second network device, or the third network device in the above-described various method embodiments, and the processor 701, the communication interface 704, and the like in the network device 700 may implement the functions of the first network device, the second network device, or the third network device in the above-described various method embodiments and/or various steps and methods implemented by the first network device, the second network device, or the third network device. For brevity, no further description is provided herein.

Referring to fig. 12, an embodiment of the present application provides a network system 800, where the network system 800 includes: a first network device 801, a second network device 802, and a third network device 803.

In some embodiments, first network device 801 is network device 300 as shown in fig. 7, second network device 802 is network device 400 as shown in fig. 8, and third network device 803 is network device 500 as shown in fig. 9.

In some embodiments, at least one of first network device 801, second network device 802, or third network device 803 is network device 600 shown in fig. 10 or network device 700 shown in fig. 11.

Those of ordinary skill in the art will appreciate that the various method steps and elements described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both, and that the steps and elements of the various embodiments have been described above generally in terms of their functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the unit is only one logical functional division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may also be an electric, mechanical or other form of connection.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the elements may be selected according to actual needs to achieve the purpose of the solution of the embodiments of the present application.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The terms "first," "second," and the like, in this application, are used for distinguishing between similar items and items that have substantially the same function or similar functionality, and it is to be understood that "first" and "second" do not have a logical or temporal dependency, nor do they define a quantity or order of execution. It will be further understood that, although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first network device may be referred to as a second network device, and similarly, a second network device may be referred to as a first network device, without departing from the scope of various examples. The first network device and the second network device may both be network devices, and in some cases, may be separate and distinct network devices.

The term "at least one" in this application means one or more, and the term "plurality" in this application means two or more.

It should also be understood that the term "if" may be interpreted to mean "when" ("while" or "upon") or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined." or "if [ a stated condition or event ] is detected" may be interpreted to mean "upon determining.. or" in response to determining. "or" upon detecting [ a stated condition or event ] or "in response to detecting [ a stated condition or event ]" depending on the context.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive various equivalent modifications or substitutions within the technical scope of the present application, and these modifications or substitutions should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer program instructions. When loaded and executed on a computer, produce, in whole or in part, the procedures or functions according to the embodiments of the application. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device.

The computer program instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer program instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire or wirelessly. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that includes one or more of the available media. The available media may be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., Digital Video Disks (DVDs), or semiconductor media (e.g., solid state disks), among others.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A transmission method for detecting a message is characterized in that the method comprises the following steps:

a first network device receives a first detection message, wherein an intermediate node of a forwarding path of the first detection message comprises the first network device;

the first network device adds path information of a reverse path to the first detection packet to obtain a second detection packet, where the transmission directions of the reverse path and the forwarding path are opposite, the reverse path and the forwarding path have the same set of constraints, the constraints include nodes or links, the path information is used to indicate the constraints corresponding to the first network device in the reverse path, and the second detection packet includes the path information;

and the first network equipment sends the second detection message.

2. The method of claim 1, wherein the first detection packet includes a destination option header, and wherein the first network device adds path information of a reverse path to the first detection packet to obtain a second detection packet, including:

and the first network equipment adds the path information to a destination option header of the first detection message to obtain the second detection message.

3. The method according to claim 2, wherein the destination option header includes indication information indicating that path information of the reverse path is added to the first detection packet.

4. The method according to any of claims 1 to 3, wherein the path information comprises an Internet protocol version 6 segment routing end point segment identifier SRv6end.SID, and the first network device adds path information of a reverse path to the first detection packet to obtain a second detection packet, comprising:

and if the destination address of the first detection message is a local end.SID, the first network device adds the local end.SID to the first detection message, where the local end.SID is a type SRv6end.SID used for identifying the first network device.

5. The method according to any of claims 1 to 3, wherein the path information includes SRv6 end-point three-layer cross-connect segment identifier end.X SID, and the first network device adds path information of a reverse path to the first detection packet to obtain a second detection packet, including:

if the destination address of the first detection packet is a local end.X SID, the first network device adds an opposite end end.X SID to the first detection packet, where the local end.X SID is SRv6end.X SID used to identify a three-layer connection from the first network device to a second network device, and the opposite end end.X SID is SRv6end.X SID used to identify a three-layer connection from the second network device to the first network device.

6. The method of claim 5, wherein before the first network device adds a peer end.X SID to the first detection packet, the method further comprises:

and the first network equipment queries a Traffic Engineering Database (TEDB) according to the local end.X SID to obtain an opposite end end.X SID corresponding to the local end.X SID, wherein the TEDB stores a corresponding relation between the local end.X SID and the opposite end end.X SID.

7. The method according to any of claims 1 to 6, wherein the first detection message employs one of the following protocol messages: the method comprises the steps of Bidirectional Forwarding Detection (BFD) messages, operation, maintenance and management (OAM) detection messages, channel-associated OAM performance measurement iFit messages based on internet protocol data flow, bidirectional active measurement protocol (TWAMP) detection messages and internet packet explorer ping detection messages.

8. A method for determining a reverse path, the method comprising:

the method comprises the steps that network equipment receives a detection message, a tail node of a forwarding path passed by the detection message is the network equipment, the detection message comprises path information of a reverse path, the transmission direction of the reverse path is opposite to that of the forwarding path, the reverse path and the forwarding path have the same constraint set, and the constraint comprises a node or a link;

and the network equipment determines the reverse path according to the path information.

9. The method of claim 8, wherein after the network device determines the reverse path according to the path information, the method further comprises:

the network equipment generates a response message, wherein the response message is used for responding to the detection message, the response message comprises a Segment Routing Header (SRH), and a segment list in the SRH is used for indicating the reverse path;

and the network equipment sends the response message.

10. The method according to claim 8 or 9, wherein after the network device receives the detection packet, the method further comprises:

the network device sends the path information to a controller in a network.

11. The method according to claim 8 or 10, wherein the detection packet includes a first destination option header, and the first destination option header includes path information of the reverse path.

12. The method of claim 11, wherein the detection packet includes a Segment Routing Header (SRH), and wherein the first destination option header precedes the SRH.

13. The method according to any one of claims 8 to 12, wherein the detection packet includes a second destination option header, the second destination option header includes service information, the service information is used to indicate an attribute of the forwarding path or a service carried by the detection packet, and after the network device receives the detection packet, the method further includes:

and the network equipment carries out service processing according to the service information.

14. The method of claim 9, wherein the detection packet includes a second destination option header, the second destination option header includes service information, the service information is color information, priority information or a descriptor, and the network device generates the response packet includes:

and the network equipment encapsulates the response message according to the service information.

15. The method according to claim 13 or 14, wherein the detection message comprises a payload, and the second destination option header follows the SRH before the payload.

16. The method according to any of claims 8 to 15, wherein the constraint of the reverse path is part of the constraint of the forwarding path.

17. A transmission method for detecting a message is characterized in that the method comprises the following steps:

a network device generates a detection message, a head node of a forwarding path of the detection message is the network device, the detection message includes path information of a reverse path, the transmission direction of the reverse path is opposite to that of the forwarding path, the reverse path and the forwarding path have the same set of constraints, the constraints include nodes or links, and the path information is used for indicating the corresponding constraints of the network device in the reverse path;

and the network equipment sends the detection message.

18. The method of claim 17, wherein the detection packet comprises a first destination option header, and wherein the first destination option header comprises path information of the reverse path.

19. The method of claim 18, wherein the first destination option header comprises indication information indicating that path information of the reverse path is added to the detection packet.

20. The method according to claim 18 or 19, wherein the detection packet includes a second destination option header, and the second destination option header includes service information, and the service information is used to indicate the attribute of the forwarding path or the service carried by the detection packet.

21. The method according to any of claims 17 to 20, wherein the network device generates a detection packet, comprising:

22. A network device, wherein the network device is a first network device, the network device comprising:

a receiving unit, configured to receive a first detection packet, where an intermediate node of a forwarding path of the first detection packet includes the first network device;

a processing unit, configured to add path information of a reverse path to the first detection packet to obtain a second detection packet, where a transmission direction of the reverse path is opposite to a transmission direction of the forwarding path, the reverse path and the forwarding path have a same set of constraints, the constraints include nodes or links, the path information is used to indicate a constraint corresponding to the first network device in the reverse path, and the second detection packet includes the path information;

and the sending unit is used for sending the second detection message.

23. The network device of claim 22, wherein the path information comprises an ip version 6 segment routing end point segment id SRv6end.sid, and the processing unit is configured to add a local end.sid to the first detection packet if a destination address of the first detection packet is the local end.sid, where the local end.sid is a class SRv6end.sid for identifying the first network device.

24. The network device of claim 22 or 23, wherein the path information includes SRv6end point three-tier cross-connect segment identifiers (end.x SIDs), and the processing unit is configured to add a peer end.x SID to the first detection packet if a destination address of the first detection packet is a local end.x SID, where the local end.x SID is a SRv6end.x SID used for identifying a three-tier connection from the first network device to a second network device, and the peer end.x SID is a SRv6end.x SID used for identifying a three-tier connection from the second network device to the first network device.

25. A network device, characterized in that the network device comprises:

a receiving unit, configured to receive a detection packet, where a tail node of a forwarding path through which the detection packet passes is the network device, the detection packet includes path information of a reverse path, a transmission direction of the reverse path is opposite to that of the forwarding path, the reverse path and the forwarding path have a same set of constraints, and the constraints include nodes or links;

and the processing unit is used for determining the reverse path according to the path information.

26. The network device according to claim 25, wherein the processing unit is further configured to generate a response packet, where the response packet is used to respond to the detection packet, and the response packet includes a Segment Routing Header (SRH), and a segment list in the SRH is used to indicate the reverse path;

the network device further includes: and the sending unit is used for sending the response message.

27. A network device, characterized in that the network device comprises:

a processing unit, configured to generate a detection packet, where a head node of a forwarding path of the detection packet is the network device, the detection packet includes path information of a reverse path, a transmission direction of the reverse path is opposite to that of the forwarding path, the reverse path and the forwarding path have a same set of constraints, the constraints include nodes or links, and the path information is used to indicate a constraint corresponding to the network device in the reverse path;

and the sending unit is used for sending the detection message.

28. A network system, characterized in that the network system comprises a network device according to any of claims 22 to 24, a network device according to any of claims 25 to 26, and a network device according to claim 27.

29. A computer-readable storage medium, in which at least one program code is stored, which, when executed by a computer, causes the computer to perform the method of any one of claims 1 to 21.