CN115225452A

CN115225452A - Fault sensing method, device and system for forwarding path

Info

Publication number: CN115225452A
Application number: CN202110418201.3A
Authority: CN
Inventors: 姚俊达; 胡志波
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-04-19
Filing date: 2021-04-19
Publication date: 2022-10-21
Also published as: WO2022222884A1

Abstract

The application provides a method, a device and a system for sensing faults of a forwarding path, and belongs to the technical field of communication. In the solution provided by the present application, a first network device may carry a first identifier for determining a first forwarding path in a sent service message, and a second network device may feed back a failure notification message carrying the first identifier to the first network device after detecting that the first forwarding path is failed. Thus, even if an end-to-end detection algorithm is not deployed in the first network device, the first forwarding path failure may be determined based on the first identifier in the failure notification message. According to the scheme provided by the application, the network equipment can sense the fault of the forwarding path without deploying the end-to-end detection algorithm in the network equipment, so that the problems of high deployment complexity and low efficiency caused by deploying the end-to-end detection algorithm are effectively solved.

Description

Fault sensing method, device and system of forwarding path

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, and a system for sensing a failure of a forwarding path.

Background

SRv6 is a Segment Routing (SR) forwarding technology based on internet protocol version 6 (ipv 6). A network device supporting SRv6 technology may encapsulate a routing extension header (SRH) in a packet, where the SRH includes a segment list (segment list) indicating a forwarding path of the packet. The network device that receives the message may forward the message based on the segment list.

In order to implement fault detection on the forwarding path, an end-to-end detection algorithm, such as a Bidirectional Forwarding Detection (BFD) algorithm or a Seamless BFD (SBFD) algorithm, needs to be deployed in the head-end network device of the forwarding path. After the head-end network equipment detects the forwarding path fault of the message based on the end-to-end detection algorithm, the forwarding path of the message can be switched in time.

However, the complexity and efficiency of deploying the end-to-end detection algorithm in the network device are high.

Disclosure of Invention

The application provides a method, a device and a system for sensing faults of a forwarding path, which can solve the technical problems of high complexity and low efficiency in deploying an end-to-end detection algorithm in network equipment.

In a first aspect, a method for sensing a failure of a forwarding path is provided, which is applied to a first network device; the method comprises the following steps: sending a first service message through a first forwarding path, and receiving a fault notification message sent by second network equipment in the first forwarding path; the first service packet includes a first identifier, the first identifier is used to determine the first forwarding path, the fault notification packet also includes the first identifier, and the fault notification packet is used to indicate that the first forwarding path is faulty.

Because the first network device can perceive the fault of the first forwarding path based on the fault notification message fed back by the second network device, an end-to-end detection algorithm does not need to be deployed in the first network device, and thus the problems of high deployment complexity and low efficiency caused by the deployment of the end-to-end detection algorithm are effectively avoided.

Optionally, the method may further include: and sending a second service message through the standby path of the first forwarding path, wherein the second service message and the first service message belong to the same service flow.

After determining that the first forwarding path fails, the first network device may further switch the path for forwarding the packet to a standby path, thereby ensuring normal forwarding of the service flow and avoiding interruption of the service flow.

Optionally, the SR policy to which the first forwarding path belongs includes a plurality of candidate paths, and the first forwarding path belongs to the plurality of candidate paths; the process of sending the second service packet through the backup path of the first forwarding path may include: and based on the fault notification message, determining a second forwarding path from the multiple candidate paths as a standby path, and sending a second service message encapsulated with a second identifier through the second forwarding path, wherein the second identifier is used for determining the second forwarding path.

The first network device determines the second forwarding path from the SR policy to which the first forwarding path belongs, so that the switched second forwarding path can still meet the performance requirement of the service flow, and the service experience of the service flow is ensured.

Optionally, the process of sending the second service packet through the backup path of the first forwarding path may include: based on the failure notification packet, a Virtual Private Network (VPN) fast reroute (FRR) technique is used to determine a second forwarding path as a standby path, and a second service packet encapsulated with a second identifier is sent through the second forwarding path, where the second identifier is used to determine the second forwarding path.

The first network device may determine the second forwarding path by using a VPN FRR technique after determining that the SR policy to which the first forwarding path belongs does not include other candidate paths, thereby ensuring that a backup path can be reliably determined, and further ensuring reliable switching of the forwarding paths.

Optionally, the process of sending the second service packet through the backup path of the first forwarding path may include: sending fault information to a controller based on the fault notification message, wherein the fault information is used for indicating the fault of the first forwarding path; and using a second forwarding path issued by the controller as a standby path, and sending a second service message encapsulated with a second identifier through the second forwarding path, where the second identifier is used to determine the second forwarding path.

The first network device may send failure information to the controller to request the controller to recalculate and issue the second forwarding path after determining that the SR policy to which the first forwarding path belongs does not include other candidate paths. Or, the first network device may send failure information to the controller after the switchable forwarding path is not determined by using the VPN FRR technique, so as to request the controller to recalculate and issue the second forwarding path. The controller is used for calculating and issuing the second forwarding path, so that reliable switching of the forwarding paths can be ensured.

Optionally, the first identifier may be a Binding Segment Identifier (BSID) of an SR policy to which the first forwarding path belongs; alternatively, the first identifier may be a path identifier of a candidate path under the SR policy, that is, a path identifier of the first forwarding path. The path identifier may be a BSID of the forwarding path.

Optionally, the first service packet may include an SRH, and the SRH may carry the first identifier.

Optionally, the SRH further comprises a segment list and a flag field, the segment list comprising a plurality of segment identifications; one segment identifier in the segment list carries the first identifier, and the tag field may be used to indicate that the segment list includes the first identifier. Thereby, it may be facilitated for the second network device to determine, based on the indication of the flag field, whether the first identity is carried in the segment list.

Optionally, the last segment identifier in the segment list may carry the first identifier. Since the last segment identifier in the segment list is usually the segment identifier of the head-end network device (i.e. the first network device) of the forwarding path, the first identifier is carried by the last segment identifier, which not only can ensure normal forwarding of the service packet, but also does not need to change the structure of the service packet.

Optionally, the fault notification message includes an SRH, where the SRH carries the first identifier; or the data field of the failure notification packet carries the first identifier, and the failure notification packet does not include the SRH.

If the second network device directly encapsulates the SRH in the failure notification message and carries the first identifier through the SRH, the second network device does not need to parse the SRH in the service message to obtain the first identifier, so that the message processing operation of the second network device can be simplified. If the second network device does not encapsulate the SRH in the failure notification message and carries the first identifier through the data field in the failure notification message, the structure of the failure notification message can be effectively simplified.

Alternatively, the failure notification message may be an Internet control information protocol (ICMP) message. Such as an ICMPv6 message.

Since the ICMP message has the function of indicating a failure, the first identifier may be directly encapsulated in the ICMP message to indicate the failure of the first forwarding path. By multiplexing the traditional ICMP message, the message identification and processing behaviors of the network equipment are prevented from being changed as much as possible on the premise of ensuring that the network equipment accurately senses the forwarding path fault.

On the other hand, a fault perception method of a forwarding path is provided, which is applied to a second network device; the method comprises the following steps: receiving a first service message sent by a first network device through a first forwarding path, and if the first forwarding path is determined to be in fault, sending a fault notification message to the first network device; the first service packet includes a first identifier, the first identifier is used to determine the first forwarding path, the fault notification packet also includes the first identifier, and the fault notification packet is used to indicate that the first forwarding path is faulty.

Optionally, the failure notification packet includes an SRH, where the SRH carries the first identifier; or, the data field of the fault notification packet carries the first identifier.

Optionally, the failure notification message is an ICMP message.

Optionally, the first identifier is a BSID of an SR policy to which the first forwarding path belongs; alternatively, the first identifier is a path identifier of the first forwarding path.

Optionally, the first service packet includes an SRH, where the SRH carries the first identifier.

Optionally, the SRH further comprises a segment list and a flag field, the segment list comprising a plurality of segment identifications; one segment identifier in the segment list carries the first identifier, and the tag field is used for indicating that the segment list includes the first identifier.

In yet another aspect, a first network device is provided, which includes at least one module that can be used to implement the failure-aware method applied to a forwarding path of the first network device provided in the above aspect.

In yet another aspect, a second network device is provided, where the second network device includes at least one module, and the at least one module may be configured to implement the failure-aware method applied to the forwarding path of the second network device provided in the foregoing aspect.

In still another aspect, a network device is provided, and the network device may include: a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the method for fault awareness for a forwarding path applied to a first network device as provided in the above aspects when executing the computer program, or implementing the method for fault awareness for a forwarding path applied to a second network device as provided in the above aspects.

In still another aspect, a network device is provided, and the network device may include: the interface board may be configured to implement the failure sensing method applied to the forwarding path of the first network device provided in the foregoing aspect, or may be configured to implement the failure sensing method applied to the forwarding path of the second network device provided in the foregoing aspect.

In another aspect, a network device is provided, where the network device may be a first network device in a packet forwarding system, and the network device 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: sending a first service message through a first forwarding path, and receiving a fault notification message sent by second network equipment in the first forwarding path; the first service packet includes a first identifier, the first identifier is used to determine a first forwarding path, the fault notification packet also includes the first identifier, and the fault notification packet is used to indicate that the first forwarding path has a fault.

In another aspect, a network device is provided, where the network device may be a second network device in a packet forwarding system, and the network device 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 first service message sent by a first network device through a first forwarding path, and if the first forwarding path is determined to be in fault, sending a fault notification message to the first network device; the first service packet includes a first identifier, the first identifier is used to determine a first forwarding path, the fault notification packet also includes the first identifier, and the fault notification packet is used to indicate that the first forwarding path is faulty.

In yet another aspect, a computer-readable storage medium is provided, in which instructions are stored, and the instructions are executed by a processor to implement the failure-aware method applied to the forwarding path of the first network device provided in the above aspect, or to implement the failure-aware method applied to the forwarding path of the second network device provided in the above aspect.

In yet another aspect, a computer program product containing instructions is provided, which when run on a computer causes the computer to perform the fault-aware method provided in the above aspect as applied to a forwarding path of a first network device or to perform the fault-aware method provided in the above aspect as applied to a forwarding path of a second network device.

In another aspect, a packet forwarding system is provided, where the packet forwarding system may include: a first network device as provided in the above aspect, and a second network device as provided in the above aspect.

In still another aspect, a chip may be configured to implement the failure awareness method applied to the forwarding path of the first network device provided in the foregoing aspect, or may be configured to implement the failure awareness method applied to the forwarding path of the second network device provided in the foregoing aspect.

To sum up, the present application provides a method, an apparatus, and a system for sensing a failure of a forwarding path, where a first network device can carry a first identifier for determining a first forwarding path in a sent service message, and a second network device can feed back a failure notification message carrying the first identifier to the first network device after detecting a failure of the first forwarding path. Thus, even if the end-to-end detection algorithm is not deployed in the first network device, the first forwarding path failure may be determined based on the first identifier in the failure notification message. According to the scheme provided by the embodiment of the application, the network equipment can quickly and accurately sense the fault of the forwarding path without deploying the end-to-end detection algorithm in the network equipment, so that the problems of high deployment complexity and low efficiency caused by deploying the end-to-end detection algorithm are effectively solved.

Drawings

Fig. 1 is a schematic structural diagram of a message forwarding system according to an embodiment of the present application;

fig. 2 is a flowchart of a method for sensing a failure of a forwarding path according to an embodiment of the present application;

fig. 3 is a flowchart of another failure sensing method for a forwarding path according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of an SRv6 packet provided in the embodiment of the present application;

fig. 5 is a schematic structural diagram of another packet forwarding system provided in the embodiment of the present application;

fig. 6 is a schematic structural diagram of an ICMPv6 message provided in the embodiment of the present application;

fig. 7 is a schematic structural diagram of another packet forwarding system provided in the embodiment of the present application;

fig. 8 is a schematic structural diagram of another message forwarding system according to an embodiment of the present application;

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

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

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

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

Detailed Description

The following describes a method, an apparatus, and a system for sensing a failure of a forwarding path according to an embodiment of the present application in detail with reference to the accompanying drawings.

Fig. 1 is a schematic structural diagram of a message forwarding system according to an embodiment of the present application, and as shown in fig. 1, the message forwarding system may include a plurality of network devices 01, and communication connections are established among the plurality of network devices 01. Each network device 01 may be a device such as a router or a switch having a message forwarding function, and each network device 01 may also be referred to as a node.

Alternatively, the network device 01 in the system may be a provider (P) device or a Provider Edge (PE) device. If the network device 01 is a PE device, as shown in fig. 1, the system may further include one or more Customer Edge (CE) devices 02 connected to the PE device. The CE device 02 may be a router or a switch, and may be connected to a user terminal for providing an access service for the user terminal. Alternatively, the CE device 02 may be a user terminal. A user terminal may also be referred to as a host or a user equipment, among others.

Optionally, referring to fig. 1, the message forwarding system may further include a controller 03, where the controller 03 is connected to at least one network device 01, and is configured to manage and control the network device 01 connected thereto. The controller 03 may also be configured to calculate an end-to-end forwarding path, and send the forwarding path to a head-end network device, i.e., a head node, of the forwarding path.

The controller 03 may be a network controller, for example, a Software Defined Network (SDN) controller, a Network Control Engine (NCE) or a path computation element server (PCE server), and the like. Moreover, the controller 03 may be a server, a server cluster composed of a plurality of servers, or a cloud computing service center.

In this embodiment of the present application, the message forwarding system may be an SRv6 system, each network device 01 in the system supports an SRv6 technology, and a VPN connection based on SRv6 may be established between the network devices 01. Moreover, the network device 01 may receive the SR policy sent by the controller 03, and forward the service packet based on the candidate path in the SR policy.

Optionally, the controller 03 may collect link states reported by each network device 01 in the system based on a BGP link-state (BGP-LS) protocol, and may issue an SR policy through a path computation element communication protocol (PCEP). BGP refers to border gateway protocol (border gateway protocol). In an SRv6 system, the SR policy may also be referred to as an SRv6 Traffic Engineering (TE) policy, namely SRv6-TE policy.

The embodiment of the application provides a method for sensing a failure of a forwarding path, which can be applied to a message forwarding system such as that shown in fig. 1. Referring to fig. 2, the method includes:

step 101, a first network device sends a first service packet through a first forwarding path, where the first service packet includes a first identifier.

The first network device may be any network device in a packet forwarding system, and the first network device is a head-end network device of the first forwarding path. The first service packet sent by the first network device through the first forwarding path may include a first identifier, where the first identifier is used to determine the first forwarding path.

Optionally, the first identifier may be a BSID of an SR policy to which the first forwarding path belongs. Alternatively, the first identifier may be a path identifier of the first forwarding path, for example, the path identifier may be a path identifier of a candidate path under an SR policy, and the path identifier may be a BSID of the candidate path.

Step 102, if the second network device determines that the first forwarding path has a fault, the second network device sends a fault notification message to the first network device, where the fault notification message includes the first identifier.

The second network device is a network device in the first forwarding path. After receiving a first service packet sent by a first network device through a first forwarding path, the second network device may send a failure notification packet to the first network device if detecting that the first forwarding path fails. The failure notification message includes the first identifier, and the failure notification message is used to indicate that the first forwarding path has failed. Correspondingly, after receiving the failure notification message, the first network device may determine that the first forwarding path fails based on the first identifier in the failure notification message.

It may be understood that the failure notification message may further include a failure identifier, and the first network device may determine, based on the failure identifier, that the received message is a failure notification message for indicating a forwarding path failure.

To sum up, the embodiment of the present application provides a method for sensing a failure of a forwarding path, where a first network device may carry a first identifier for determining a first forwarding path in a sent service message, and a second network device may feed back a failure notification message carrying the first identifier to the first network device after detecting that the first forwarding path has a failure. Thus, even if an end-to-end detection algorithm is not deployed in the first network device, the first forwarding path failure may be determined based on the first identifier in the failure notification message. According to the scheme provided by the embodiment of the application, the network equipment can quickly and accurately sense the fault of the forwarding path without deploying the end-to-end detection algorithm in the network equipment, so that the problems of high deployment complexity and low efficiency caused by deploying the end-to-end detection algorithm are effectively avoided.

Moreover, when detecting whether the forwarding path is faulty based on the end-to-end detection algorithm, the network device needs to periodically send a detection message, and the detection message may occupy the bandwidth of the service message, resulting in a low utilization rate of the network bandwidth. The scheme provided by the embodiment of the application does not need to periodically send the detection message, so that the utilization rate of the network bandwidth can be effectively improved, and the reliable sending of the service message is ensured.

The embodiment of the present application provides another method for sensing a failure of a forwarding path, which may be applied to a packet forwarding system such as that shown in fig. 1. Referring to fig. 3, the method includes:

step 201, a first network device sends a first service packet through a first forwarding path, where the first service packet includes a first identifier.

The first network device may be any network device in a packet forwarding system, and the first network device is a head-end network device of the first forwarding path. The first service packet sent by the first network device through the first forwarding path may include a first identifier, where the first identifier may be used to determine the first forwarding path.

As one possible example, the first identification may be a BSID of an SR policy to which the first forwarding path belongs. As another possible example, the first identity may be a path identity of the first forwarding path, e.g., the path identity may be a BSID of the forwarding path.

Optionally, the first service packet may be an SRv6 packet, where the SRv6 packet includes an SRH, and the SRH may carry the first identifier. Fig. 4 is a schematic structural diagram of an SRv6 packet provided in the embodiment of the present application, and as shown in fig. 4, the SRv6 packet includes an IPv6 header, an SRH, and a payload (payload). The IPv6 header at least includes a Source Address (SA) and a Destination Address (DA) of the service packet.

SRH includes the following fields: next Header (NH), extension header length (Hdr Ext Len), routing header type (routing type), segment Left (SL), last entry (last entry), flags (flags), tag (tag), and segment list (segment list). The segment list includes a plurality of Segment Identifications (SID), for example, n +1 segment identifications (n may be an integer greater than or equal to 1) from the segment list [0] to the segment list [ n ] are shown in fig. 4. Each segment identifier is used to indicate a network device in a forwarding path of the traffic packet, and for example, the segment identifier may be an IPv6 address of the network device. Therefore, the forwarding path of the service packet can be determined based on the segment list. The SL field is used to indicate the number of intermediate network devices that need to be accessed before reaching the destination network device (which may also be referred to as the destination node).

The segment list may include a plurality of segment identifiers, where one segment identifier of the plurality of segment identifiers may carry the first identifier, and the flag field is used to indicate that the segment list includes the first identifier. Therefore, the network device receiving the first service packet can determine whether the segment list carries the first identifier based on the indication of the tag field. For example, referring to fig. 4, 1 bit (bit) in the flag field may be used as a flag bit B, where a value of the flag bit B is 1 may indicate that the first identifier is included in the segment list, and a value of the flag bit B is 0 may indicate that the first identifier is not included in the segment list.

In the embodiment of the present application, the first identifier may be carried by the last segment identifier in the segment list (i.e., segment list [ n ]). Since the last segment identifier in the segment list is usually the segment identifier of the head-end network device (i.e., the first network device) of the forwarding path, the first identifier is carried by the last segment identifier, which not only can ensure normal forwarding of the service packet, but also does not need to change the structure of the service packet.

Alternatively, a new segment identifier (e.g., segment list [ -1] or segment list [ n +1 ]) may be added to the segment list to carry the first identifier.

It will be appreciated that the length of the first marker may be equal to the length of a segment marker. Or, the length of the first identifier may be smaller than that of a segment identifier, that is, a segment identifier in the segment list may carry the first identifier and may also carry other information besides the first identifier.

For example, referring to fig. 5, it is assumed that the first network device is PE1, which receives SRv6 TE Policy sent by the controller 03:

Policy 1：Endpoint PE3,color red

Binding Sid：BSID1

Candidate path 1：

Preference 200

SID List:<PE1,P1,P3,PE3>

Candidate path 2：

Preference 100

SID List:<PE1,P2,P4,PE3>

as can be seen from the above, the SRv6 TE Policy has an end point (endpoint) of PE3, a color (color) of red (red), and a BSID of BSID1. The end point may be configured to indicate a tail-end network device of a public network tunnel in an end-to-end forwarding path; color is used to indicate the performance of the SRv6 TE Policy, i.e., the performance of the tunnel indicated by the SRv6 TE Policy, such as a low latency tunnel or a low cost tunnel. As can also be seen with reference to the above, the SRv6 TE Policy includes two candidate paths (candidate paths). Wherein, the first candidate path is: PE1 → P1 → P3 → PE3, its priority (reference) is 200; the second candidate path is: PE1 → P2 → P4 → PE3, with a priority of 100.

Since the priority of the first candidate path is higher, the PE1 may use the first candidate path as a first forwarding path (i.e., a main path) to forward the first service packet. Referring to fig. 5, an SRH is encapsulated in the first service packet sent by the pe1, and a segment list in the SRH includes 5 segment identifiers (i.e., n = 5). The first segment id is a SID used to identify VPN information between the endpoint PE3 and the destination node CE2, and the SID may be end.dt4, end.dt6, end.dxp 4, or end.dxp 6, etc., which are collectively denoted as PE3-VPNSID, according to the difference of the VPN policy of the PE3. The 2 nd to 4 th segment identifiers are segment identifiers of PE3, P3, and P1 in the first forwarding path in sequence, and the last segment identifier may carry the BSID of the SRv6 TE Policy: BSID1. And, the value of the flag bit B of the flag field in the SRH may be set to 1, and the value of SL may be set to n-1, i.e., SL =3. The manner in which the encapsulation BSID is identified by the last segment in the segment list may also be referred to as reduced SRH (reduce SRH) encapsulation.

Based on the above description about SR policy and the segment list, the candidate path in SR policy may indicate a public network tunnel, and the segment list in SRH may include, in addition to the SID of each node in the public network tunnel, a SID used for identifying VPN information between an end point (endpoint) of the public network tunnel and a destination node.

Step 202, if the second network device determines that the first forwarding path fails, the second network device sends a failure notification message to the first network device, where the failure notification message includes the first identifier.

The second network device is a network device in the first forwarding path. After receiving a first service packet sent by a first network device through a first forwarding path, a second network device may send a failure notification packet to the first network device if detecting that the first forwarding path fails. The failure notification message includes the first identifier, and the failure notification message is used to indicate that the first forwarding path has failed. The second network device may determine that the first forwarding path fails when detecting an outgoing interface failure of the second network device for forwarding the first service packet or a link failure corresponding to the outgoing interface. It is understood that the failure notification message may be sent to the first network device based on a protocol such as IPv 6.

As a possible example, the failure notification message may include an SRH, and the SRH carries the first identifier. That is, the second network device may directly encapsulate the SRH in the first service message into the failure notification message without parsing and acquiring the first identifier in the SRH, thereby effectively simplifying the message processing operation of the second network device.

As another possible example, the data field of the failure notification packet carries the first identifier, that is, the failure notification packet does not include the SRH. Therefore, the structure of the fault notification message is simple. After receiving the fault notification message, the first network device may directly obtain the first identifier from the data field of the fault notification message without analyzing the SRH, thereby effectively simplifying the message processing operation of the first network device.

It can be understood that the fault notification message may further include a fault identifier. The network device (e.g., the first network device) that receives the failure notification message may determine, based on the failure identifier, that the message it receives is a failure notification message indicating a failure of the forwarding path.

Optionally, the failure notification message may be an ICMP message, for example, an ICMPv6 message based on IPv 6. Fig. 6 is a schematic structural diagram of an ICMPv6 message provided in an embodiment of the present application, and fig. 6 illustrates that the ICMPv6 message includes an SRH. Referring to fig. 6, the ICMPv6 message includes an IPv6 header, an SRH, an ICMP message, and a payload. The NH field of the SRH may be used to indicate that the message also includes an ICMP message, for example, the value of the NH field may be 58. The ICMP message may include the following fields: type (type), code (code), checksum (checksum), and message body (message body).

Wherein, the message body field is the data field of the fault notification message. the type field is used to indicate a type of the ICMP message, and values of the type field of 0 to 127 represent an error message and values of the type field of 128 to 255 represent an information message. The value of the code field is used to further subdivide the type of message. For example, a value of 1 in the type field may indicate that the purpose is not reachable. When the value of the type field is 1, if the value of the code field is 0, it may indicate that no route to the target is reached; if the code field has a value of 3, it may indicate that the address is not reachable. As can be seen from the above definition, the value of the type field (or the values of the type field and the code field) in the ICMP message can be used as a fault identifier. It is to be understood that the fault notification message may not include a payload. For the related definition of each field in the ICMP message, reference may be made to the related description in request for comments (RFC) document with number 2463, and the related content in this document may be incorporated by reference in the embodiments of the present application.

For example, referring to fig. 5, assuming that P3 in the first forwarding path detects an output interface failure, P3 serving as the second network device may send a failure notification packet encapsulating BSID1 to PE1. The failure notification message is encapsulated with SRH, and the SRH carries BSID1. As shown in fig. 5, SA of the IPv6 header in the fault notification packet is P3, DA is PE1, and the fault notification packet may be forwarded to PE1 based on IPv 6.

Since the ICMP message has the function of indicating a failure, the first identifier may be directly encapsulated in the ICMP message to indicate the failure of the first forwarding path. By multiplexing the traditional ICMP message, the message identification and processing behaviors of the network equipment can be avoided to the greatest extent on the premise of ensuring that the network equipment accurately senses the forwarding path fault.

It can be understood that, if the network device in the first forwarding path does not detect a path failure, the first service packet may be normally forwarded to the tail-end network device through the first forwarding path. If the SRH of the first service packet is encapsulated with the first identifier, the first identifier may be popped up along with the SRH at the tail end network device or the penultimate network device of the first forwarding path.

Step 203, the first network device determines that the first forwarding path fails based on the first identifier in the failure notification message.

In this embodiment of the present application, after receiving a failure notification message sent by a second network device, a first network device may determine that a first forwarding path fails based on a first identifier in the failure notification message.

In one aspect, for a scenario in which the first identifier is a BSID of an SR policy to which the first forwarding path belongs. If the SR policy only includes one candidate path (i.e., the first forwarding path), the first network device may determine that the first forwarding path in the SR policy fails after determining the SR policy based on the BSID. If the SR policy includes multiple candidate paths, since a current path (i.e., a first forwarding path) for forwarding the first service packet in the multiple candidate paths is in an active (active) state, the first network device may determine that the first forwarding path in the active state in the SR policy has a fault after determining the SR policy based on the BSID.

On the other hand, for a scenario in which the first identifier is a path identifier of the first forwarding path (e.g., BSID of the forwarding path), the first network device may determine that the first forwarding path fails based on the first identifier directly.

It can be understood that, if the failure notification message includes an SRH and the SRH carries the first identifier, the first network device may parse the SRH to obtain the first identifier. If the fault notification message does not include the SRH and the data field in the fault notification message carries the first identifier, the first network device may directly obtain the first identifier from the data field.

It is further understood that the fault notification message may further include a fault identifier, and the first network device may determine, based on the fault identifier, that the message received by the first network device is a fault notification message for indicating a forwarding path fault. If the fault notification message is an ICMP message, the first network device may determine that the received message is a fault notification message based on the type field in the ICMP message, and may determine the fault type of the first forwarding path based on the code field of the ICMP message.

Step 204, the first network device determines that the second forwarding path is a standby path.

After sensing the failure of the first forwarding path based on the failure notification packet, the first network device may further determine a backup path of the first forwarding path, so as to switch the service flow to which the first service packet belongs to the backup path, so as to ensure normal forwarding of the service flow. The following description takes an example in which the first network device determines that the second forwarding path is a backup path of the first forwarding path.

As a possible example, if the SR policy to which the first forwarding path belongs includes multiple candidate paths, the first network device may determine, from the multiple candidate paths, a second forwarding path as a standby path, so that hot-standby (hot-standby) protection of the forwarding paths may be implemented. For example, the first network device may determine a highest priority candidate path among the plurality of candidate paths, excluding the first forwarding path, as the second forwarding path.

For example, referring to step 201 above, assuming that the SRv6 TE Policy to which the first forwarding path belongs includes two candidate paths, after determining that the first candidate path fails, PE1 may: PE1 → P2 → P4 → PE3 is determined as the second forwarding path.

In this example, since the switched second forwarding path and the switched first forwarding path belong to the same SR policy, it can be ensured that after the service packet is forwarded based on the second forwarding path, the performance requirement of the service flow to which the service packet belongs can still be satisfied, and the service experience of the service flow is ensured.

It is understood that if the hot backup protection mechanism is configured in the first network device, the first network device may determine the second forwarding path in the manner shown in this example.

As another possible example, the first network device may determine the second forwarding path as a backup path using VPN FRR techniques. The VPN FRR technology is a fault protection mechanism applied to a CE dual-homing network model, and can solve the problem of end-to-end rapid convergence of the service when the main PE equipment fails. The CE dual homing refers to that one CE device accesses two PE devices at the same time, where one PE device is a primary PE device and the other PE device is a backup PE device. For example, referring to fig. 7, the connection manner of the ce1 and the PE1 and the PE2, and the connection manner of the CE2 and the PE3 and the PE4 are both CE dual-homing network models.

It can be understood that, in this example, the controller may issue two SR policies to the first network device, where one SR policy includes the first forwarding path, and an endpoint of the SR policy is a primary PE device for CE dual homing access; and the other SR strategy comprises a second forwarding path, and the end point of the SR strategy is a standby PE device for CE dual-homing access. The first network device may determine the second forwarding path from the another SR policy after determining that the first forwarding path fails and triggering the VPN FRR.

Taking the scenario shown in fig. 7 as an example, the SRv6 TE Policy issued by the controller to PE1 may include:

Policy 1：Endpoint PE3,color red

Binding Sid：BSID1

Candidate path 1：

SID List:<PE1,P1,P3,PE3>

Policy 2：Endpoint PE4,color yellow

Binding Sid：BSID2

Candidate path 2：

SID List:<PE1,P2,P4,PE4>

referring to the content of the SRv6 TE Policy, it can be seen that the end point of an SR Policy (i.e., policy 1) issued by the controller is a CE2 dual-homed active PE device: PE3, red in color, BSID1, candidate paths are: PE1 → P1 → P3 → PE3. The end point of another SR Policy (i.e. Policy 2) issued by the controller is a standby PE device for CE2 dual homing: PE4, yellow in color, BSID2, candidate path is: PE1 → P2 → P4 → PE4.

The PE1 receives a first identifier: after the failure notification message of BSID1, the candidate path failure in Policy 1 may be determined. Since there are no other candidate paths in Policy 1, PE1 may set the tunnel state of the tunnel indicated by Policy 1 to an inactive (down) state and trigger VPN FRR protection. Based on the VPN FRR protection technology, the PE1 may switch the forwarding path of the service packet to a candidate path in Policy 2, so as to access the CE2 through the PE4, that is, the PE1 may determine the candidate path in Policy 2 as the second forwarding path.

It can also BE understood that, when determining the second forwarding path based on the VPN FRR technique, if a candidate path in another SR policy is not acquired, the first network device may further calculate a best effort forwarding (BE) path as the second forwarding path.

It is also understood that if the first network device is configured with a VPN FRR mechanism, the first network device may determine the second forwarding path using the VPN FRR technique.

As yet another possible example, the first network device may send failure information to the controller, the failure information indicating that the first forwarding path failed. After receiving the failure information, the controller may recalculate a new forwarding path (i.e., the second forwarding path), and send the second forwarding path to the first network device. That is, the first network device may use the second forwarding path recalculated and issued by the controller as the standby path.

For example, suppose that the SR Policy issued by the controller to PE1 is Policy 1, where Policy 1 includes only the first forwarding path. Then PE1 receives the packet carrying the first identifier: after the failure notification message of BSID1, it may determine that the first forwarding path in Policy 1 fails. Since there are no other candidate paths in Policy 1, PE1 may set down the tunnel state of the tunnel indicated by Policy 1, and report failure information to the controller, where the failure information includes the tunnel state of the tunnel indicated by Policy 1. After the controller determines that the tunnel state of Policy 1 is down based on the fault information, it may recalculate a second forwarding path and send it to PE1.

It can be understood that, in this embodiment of the present application, if the first network device is configured with a hot backup protection mechanism and a VPN FRR mechanism, after sensing that the first forwarding path fails based on the failure notification packet, the first network device may first detect whether the SR policy to which the first forwarding path belongs includes other candidate paths. If the SR policy includes other candidate paths, the first network device may determine, from the other candidate paths, the second forwarding path as a standby path, that is, the first network device may switch the forwarding path in a hot backup protection manner. If the SR policy does not include other candidate paths, the first network device may determine, by using a VPN FRR technique, the second forwarding path as a backup path. If the first network device does not determine the second forwarding path by using the VPN FRR technique, it may report failure information to the controller to request the controller to recalculate and issue the second forwarding path as a standby path. Based on the mode, the reliable switching of the forwarding path can be ensured, and the influence on the normal forwarding of the service flow is avoided.

And step 205, the first network device sends the second service packet through the second forwarding path.

After the first network device determines the second forwarding path, the second network device may send the second service packet through the second forwarding path. The second service packet and the first service packet belong to the same service flow. That is, the first network device may switch the service flow to which the first service packet belongs to the second forwarding path, so as to ensure normal forwarding of the service flow and avoid interruption of the service flow. The second service packet may also be an SRv6 packet, and the SRH of the second service packet may also include a segment list, where the segment list is used to indicate the second forwarding path. The structure of the second service packet may refer to the structure of the first service packet, which is not described herein again.

In this embodiment of the present application, a second identifier may be encapsulated in the second service packet, where the second identifier is used to determine the second forwarding path. It is to be understood that the second identifier may be a BSID of an SR policy to which the second forwarding path belongs, or the second identifier may be a path identifier of the second forwarding path, for example, the BSID of the second forwarding path.

It may also be understood that, if the first identifier and the second identifier are both BSIDs of the SR policy, and the second forwarding path is a candidate path in the SR policy to which the first forwarding path belongs (that is, the second forwarding path and the first forwarding path belong to the same SR policy), the second identifier and the first identifier may be the same. And if the first identifier and the second identifier are both path identifiers, or if the second forwarding path and the first forwarding path belong to different SR strategies, the second identifier is different from the first identifier.

For example, assume that the second forwarding path is a second candidate path in the SR policy to which the first forwarding path belongs. Referring to fig. 5, the pe1 may encapsulate the SRH in the second service packet, and a first segment identifier in a segment list of the SRH is PE3-VPNSID, segment identifiers from 2 nd to 4 th are segment identifiers of PE3, P4, and P2 in the second forwarding path in sequence, and a last segment identifier may carry the BSID of the SR policy: BSID1.

Or, it is assumed that the second forwarding path is a candidate path in another SR policy determined by PE1 based on the VPN FRR, and the BSID of the SR policy to which the second forwarding path belongs is BSID2. Referring to fig. 7, the pe1 may encapsulate the SRH in the second service packet, and a first segment identifier in a segment list of the SRH is PE4-VPNSID, segment identifiers 2 to 4 are segment identifiers of PE4, P4, and P2 in the second forwarding path in sequence, and a last segment identifier may carry the BSID of the other SR policy: BSID2.

Or, it is assumed that the second forwarding path is a forwarding path recalculated and issued by the controller 03, and the BSID of the SR policy to which the second forwarding path belongs is BSID2. Referring to fig. 8, pe1 may encapsulate an SRH in the second service message, and a first segment identifier in a segment list of the SRH is PE3-VPNSID, segment identifiers 2 to 4 are segment identifiers of PE4, P4, and P2 in the second forwarding path in sequence, and a last segment identifier may carry BSID2.

It can be understood that, the above embodiments are all described by taking the SRH carrying the first identifier as an example, and of course, the first identifier may also be encapsulated in other positions in the message, for example, in an IPv6 header of the message. In addition, the above embodiment has been described by taking an example in which the failure notification message is an ICMP message, but it is needless to say that the failure notification message may be other types of messages, for example, the failure notification message may be a message configured to notify a forwarding path failure.

It can also be understood that the execution sequence of each step in the above method for sensing a failure of a forwarding path may be adjusted according to the situation, and the steps may also be increased or decreased according to the situation. For example, the step 204 and the step 205 may be deleted according to the situation, that is, after the first network device determines that the first forwarding path fails, it may not be necessary to switch the path for forwarding the service packet. For example, the first network device may only report the fault information to the controller.

To sum up, the embodiment of the present application provides a method for sensing a failure of a forwarding path, where a first network device may carry a first identifier for determining a first forwarding path in a sent service message, and a second network device may feed back a failure notification message carrying the first identifier to the first network device after detecting that the first forwarding path has a failure. Thus, even if the end-to-end detection algorithm is not deployed in the first network device, the first forwarding path failure may be determined based on the first identifier in the failure notification message. According to the scheme provided by the embodiment of the application, the network equipment can quickly and accurately sense the fault of the forwarding path without deploying the end-to-end detection algorithm in the network equipment, so that the problems of high deployment complexity and low efficiency caused by deploying the end-to-end detection algorithm are effectively avoided.

In addition, according to the scheme provided by the embodiment of the application, the first network device does not need to periodically send the detection message to judge whether the first forwarding path fails, so that the utilization rate of the network bandwidth can be effectively improved, and the reliable sending of the service message is ensured.

Fig. 9 is a schematic structural diagram of a first network device according to an embodiment of the present application, where the first network device may be applied to a packet forwarding system shown in fig. 1, fig. 5, fig. 7, or fig. 8. For example, the first network device may be any network device 01 in the system shown in fig. 1, or may be PE1 in the system shown in fig. 5, fig. 7, or fig. 8. The first network device may implement the steps performed by the first network device in the embodiments shown in fig. 2 or fig. 3 described above. Referring to fig. 9, the first network device includes:

a sending module 301, configured to send a first service packet through a first forwarding path, where the first service packet includes a first identifier, and the first identifier is used to determine the first forwarding path. The functional implementation of the sending module 301 may refer to the related description of step 101 or step 201 in the above method embodiments.

A receiving module 302, configured to receive a failure notification message sent by the second network device in the first forwarding path, where the failure notification message includes the first identifier, and the failure notification message is used to indicate that the first forwarding path fails. The functional implementation of the receiving module 302 may refer to the related description of step 102 or step 202 in the above method embodiments.

Optionally, the sending module 301 may be further configured to send a second service packet through a standby forwarding path of the first forwarding path, where the second service packet and the first service packet belong to the same service flow. The functional implementation of the sending module 301 may also refer to the related description of step 205 in the above method embodiment.

As shown in fig. 9, the first network device may further include: a determining module 303, the determining module 303 configured to determine the second forwarding path as a backup path. The functional implementation of the determining module 303 may refer to the related descriptions of step 203 and step 204 in the above method embodiments.

The sending module 301 may be configured to send a second service packet encapsulated with a second identifier through the second forwarding path, where the second identifier is used to determine the second forwarding path.

As a possible example, the SR policy to which the first forwarding path belongs includes a plurality of candidate paths to which the first forwarding path belongs; the determination module 303 may be configured to: and determining a second forwarding path from the plurality of candidate paths as a standby path based on the fault notification message.

As another possible example, the determining module 303 may be configured to: and based on the fault notification message, determining a second forwarding path as a standby path by adopting a VPN FRR technology.

As another possible example, the sending module 301 may be further configured to send, based on the failure notification message, failure information to a controller, where the failure information is used to indicate that the first forwarding path fails; the determining module 303 may be configured to use the second forwarding path issued by the controller as a backup path.

Optionally, the first identifier may be a BSID of an SR policy to which the first forwarding path belongs; alternatively, the first identifier may be a path identifier of the first forwarding path.

Optionally, the SRH further includes a segment list and a flag field, the segment list including a plurality of segment identifications; one segment identifier in the segment list carries the first identifier, and the tag field is used for indicating that the segment list comprises the first identifier.

Optionally, the last segment identifier in the segment list carries the first identifier.

Optionally, the fault notification message includes an SRH, where the SRH carries the first identifier; or, the data field of the failure notification packet carries the first identifier.

Optionally, the failure notification message may be an ICMP message.

To sum up, the embodiment of the present application provides a first network device, where the first network device can carry a first identifier for determining a first forwarding path in a sent service message, and a second network device can feed back a failure notification message carrying the first identifier to the first network device after detecting a failure of the first forwarding path. Thus, even if the end-to-end detection algorithm is not deployed in the first network device, the first forwarding path failure may be determined based on the first identifier in the failure notification message. According to the scheme provided by the embodiment of the application, the first network device can quickly and accurately sense the fault of the forwarding path without deploying the end-to-end detection algorithm in the first network device, so that the problems of high deployment complexity and low efficiency caused by deploying the end-to-end detection algorithm are effectively avoided.

Fig. 10 is a schematic structural diagram of a second network device according to an embodiment of the present application, where the second network device may be applied to a packet forwarding system shown in fig. 1, fig. 5, fig. 7, or fig. 8. For example, the second network device may be any network device 01 in the system shown in fig. 1, or may be P3 in the system shown in fig. 5, fig. 7, or fig. 8. The second network device may implement the steps performed by the second network device in the embodiments shown in fig. 2 or fig. 3 described above. Referring to fig. 10, the second network device includes:

a receiving module 401, configured to receive a first service packet sent by a first network device through a first forwarding path, where the first service packet includes a first identifier, and the first identifier is used to determine the first forwarding path. The functional implementation of the receiving module 401 may refer to the related description of step 101 or step 201 in the above method embodiments.

A sending module 402, configured to send a failure notification message to the first network device if it is determined that the first forwarding path fails, where the failure notification message includes the first identifier, and the failure notification message is used to indicate that the first forwarding path fails. The functional implementation of the sending module 402 may refer to the related description of step 102 or step 202 in the above method embodiment.

Optionally, the fault notification message includes an SRH, where the SRH carries the first identifier; or, the data field of the fault notification packet carries the first identifier.

Optionally, the failure notification message is an ICMP message.

To sum up, the embodiment of the present application provides a second network device, where the second network device can receive a service packet that is sent by a first network device through a first forwarding path and carries a first identifier, and can feed back a failure notification packet that carries the first identifier to the first network device after detecting that a failure of the first forwarding path occurs. Thus, even if an end-to-end detection algorithm is not deployed in the first network device, the first forwarding path failure may be determined based on the first identifier in the failure notification message. According to the scheme provided by the embodiment of the application, the first network equipment can quickly and accurately sense the fault of the forwarding path without deploying the end-to-end detection algorithm in the first network equipment, so that the problems of high deployment complexity and low efficiency caused by deploying the end-to-end detection algorithm are effectively avoided.

It can be clearly understood by those skilled in the art that, for convenience and simplicity of description, the specific working processes of the first network device, the second network device, and each module described above may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

It should be understood that, in the embodiments of the present application, each of the first network device and the second network device may be implemented by an application-specific integrated circuit (ASIC), or a Programmable Logic Device (PLD), where the PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof. Alternatively, the method for sensing a failure of a forwarding path provided in the foregoing method embodiment may also be implemented by software, and when the method for sensing a failure of a forwarding path provided in the foregoing method embodiment is implemented by software, each module in the first network device and the second network device may also be a software module.

Fig. 11 is a schematic structural diagram of a network device according to an embodiment of the present application, where the network device may be applied to a message forwarding system shown in fig. 1, fig. 5, fig. 7, or fig. 8. For example, the network device may be any network device 01 in the system shown in fig. 1, or may be PE1 in the system shown in fig. 5, fig. 7, or fig. 8, or may be P3 in the system shown in fig. 5, fig. 7, or fig. 8. As shown in fig. 11, the network device may include: a processor 501, a memory 502, a transceiver 503, and a bus 504. The bus 504 is used to connect the processor 501, the memory 502, and the transceiver 503. Communication connections with other devices may be made through transceiver 503 (which may be wired or wireless). The memory 502 stores therein a computer program for realizing various application functions. When the various modules in the network device shown in fig. 10 are implemented as software modules, the programs corresponding to the software modules may be stored in the memory 502 of the network device.

It should be understood that, in the embodiment of the present application, the processor 501 may be a CPU, and the processor 501 may also be other general processors, digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), GPUs or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. The general purpose processor may be a microprocessor or any conventional processor or the like.

The memory 502 may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The non-volatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash memory. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (static RAM, SRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), and direct bus RAM (DR RAM).

The bus 504 may include a power bus, a control bus, a status signal bus, and the like, in addition to a data bus. But for clarity of illustration the various busses are labeled in the figures as bus 504.

On one hand, the processor 501 in the network device may be configured to send a first service packet through a first forwarding path, and receive a fault notification packet sent by a second network device in the first forwarding path; the first service packet includes a first identifier, the first identifier is used to determine the first forwarding path, the fault notification packet includes the first identifier, and the fault notification packet is used to indicate that the first forwarding path is faulty. The detailed processing procedure of the processor 501 may refer to the above-described method embodiments. For example, the detailed description of step 101 in the embodiment shown in fig. 2 may be referred to, or the detailed descriptions of step 201, and steps 203 to 205 in the embodiment shown in fig. 3 may be referred to, which are not described again here.

On the other hand, the processor 501 in the network device may be configured to receive a first service packet sent by a first network device through a first forwarding path, and send a failure notification packet to the first network device if it is determined that the first forwarding path fails; the first service packet includes a first identifier, the first identifier is used to determine a first forwarding path, the fault notification packet includes the first identifier, and the fault notification packet is used to indicate that the first forwarding path has a fault. The detailed processing procedure of the processor 501 may refer to the above-described method embodiments. For example, reference may be made to the detailed description of step 102 in the embodiment shown in fig. 2, or reference may be made to the detailed description of step 202 in the embodiment shown in fig. 3, which is not described herein again.

Fig. 12 is a schematic structural diagram of a network device according to an embodiment of the present application, where the network device may be applied to a message forwarding system such as the one shown in fig. 1, fig. 5, fig. 7, or fig. 8. For example, the network device may be any network device 01 in the system shown in fig. 1, or may be PE1 in the system shown in fig. 5, fig. 7, or fig. 8, or may be P3 in the system shown in fig. 5, fig. 7, or fig. 8. As shown in fig. 12, the network device may include: a main control board 601 and at least one interface board (interface board is also called line card or traffic board), for example, an interface board 602 and an interface board 603 are shown in fig. 12. Multiple interface boards can include a switch interface board 604, where the switch interface board 604 is used to complete the data exchange between the interface boards.

The main control board 601 is used to complete functions of system management, device maintenance, protocol processing, and the like. The interface boards 602 and 603 are used to provide various service interfaces (e.g., POS interface, GE interface, ATM interface, etc.), and implement forwarding of messages. The main control board 601 mainly has 3 types of functional units: the system comprises a system management control unit, a system clock unit and a system maintenance unit. The main control board 601, the interface board 602, and the interface board 603 are connected to the system backplane through a system bus to implement intercommunication. Included on the interface board 602 are one or more central processors 6021. The central processor 6021 is configured to control and manage the interface board 602, communicate with the central processor 6011 on the main control board 601, and forward a message. The forwarding table item memory 6024 on the interface board 602 is configured to store a forwarding table item, and the central processor 6021 may forward the message by looking up the forwarding table item stored in the forwarding table item memory 6024.

The interface board 602 includes one or more physical interface cards 6023 configured to receive the message sent by the previous-hop node and send the processed message to the next-hop node according to the instruction of the central processor 6021. The specific implementation process is not described in detail herein. The specific functions of the central processor 6021 are not repeated here again.

It is understood that the sending module 301 and the receiving module 302 in the first network device may be located in the interface board 602, and the determining module 303 may be located in the main control board 601. The receiving module 401 and the sending module 402 in the second network device may be located in the interface board 602.

It can also be understood that, as shown in fig. 12, in this embodiment, a plurality of interface boards are included, and a distributed forwarding mechanism is adopted, in this mechanism, the structure of the interface board 603 is substantially the same as that of the interface board 602, and operations on the interface board 603 are substantially similar to those of the interface board 602, and for brevity, details are not repeated. Furthermore, it is understood that the central processor 6021 and/or the network processor 6022 in the interface board 602 in fig. 12 may be dedicated hardware or chips, such as an application-specific integrated circuit, to implement the above functions, which is a way of processing the forwarding plane by using dedicated hardware or chips. In other embodiments, the central processor 6021 and/or the network processor 6022 may also employ a general-purpose processor, such as a general-purpose CPU, to implement the functions described above.

It should be further understood that the main control board 601 may have one or more blocks, and when there are more blocks, the main control board may include an active main control board and a standby main control board. The interface board may have one or more blocks, and the more data processing capacity the device has, the more interface boards are provided. Under the condition of a plurality of interface boards, the plurality of interface boards can communicate through one or a plurality of exchange network boards, and when a plurality of interface boards exist, the redundant backup of load sharing can be realized together. Under the centralized forwarding architecture, the 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 device comprises a plurality of interface boards, and can realize data exchange among the plurality of interface boards through a switching network board, thereby providing high-capacity data exchange and processing capacity. Therefore, the data access and processing capabilities of network devices in a distributed architecture are greater than those of devices in a centralized architecture. Which architecture is specifically adopted depends on a specific networking deployment scenario, and is not limited herein.

In particular embodiments, memory 6012 and Memory 6024 may be, but are not limited to, read-only Memory (ROM) or other types of static storage devices that may store static information and instructions, random Access Memory (RAM) or other types of dynamic storage devices that may store information and instructions, electrically erasable programmable read-only Memory (EEPROM), 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.), magnetic disk or other magnetic storage devices, 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 6024 in the interface board 602 may be independent and connected with the central processor 6021 via a communication bus; alternatively, the memory 6024 may be integrated with the central processor 6021. The memory 6012 in the main control board 601 may be independent and connected to the central processing unit 6011 through a communication bus; alternatively, the memory 6012 may be integrated with the central processor 6011.

The memory 6024 is used for storing program codes and is controlled by the central processor 6021, and the memory 6012 is used for storing program codes and is controlled by the central processor 6011. The central processor 6021 and/or the central processor 6011 may implement the failure sensing method applied to the forwarding path of the first network device or the second network device provided in the foregoing embodiments by executing the program code. Memory 6024 and/or memory 6012 may store program code that includes one or more software modules therein. The one or more software modules may be the functional modules provided in the embodiments shown in fig. 9 or fig. 10 described above.

In an embodiment, the physical interface card 6023 may be any device using any transceiver or the like for communicating with other devices or communication networks, such as ethernet, radio Access Network (RAN), wireless Local Area Network (WLAN), and the like.

The embodiment of the present application further provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and the instructions are executed by a processor to implement the method for sensing a failure of a forwarding path executed by a first network device or a second network device, which is provided in the foregoing method embodiment.

Embodiments of the present application further provide a computer program product including instructions, which when run on a computer, cause the computer to execute the method for fault awareness of a forwarding path executed by a first network device or a second network device, which is provided in the foregoing method embodiments.

An embodiment of the present application further provides a packet forwarding system, as shown in fig. 1, where the packet forwarding system includes: a plurality of network devices 01. The plurality of network devices 01 may include at least a first network device as shown in fig. 9, 11 or 12, and may include a second network device as shown in fig. 10, 11 or 12.

Optionally, the message forwarding system may be an SRv6 system.

The embodiment of the present application further provides a chip, where the chip may be used to implement the method for sensing a failure of a forwarding path executed by the first network device or the second network device, which is provided in the foregoing method embodiment.

The above embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, the above-described embodiments 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 instructions. When loaded or executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer 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 instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. 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, data center, etc. that contains one or more collections of available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium may be a Solid State Drive (SSD).

The term "at least one" in this application means one or more, and the term "plurality" in this application means two or more, e.g., a plurality of nodes means two or more nodes. The terms "system" and "network" are often used interchangeably herein. Reference herein to "and/or" means that three relationships may exist, for example, a and/or B may represent: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

The above description is only an alternative embodiment 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.

Claims

1. A failure sensing method of a forwarding path is characterized in that the method is applied to a first network device; the method comprises the following steps:

sending a first service message through a first forwarding path, wherein the first service message comprises a first identifier, and the first identifier is used for determining the first forwarding path;

and receiving a fault notification message sent by a second network device in the first forwarding path, where the fault notification message includes the first identifier, and the fault notification message is used to indicate that the first forwarding path has a fault.

2. The method of claim 1, further comprising:

and sending a second service message through a standby path of the first forwarding path based on the fault notification message, wherein the second service message and the first service message belong to the same service flow.

3. The method according to claim 2, characterized in that the segment routing SR policy to which the first forwarding path belongs comprises a plurality of candidate paths to which the first forwarding path belongs; the sending a second service packet through the backup path of the first forwarding path includes:

determining a second forwarding path from the plurality of candidate paths as the standby path based on the fault notification message;

and sending a second service message encapsulated with a second identifier through the second forwarding path, wherein the second identifier is used for determining the second forwarding path.

4. The method of claim 2, wherein sending the second traffic packet via the backup path of the first forwarding path comprises:

based on the fault notification message, determining a second forwarding path as the standby path by adopting a Virtual Private Network (VPN) fast reroute (FRR) technology;

5. The method of claim 2, wherein sending the second traffic packet via the backup path of the first forwarding path comprises:

based on the fault notification message, sending fault information to a controller, wherein the fault information is used for indicating the fault of the first forwarding path;

a second forwarding path issued by the controller is used as the standby path;

6. The method according to any of claims 1 to 5, wherein the first identifier is a binding segment identifier of an SR policy to which the first forwarding path belongs;

or, the first identifier is a path identifier of the first forwarding path.

7. The method according to any one of claims 1 to 6, wherein the first service packet includes a route extension header (SRH), and the SRH carries the first identifier.

8. The method of claim 7, wherein the SRH further comprises a segment list and a tag field, wherein the segment list comprises a plurality of segment identifications;

one segment identifier in the segment list carries the first identifier, and the tag field is used for indicating that the segment list includes the first identifier.

9. The method of claim 8, wherein the first identifier is carried by a last segment identifier in the segment list.

10. The method according to any one of claims 1 to 9, wherein the failure notification packet includes an SRH, and the SRH carries the first identifier;

or, the data field of the failure notification packet carries the first identifier.

11. The method according to any of the claims 1 to 10, wherein said failure notification message is an internet control information protocol, ICMP, message.

12. A failure sensing method of a forwarding path is applied to a second network device; the method comprises the following steps:

receiving a first service message sent by a first network device through a first forwarding path, wherein the first service message comprises a first identifier, and the first identifier is used for determining the first forwarding path;

and if the first forwarding path fails, sending a failure notification message to the first network device, where the failure notification message includes the first identifier, and the failure notification message is used to indicate that the first forwarding path fails.

13. The method according to claim 12, wherein the failure notification packet includes a route extension header SRH, and the SRH carries the first identifier;

14. The method according to claim 12 or 13, wherein the failure notification message is an internet control information protocol ICMP message.

15. The method according to any of claims 12 to 14, wherein the first identifier is a binding segment identifier of a segment routing, SR, policy to which the first forwarding path belongs;

or, the first identifier is a path identifier of the first forwarding path.

16. The method according to any of claims 12 to 15, wherein the first service packet includes an SRH, and the SRH carries the first identifier.

17. The method of claim 16 wherein the SRH further comprises a segment list and a flag field, the segment list comprising a plurality of segment identifications;

one segment identifier in the segment list carries the first identifier, and the tag field is used for indicating that the segment list comprises the first identifier.

18. A first network device, wherein the first network device comprises:

a sending module, configured to send a first service packet through a first forwarding path, where the first service packet includes a first identifier, and the first identifier is used to determine the first forwarding path;

a receiving module, configured to receive a fault notification message sent by a second network device in the first forwarding path, where the fault notification message includes the first identifier, and the fault notification message is used to indicate that the first forwarding path has a fault.

19. The first network device of claim 18, wherein the sending module is further configured to:

20. The first network device of claim 19, wherein the segment routing, SR, policy to which the first forwarding path belongs comprises a plurality of candidate paths to which the first forwarding path belongs; the first network device further includes:

a determining module, configured to determine, based on the fault notification packet, a second forwarding path from the multiple candidate paths as the standby path;

the sending module is configured to send a second service packet encapsulated with a second identifier through the second forwarding path, where the second identifier is used to determine the second forwarding path.

21. The first network device of claim 19, wherein the first network device further comprises:

a determining module, configured to determine, based on the fault notification packet, a second forwarding path as the backup path by using a virtual private network VPN fast reroute FRR technique;

the sending module is configured to send a second service packet encapsulated with a second identifier through the second forwarding path, where the second identifier is used to determine the second forwarding path, and the second identifier is used to determine the second forwarding path.

22. The first network device of claim 19,

the sending module is further configured to send fault information to a controller based on the fault notification packet, where the fault information is used to indicate that the first forwarding path has a fault;

the first network device further comprises: the determining module is used for taking a second forwarding path issued by the controller as the standby path;

23. A second network device, the second network device comprising:

a receiving module, configured to receive a first service packet sent by a first network device through a first forwarding path, where the first service packet includes a first identifier, and the first identifier is used to determine the first forwarding path;

a sending module, configured to send a failure notification message to the first network device if it is determined that the first forwarding path fails, where the failure notification message includes the first identifier, and the failure notification message is used to indicate that the first forwarding path fails.

24. A computer-readable storage medium having stored thereon instructions for execution by a processor to perform the method of any one of claims 1 to 17.

25. A message forwarding system, the message forwarding system comprising: a first network device as claimed in any one of claims 18 to 22, and a second network device as claimed in claim 23.