WO2018010560A1 - Method, apparatus, and system for detecting and processing multi-protocol label switching - Google Patents

Abstract

Provided in the embodiments of the present invention are a method, an apparatus, and a system for detecting and processing multi-protocol label switching, the method for detecting multi-protocol label switching comprising: detecting an echo request packet sent by an initiating party, the echo request packet comprising a type field used for identifying multi-protocol label switching (MPLS) operation administration and maintenance (OAM) packets; receiving an echo response packet fed back by a transmission node or egress node on the basis of the MPLS OAM packets, and detecting whether the echo response packet matches pre-stored information. The embodiments of the present invention solve the problem in the prior art of LSP detection distortion and P2MP LSP detection being inefficient and insufficient.

Description

Multi-protocol exchange label detection, processing method, device and system Technical field

The embodiments of the present invention relate to the field of communications, and in particular, to a method, a device, and a system for detecting and processing a multi-protocol exchange tag.

Background technique

In the related art, P2P (peer to peer) LSP ping/trace and P2MP (peer to multiple peer) LSP ping/trace are operated, managed, and maintained by using Multi-protocol Label Switching (MPLS). The Administration and Maintenance (OAM) packet is transmitted on the same path as the MPLS data packet. The data plane does not recognize the MPLS OAM packet. The packet expires due to the time-to-live (Time To Live, TTL for short). When the egress node is sent to the control plane from the data plane, the control plane identifies the MPLS OAM packet and performs subsequent processing. Rfc4379 (Label Switching Path (LSP) ping/trace) and rfc5884 (MPLS BFD) both pass the IP header based TTL=1 and the destination IP is 127.0.0.0/8 (IPv4) or 0:0: 0:0:0:FFFF:127.0.0.0/104 (IPv6) These flags are used to initially identify MPLS OAM packets, and rfc5586 (MPLS g-ACH) identifies MPLS OAM packets through the GAL (Special Label 13) flag. However, these are not suitable for the data plane that does not want to perform deep analysis on the packet to identify the specific packet. When these flags are not exposed on the data plane, and the MPLS OAM packet is not sent from the data plane to the control plane, the data is The plane does not know that it is an MPLS OAM message.

The data link layer defines whether the type field identifies whether it is an MPLS unicast packet or a multicast packet (rfc3032, rfc5332). However, there is no corresponding standard definition to identify whether it is an MPLS OAM packet or an MPLS data packet, except for the Ethernet link. The ethernet type is used for specific Ethernet OAM mechanisms (such as 802.1ag, 802.3ah, Y.1731), but these definitions cannot be applied to MPLS OAM.

In some scenarios, the data plane also needs to be perceived in advance in a quick way to be MPLS. On the premise of consistent with the forwarding of MPLS data packets, OAM packets do some auxiliary processing that is independent of the forwarding path.

The P2P LSP ping/trace standard in the related art has the following problems:

1) According to rfc4379, when there is ECMP in the detected target FEC, multipath information is divided into multiple fragments by simulating load sharing on the control plane, and then multiple echo requests (including different multipath information fragments respectively) are sent based on the division result to expect Traverse the complete path. The key problems are: a) the simulated load sharing result of the control plane is not necessarily the same as the actual load sharing result of the data plane; b) the original multipath information may not meet the fragmentation requirement of load sharing, that is, there is a problem of insufficient allocation. These all lead to detection distortion. In fact, the essential requirement of the LSP ping is to detect the data plane connectivity and ensure that the data plane is consistent with the forwarding entries of the control plane. As long as we MPLS OAM packets are strictly forwarded according to the real load of the data plane.

2) According to rfc6424, if an FEC change occurs during the detection process, the node that needs to perceive the FEC change returns the FEC change information to the Initiator node, so that the Initiator carries the changed target FEC stack in the subsequent echo request. However, there is an obvious flaw in the standard that is only applicable to the trace route mode. In the ping mode, the node that senses the FEC change will not return the FEC change information to the Initiator node, which means that as long as the FEC change occurs, the LSP ping will be performed. Will get the result of the path is not available.

The P2MP LSP ping/trace standard in the related art has the following problems of detecting inefficiency and insufficiency:

1) According to rfc6425, the Initiator does not precisely control whether the echo reply message is received and then initiates the next echo request. That is to say, the timing of sending the next request is uncertain. If the Initiator sends the next echo request every time it receives an echo reply, it needs to cache a large number of historical echo requests in order to wait for those late echo requests.

2) Since the sending of the echo request is not strictly controlled, the received echo reply may burst and cause congestion. Although a solution has been proposed, it is not perfect. For example, a method that returns a random delay when echo reply will slow down the detection process; only a specific node will return echo. The reply method only supports specifying a single node or a route node assigned to a single egress.

3) Because the "Address Type" field in the Downstream Detailed Mapping TLV included in the echo request is set to IPv4Unnumbered or IPv6Unnumbered, and the "Downstream IP Address" field is set to the ALLROUTERS multicast address, the interface consistency check cannot be performed on the responder node. It is impossible to strictly check whether the forwarding information of the control plane and the forwarding plane are consistent.

In view of the above problems in the related art, no effective solution has been found yet.

Summary of the invention

The embodiments of the present invention provide a method, a device, and a system for detecting and processing a multi-protocol exchange label, so as to solve the problem that the LSP detection distortion and the P2MP LSP detection are inefficient and insufficient in the related art.

According to an embodiment of the present invention, a method for detecting a multi-protocol switching label is provided, including: detecting an initiator sending an echo request packet, where the echo request packet includes an MPLS operation for identifying a multi-protocol switching label Maintaining the type field of the management OAM packet; receiving the response response message fed back by the transit node or the egress node according to the MPLS OAM packet, and detecting whether the response response packet matches the pre-stored information.

Optionally, the response request message further includes: downstream mapping information, where the downstream mapping information corresponds to one or more next hop routes of the response request message.

Optionally, the detecting the initiator sending the response request message further includes: detecting, by the initiator, whether the response request message is an initial response request message sent by the initial node; if the determination result is yes, detecting that the initiator is When the response request message is sent, the downstream mapping information in the response request message is locally saved in the initial node.

Optionally, in the case that the determination result is negative, when the response request message is sent, the detecting initiator locally saves the downstream mapping information carried in the last round of the response response message in the initial node.

Optionally, the type field is encapsulated in a data link layer header of the response request message.

Optionally, detecting whether the response response message matches the pre-stored information includes: detecting whether a sender handle Sender's Handle in the response response message matches a first corresponding field in the response request message, and detecting Whether the sequence number in the response response message matches the second corresponding field in the response request message; the Sender's Handle matches the first corresponding field, and the serial number and the second When the corresponding field matches, it is determined whether the upstream interface information in the response response message matches the downstream mapping information saved locally by the initial node, and the upstream interface information in the response response message is locally saved with the initial node. When the downstream mapping information matches, it is determined that the response response message matches the pre-stored information.

Optionally, determining whether the upstream interface information in the response response packet matches the downstream mapping information, when determining that the plurality of downstream mapping information is locally saved, Corresponding to the response response message matching; determining whether the matching success rate of the plurality of downstream mapping information and the plurality of the response response messages saved locally is greater than a preset threshold.

Optionally, after detecting whether the response response message matches the pre-stored information, the method further includes: determining, according to the detection result that the response response message matches the pre-stored information, whether to send the next response request message.

Optionally, determining, according to the detection result that the response response message matches the pre-stored information, whether to send the next response request message includes: detecting a transmission mode of the response request message; and searching for the Internet packet in the transmission mode When the ping (Packet Internet Groper) mode is used, the next response request message is discarded; and/or, according to whether the locally saved downstream mapping information satisfies the matching policy, whether to send the next response request message is determined.

According to another embodiment of the present invention, a method for processing a multi-protocol exchange label is provided, including: receiving an echo request message, where the response request message includes an MPLS operation maintenance management for identifying a multi-protocol exchange label. The type field of the OAM packet; the MPLS OAM packet is identified by the type field; and the response request packet is forwarded according to the preset forwarding entry.

Optionally, the forwarding plane forwards the response request message according to the preset forwarding entry, and the forwarding plane forwards the response request message to the control according to the first preset forwarding entry. a plane, and feedback the response response message of the response request message; the forwarding plane modifies the content of the MPLS OAM message, and forwards the response request message to the data plane according to the second preset forwarding entry Next hop node.

Optionally, modifying, by the forwarding plane, the content of the MPLS OAM packet includes: modifying downlink mapping information in the response request packet.

According to another embodiment of the present invention, a device for detecting a multi-protocol exchange label is provided, comprising: a sending module, configured to send an echo request message, wherein the response request message includes a multi-protocol exchange for identifying The labeling MPLS operation maintains and manages the type field of the OAM packet. The detecting module is configured to receive the response response message fed back by the transmitting node or the egress node according to the MPLS OAM packet, and detect whether the response response packet matches the pre-stored information. .

Optionally, the response request message further includes: downstream mapping information, where the downstream mapping information corresponds to one or more next hop routes of the response request message.

According to another embodiment of the present invention, a processing apparatus for a multi-protocol exchange label is provided, including: a receiving module, configured to receive an echo request message, where the response request message includes a multi-protocol exchange for identifying The tag MPLS operation maintains the type field of the OAM message; the identification module is configured to identify the MPLS OAM message by using the type field, and the forwarding module is configured to forward the response request message according to the preset forwarding entry.

According to still another embodiment of the present invention, a detection system for a multi-protocol switching label is provided, including an initial node, a transit node, or an egress node, where the initial node further includes:

The sending module is configured to send a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message; and the detecting module is configured to receive the transmission node or the egress node. And responding to the response message sent by the MPLS OAM packet, and detecting whether the response response message matches the pre-stored information; the transmitting node or the egress node further includes: a receiving module, configured to receive the response request message, where The response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message; the identification module is configured to identify the MPLS OAM packet by using the type field; and the forwarding module is set to be based on the pre- Let the forwarding entry be the response request The packet is forwarded to the control plane, and the response response message of the response request message is fed back.

According to still another embodiment of the present invention, a storage medium is also provided. The storage medium is arranged to store program code for performing the following steps:

Sending a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message;

The receiving transmission node or the egress node responds to the response message sent by the MPLS OAM packet, and detects whether the response response message matches the pre-stored information.

According to the embodiment of the present invention, the response request message is sent, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message; the receiving transmission node or the egress node is according to the MPLS The OAM packet feedback response message is sent, and it is detected whether the response response message matches the pre-stored information. The response request message carries a type field for identifying the multi-protocol switching label MPLS operation and maintenance management OAM packet, so that the forwarding plane of the transport node modifies the packet according to the actual forwarding information, and a corresponding set of detection processing procedures. Therefore, the problem of LSP detection distortion and P2MP LSP detection inefficiency and insufficiency in the related art can be solved.

DRAWINGS

The drawings described herein are intended to provide a further understanding of the invention, and are intended to be a part of the invention. In the drawing:

1 is a flowchart of a method for detecting a multi-protocol exchange tag according to an embodiment of the present invention;

2 is a flowchart of a method for processing a multi-protocol exchange tag according to an embodiment of the present invention;

3 is a structural block diagram of a multi-protocol exchange tag detecting apparatus according to an embodiment of the present invention;

4 is a structural block diagram of a processing apparatus for a multi-protocol exchange tag according to an embodiment of the present invention;

5 is a structural block diagram of a detection system for a multi-protocol exchange tag according to an embodiment of the present invention;

6 is a format diagram of an LSP ping echo request/reply message according to an embodiment of the present invention;

7 is a format diagram of a Downstream Mapping TLV according to an embodiment of the present invention;

8 is a format diagram of an Upstream Interface TLV according to an embodiment of the present invention;

9 is a format diagram of a Responder Egress TLV according to an embodiment of the present invention;

10 is a format diagram of a Responder Transit TLV according to an embodiment of the present invention;

11 is a flowchart of an Initiator node sending an echo request message according to an embodiment of the present invention;

12 is a flowchart of receiving an echo request message by a Transit or Egress node according to an embodiment of the present invention;

13 is a flowchart of a send reply message sent by a Responder node according to an embodiment of the present invention;

14 is a flowchart of an Initiator node receiving an echo reply message according to an embodiment of the present invention;

Figure 15 is a network topology diagram according to Example 1 of the present invention;

16 is a network topology diagram according to Example 2 of the present invention;

Figure 17 is a network topology diagram in accordance with Example 3 of the present invention.

detailed description

The invention will be described in detail below with reference to the drawings in conjunction with the embodiments. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict.

It is to be understood that the terms "first", "second" and the like in the specification and claims of the present invention are used to distinguish similar objects, and are not necessarily used to describe a particular order or order.

Example 1

In this embodiment, a method for detecting a multi-protocol exchange label is provided. FIG. 1 is a flowchart of a method for detecting a multi-protocol exchange label according to an embodiment of the present invention. As shown in FIG. Including the following steps:

Step S102: The initiating party sends an echo request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message.

Step S104: Receive an echo response message fed back by the transit node or the egress node according to the MPLS OAM packet, and detect whether the response response packet matches the prestored information. Optionally, the execution subject may be the detection initiator, or the detection party (same or different from the detection initiator).

And the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM packet, and the receiving transmission node or the egress node responds according to the MPLS OAM packet feedback. The response message is sent, and it is detected whether the response response message matches the pre-stored message. The type field of the MPLS operation and maintenance management OAM packet for the multi-protocol exchange label is carried in the response request packet, so that the forwarding plane of the transmission node modifies the packet according to the actual forwarding information, and a corresponding set of detection processing flows. Therefore, the problem of LSP detection distortion and P2MP LSP detection inefficiency and insufficiency in the related art can be solved.

Optionally, the response request message further includes: downstream mapping information, where the downstream mapping information corresponds to one or more next hop routes of the response request message.

Specifically, the detecting initiator sends the response request message, which further includes:

S11. The detecting initiator determines whether the response request message is an initial response request message sent by the initial node.

S12. If the determination result is yes, when the response request message is sent, the initiator detects that the initiator maps the downstream mapping information in the response request message locally. If the result of the determination is negative, the detecting initiator locally saves the downstream mapping information carried in the last round of response response packets at the initial node when sending the response request message.

Optionally, the type field is encapsulated in the data link layer header of the response request message.

Optionally, detecting whether the response response message matches the pre-stored information specifically includes:

S21. Detect whether the sender corresponding handle Sender's Handle in the response response message matches the first corresponding field in the response request message, and detects whether the sequence number in the response response message and the second corresponding field in the response request message are match;

S22: When the Sender's Handle matches the first corresponding field, and the sequence number matches the second corresponding field, determining whether the upstream interface information in the response response message matches the downstream mapping information saved locally by the initial node, and responding to the response message. When the upstream interface information matches the downstream mapping information saved locally by the initial node, it is determined that the response response message matches the pre-stored information.

Optionally, when the multiple downstream mapping information is saved locally, determining whether the upstream interface information in the response response packet matches the downstream mapping information includes the following two methods:

Determining whether multiple downstream mapping information saved locally has a corresponding response response message matching;

It is determined whether the matching success rate of the multiple saved downstream mapping information and the multiple response response packets is greater than a preset threshold.

Optionally, after detecting whether the response response message matches the pre-stored information, the method further includes: determining, according to the detection result that the response response message matches the pre-stored information, whether to send the next response request message. Further, determining whether to send the next response request message according to the detection result that the response response message matches the pre-stored information includes: detecting a transmission mode of the response request message; and abandoning the transmission when the transmission mode is the Internet packet explorer ping mode The next response request message; and/or, determining whether to send the next response request message according to whether the locally saved downstream mapping information satisfies the matching policy.

In this embodiment, a method for processing a multi-protocol exchange label is provided, which is applicable to a transmission node or an egress node corresponding to the multi-protocol exchange label detection method, and FIG. 2 is a multi-protocol exchange according to an embodiment of the present invention. A flowchart of a method for processing a label, as shown in FIG. 2, the flow includes the following steps:

Step S202, receiving a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message;

Step S204: Identify an MPLS OAM packet by using a type field.

Step S206: Forward the response request message according to the preset forwarding entry.

Optionally, the forwarding plane forwards the response request message according to the preset forwarding entry, including one of the following:

The forwarding plane forwards the response request message to the control plane according to the first preset forwarding entry, and feeds back the response response message of the response request message;

The forwarding plane modifies the content of the MPLS OAM packet, and forwards the response request packet to the next hop node of the data plane according to the second preset forwarding entry.

Optionally, the forwarding plane modifies the content of the MPLS OAM packet, including: the downstream mapping information in the forwarding plane modification response request packet.

Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware, but in many cases, the former is A better implementation. Based on such understanding, the technical solution of the present invention, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk, The optical disc includes a number of instructions for causing a terminal device (which may be a cell phone, a computer, a server, or a network device, etc.) to perform the methods of various embodiments of the present invention.

Example 2

In this embodiment, a multi-protocol exchange label detecting apparatus, a multi-protocol exchange label processing apparatus, and a multi-protocol exchange label detecting system are provided to implement the above embodiments and preferred embodiments, which have been described. No longer. As used below, the term "module" may implement a combination of software and/or hardware of a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.

FIG. 3 is a structural block diagram of a multi-protocol exchange label detecting apparatus according to an embodiment of the present invention. As shown in FIG. 3, the apparatus includes:

The sending module 30 is configured to send an echo request message, where the response request message includes a type field for identifying an OAM packet of the MPLS operation and maintenance management of the multi-protocol switching label;

The detecting module 32 is configured to receive an echo response message fed back by the transit node or the egress node according to the MPLS OAM packet, and detect whether the response response packet matches the pre-stored information.

Optionally, the response request message further includes: downstream mapping information, where the downstream mapping information corresponds to one or more next hop routes of the response request message.

4 is a structural block diagram of a processing apparatus for a multi-protocol exchange tag according to an embodiment of the present invention. As shown in FIG. 4, the device includes:

The receiving module 40 is configured to receive a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message;

The identification module 42 is configured to identify the MPLS OAM message by using the type field;

The forwarding module 44 is configured to forward the response request message according to the preset forwarding entry.

FIG. 5 is a structural block diagram of a detection system for a multi-protocol exchange label according to an embodiment of the present invention. As shown in FIG. 5, the system includes: an Initiator initial node 50, a Transit transmission node 52, or an Egress exit node 52.

The initial node 50 also includes:

The sending module 502 is configured to send a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message;

The detecting module 504 is configured to receive an echo response message fed back by the transit node or the egress node according to the MPLS OAM packet, and detect whether the response response packet matches the prestored information.

Transfer node 52 or egress node 52 also includes:

The receiving module 522 is configured to receive a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message;

The identification module 524 is configured to identify the MPLS OAM message by using the type field;

The forwarding module 526 is configured to forward the response request message to the control plane according to the preset forwarding entry, and feed back the response response message of the response request message.

It should be noted that each of the above modules may be implemented by software or hardware. For the latter, the foregoing may be implemented by, but not limited to, the foregoing modules are all located in the same processor; or, the above modules are in any combination. The forms are located in different processors.

Example 3

In this implementation, according to an optional embodiment of the present invention, the present application is specifically described in detail in conjunction with a specific scenario:

The method for detecting MPLS LSP in this embodiment includes the following steps:

first step:

When sending an echo request message, the Initiator node sets a type field in the encapsulated data link layer header to indicate that it is an MPLS OAM packet. The Downstream Mapping TLV (Type Length Value) contained in the echo request always corresponds to the next hop to be sent.

When the initiator sends the first echo request, it needs to save the corresponding next hop's Downstream Mapping information, so that it can be used to match the subsequent echo reply. In the case of a non-first echo request, the Initiator saves the Downstream Mapping information copied in the previous round of echo reply.

The Downstream Mapping contained in the echo request sent by the Initiator always corresponds to the next hop to be sent, regardless of the subsequent echo reply.

The second step:

The data plane of the transit node or the egress node is forwarded through the data link layer header to identify the MPLS OAM packet (that is, the echo request packet), and then forwards the packet according to the forwarding entry consistent with the data packet forwarding. :1) If the control plane is sent, the control plane will process the echo reply to the Initiator node as a Responder node; 2) If the data plane continues to forward to the next hop, the data is directly in the data according to the MPLS OAM message. After the MPLS OAM packet is modified, the MPLS OAM packet is modified. If the Downstream Mapping TLV content is modified in the echo request, the Downstream Mapping TLV included in the echo request only corresponds to the next hop to be sent. Continue to set in the data link layer header. Type field to indicate as an MPLS OAM message. Note that if it is a normal data packet, there is no such step, which avoids affecting the forwarding efficiency of ordinary data packets.

third step:

After receiving the echo reply of the Responde node, the Initiator node first matches the corresponding field in the Sequence Number and the echo request according to the Sender's Handle in the echo reply, and then matches the Upstream Interface TLV in the echo reply with the locally saved Downstream Mapping information to determine Whether all the locally saved Downstream mapping information has the corresponding echo reply matching, and the next echo request is sent. The default policy is that all locally saved Downstream mapping information has the corresponding echo reply matching before sending the next echo request. A policy can also be adopted to send the next echo request, or other policy, as long as the locally saved Downstream Mapping information matches the success ratio greater than a certain threshold. The Initiator obtains the Downstream Mapping information from the matched echo reply and saves it for matching with the next round of echo reply before sending the next round of the echo request.

To overcome the problems of P2P LSP detection distortion and P2MP LSP detection inefficiency and insufficiency in the prior art, and provide a unified MPLS LSP detection method, which adopts the method of the present invention and unifies P2P compared with the prior art. The process of detecting LSP and P2MP LSP improves the detection efficiency and overcomes the problems of detection distortion and insufficient detection.

The implementation of the technical solution will be further described in detail below with reference to the accompanying drawings:

6 is a format diagram of an LSP ping echo request/reply message according to an embodiment of the present invention, which is basically the same as rfc4379 except that a new flag is added to the Global Flags:

C (Constant) flag: used in the echo request message, set to 1 indicates that the target FEC stack remains unchanged during the detection process, and FEC change is not supported. For example, if a packet enters a tunnel that is outside, it is forced to process the outer tunnel according to the PIPE type. Otherwise, it is necessary to distinguish that the outer tunnel is UNIFORM or PIPE for differentiation. For example, if the packet enters another blocked LSP or the current tunnel is terminated, the target FEC stack is also not changed. The C flag defaults to 0. The LSP ping command design needs to introduce corresponding parameters for setting the C. Sign.

7 is a format diagram of a Downstream Mapping TLV according to an embodiment of the present invention, in which a field related to multipath information of a Downstream Mapping TLV in rfc4379 is deleted, and the reserved field is basically the same as rfc4379 except:

1) Three new flags are added to DS Flags:

E flag: Set to 1 to indicate that the next hop corresponding to the Downstream Mapping TLV is an ECMP member. Used in echo reply.

M flag: Set to 1 to indicate that the next hop corresponding to the Downstream Mapping TLV is a multicast member. Used in echo reply.

The R flag is set to 1 to indicate that the next hop corresponding to the Downstream Mapping TLV is indirectly connected. Used in echo request/reply.

2) Downstream Labels refers only to the labels corresponding to each FEC in the target FEC stack, and does not include other outer labels.

8 is a format diagram of an Upstream Interface TLV according to an embodiment of the present invention, in which a field related to tag information in an Interface and Label Stack TLV in rfc4379 is deleted, and the reserved field has the same definition as rfc4379.

9 is a format diagram of a Responder Egress TLV according to an embodiment of the present invention, and FIG. 10 is a format diagram of a Responder Transit TLV according to an embodiment of the present invention. The Egress and Transit nodes may include their own address when replying to an Initiator node with an echo reply. Information so that the Initiator node evaluates whether an echo reply has been received from the desired node.

This embodiment also uses the Target FEC Stack TLV defined in rfc4379, which has not been modified.

Next, we will introduce the specific sending and receiving process of the echo request and the echo reply message.

11 is a flowchart of an Initiator node sending an echo request message according to an embodiment of the present invention, including

Step S601, the Initiator node initiates an LSP ping or LSP for a target FEC. The traceroute process constructs an echo request message.

Step S602, the Initiator node constructs an echo request PDU (Protocol Data Unit) as follows:

1) Select a Sender's Handle and a Sequence Number. When the echo request is sent continuously, increment the Sequence Number by 1. Note that if there is ECMP (Equal-Cost Multipath Routing) in the P2P LSP, the echo request will only be sent to one ECMP member; and the P2MP LSP will be sent to each multicast member. In this case, any The sequence number in the echo request sent to each multicast member at the same time is the same.

2) The TimeStamp Sent field is set to the relative time of day, seconds and microseconds.

3) The TimeStamp Received field is set to 0.

4) The Reply Mode is set to the desired mode, indicating that the echo reply is expected to be returned to the Initiator node along IP or some other way. Return Code and Subcode are set to 0.

5) Contains the target FEC stack TLV, indicating the detected target FEC.

6) Set the C flag in Global Flags according to the parameters passed in the LSP ping command.

7) In the traceroute mode, the Downstream Mapping TLV is included, corresponding to the next hop to be sent. The DS Flags are marked with an I, indicating that the responder node wants to include the Upstream Interface TLV when replying to the echo reply. The next hop here refers to the next hop on the Initiator node to the top-level target FEC in the target FEC stack. In particular, when the C flag is invalid, when the Initiator node finds that the forwarding entry to the top-level target FEC is to enter the outer PIPE tunnel, it refers to the far-end next hop before the iterative tunnel iteration. In this case, DS Flags The R flag is set to be valid; if it is to enter the outer UNIFORM type tunnel, it means the next hop after the iterative tunnel iteration. At this time, the R flag in the DS Flags is set to be invalid. In this case, the Initiator can be at the target FEC. The top layer of the stack continues to insert the FEC of the UNIFORM tunnel. When the C flag is valid, when the Initiator node finds that the forwarding entry to the top-level target FEC enters the outer-layer tunnel, it does not distinguish between PIPE or UNIFORM, which refers to the far-end next hop before the iterative tunnel iteration. The R flag in Flags is set to be valid.

In step S603, the Initiator node constructs an IP/UDP header as follows:

1) The source IP is a routable IP address of the sender.

2) The destination IP is randomly selected from 127/8, or randomly selected from 0:0:0:0:0:FFFF:127/104

3) IP TTL=1

4) Source PORT is selected by the sender

5) The destination PORT is 3503

6) Router Alert option must be set

Step S604, the Initiator node encapsulates the label stack for the echo request message, and includes the label corresponding to the target FEC stack and any possible outer layer tunnel labels.

In the step S605, the Initiator node encapsulates the data link layer for the echo request packet, and sets the type field (such as setting the ethernet type to a specific value when the Ethernet link is used) to indicate that it is an MPLS OAM packet.

In step S606, the Initiator node maintains the target responder identifiers, indicating which echo replys are expected to be received by the node, as one of the basis for determining whether the detection is completed.

In step S607, the Initiator node determines whether it is the first round of echo request.

In step S608, if it is the first round of the echo request, the Downstream Mapping information corresponding to the next hop to be sent by the first round of the echo request is saved, and is used to accurately match the next round of echo reply.

The P2P LSP refers to the next hop of the top-level target FEC on the Initiator node to the target FEC stack. If multiple next hops form ECMP, the echo request will only be sent to one of the next hops, so the Initiator only needs to save. Downstream mapping information corresponding to this next hop, where DS Flags is marked with E. In step 602, the next hop here is determined based on the C flag and whether the PIPE/UNIFORM type of the outer tunnel is entered.

The P2MP LSP is the Downstream mapping information corresponding to each multicast member in the multicast forwarding entry of the Initiator node to the target FEC. The Initiator needs to save multiple Downstream mapping information, in which DS Flags are marked with M.

In step S609, if it is not the first round of echo request, the Downstream Mapping information obtained from the previous round of matching echo replys is saved, and is used to accurately match the next round of echo reply. The last round of echo replys refers to the echo replys that match the echo request in the previous round of the echo request/reply process. In particular, the Upstream Interface TLVs contained in these echo replys indicate that they are the Downstream Mapping information saved by the Initiator node at the time. For the matching, see the process of receiving the echo reply message by the Initiator node below.

The P2P LSP refers to the next hop corresponding to the target FEC (recorded as First Transit FEC) of the target FEC stack from the top to the bottom of the target FEC stack. If there are multiple ECMPs in the next hop, the echo reply There are multiple Downstream Mapping TLVs, and the DS Flags are marked with the E flag. The Initiator needs to save multiple Downstream Mapping information. In particular, when the Responder node finds that the forwarding entry to the First Transit FEC is to enter the outer tunnel, it also needs to determine the next hop along with the PI flag and the PIPE/UNIFORM type entering the outer tunnel, and step 602 above. The processing of the Initiator node is similar. When the C flag is invalid, when the Responder node finds that the forwarding entry to the First Transit FEC is to enter the outer PIPE type tunnel, it refers to the far end before the iterative tunnel iteration. One hop, at this time, the R flag in the DS Flags is set to be valid; if it is to enter the outer UNIFORM type tunnel, it means the next hop after the iterative tunnel iteration, and the R flag in the DS Flags is set to be invalid. . When the C flag is valid, when the Initiator node finds that the forwarding entry to the top-level target FEC enters the outer-layer tunnel, it does not distinguish between PIPE or UNIFORM, which refers to the far-end next hop before the iterative tunnel iteration. The R flag in Flags is set to be valid. If the First Transit FEC does not exist, the echo reply does not need to include the Downstream Mapping TLV.

The P2MP LSP is the Downstream Mapping information corresponding to each multicast member in the multicast forwarding entry of the destination FEC on the Responder node. The echo reply contains multiple Downstream Mapping TLVs, and the DS Flags are marked with the M flag. The Initiator needs to save multiple Downstream Mapping information.

In step S610, the Initiator starts a timer and waits for an echo reply.

FIG. 12 is a flowchart of receiving an echo request message by a transit or egress node according to an embodiment of the present invention, including:

In step S701, the Transit or Egress node receives the echo request.

In step S702, the data plane first obtains an MPLS OAM packet according to the type field of the data link layer header for subsequent processing.

If any of the following conditions are exposed during data plane processing, the mpls echo request message is sent to the control plane:

a) Router Alert option

b) IP TTL expiration

c) MPLS TTL expiration

d) MPLS Router Alert label

e) Destination IP of 127/8 range

In step S703, the data plane determines whether it needs to be sent to the control plane.

Step S704, if the data plane needs to send the echo request message to the control plane.

Control plane processing:

1) Check if the tag value is valid and whether there is a corresponding ILM. Trace route records the corresponding label operation, which is used to fill in the subsequent echo reply.

2) Check whether the next hop information in the Downstream Mapping TLV matches the incoming interface where the packet arrives.

3) Check whether the label stack of the message is consistent with the target FEC stack. The Downstream Mapping TLV contains only the labels corresponding to the FEC in the target FEC stack. Therefore, the label layer corresponding to the FEC in the target FEC stack included in the Downstream Mapping TLV needs to be in the label stack from the bottom to the top. Get the label of the corresponding layer for consistency check with the target FEC stack. When checking, first check the top layer FEC, if the top layer If the FEC indicates that the Egress node is reached, it will continue to check the next layer of FEC (forwarding equivalence class), otherwise the next layer of FEC will not be checked.

In step S705, it is determined whether the above check is successful.

In step S706, the check result is successful.

1) Reply to the Initiator node echo reply, Return Code and Return Subcode set the corresponding successful return code. Includes Upstream Interface TLV, Responder Egress TLV or Responder Transit TLV.

2) When the Responder node is Transit, it can also include Downstream Mapping TLVs in the ehco reply according to the echo request including the Downstream Mapping TLV, and put the E/M/R flag as needed. The P2P LSP refers to the next hop of the First Transit FEC on the Responder node to the target FEC stack. In step 609, the next hop here is determined according to whether the C flag is entered into the PIPE/UNIFORM type of the outer tunnel. That is, when the C flag is invalid, when the Responder node finds that the forwarding entry to the First Transit FEC is to enter the outer PIPE tunnel, it refers to the far-end next hop before the iterative tunnel iteration, at this time in the DS Flags. The R flag is set to be valid; to enter the outer UNIFORM type tunnel, it means the next hop after the iterative tunnel iteration, and the R flag in DS Flags is set to invalid. When the C flag is valid, when the Initiator node finds that the forwarding entry to the top-level target FEC enters the outer-layer tunnel, it does not distinguish between PIPE or UNIFORM, which refers to the far-end next hop before the iterative tunnel iteration. The R flag in Flags is set to be valid. If there are multiple ECMPs in the next hop, the echo reply will contain multiple Downstream Mapping TLVs, and the DS Flags will be marked with E. The P2MP LSP is the Downstream Mapping information corresponding to each multicast member in the multicast forwarding entry of the destination FEC on the Responder node. The echo reply contains multiple Downstream Mapping TLVs, and the DS Flags are marked with the M flag.

In step S707, the result of the check is a failure.

Reply to the Initiator node echo reply, Return Code and Return Subcode set the corresponding failure return code. Contains the Upstream Interface TLV.

Step S708: If the data plane does not need to send the echo request packet to the control plane, check whether the packet is quickly obtained as an MPLS OAM packet.

In step S709, if it is not an MPLS OAM packet, the data plane immediately forwards the packet according to the normal data packet.

In step S710, if it is an MPLS OAM packet, the data plane modifies the content of the packet before sending the packet.

Depending on the hardware implementation cost, choose the level of support for the modification. Generally, the simplest is to modify the field, that is, the size of the message is not changed, only the value of some of the fields is changed, and the more complicated modification is to change the size of the message. In this embodiment, the simple modification may be to modify the Downstream Mapping TLV in the echo request according to the next hop to which the packet is sent. The complicated modification may be to modify the target FEC stack.

In this embodiment, the message can be modified according to the C flag carried in the echo request message.

If the C flag is valid, the target FEC stack TLV is not modified, and only the Downstream Mapping TLV is modified. Specifically, the P2P LSP is changed to the Downstream Mapping information corresponding to the next hop of the forwarding entry corresponding to the First Transit FEC. If the forwarding entry has multiple next hops to form ECMP, only one of them will be forwarded during actual forwarding. The Downstream Mapping TLV is modified based on the next hop in the pick. As the C flag is valid, when the next hop in the selection needs to continue to iterate over the outer layer tunnel, the outer tunnel is uniformly processed according to the PIPE type, that is, the next hop information in the modified Downstream Mapping TLV is the tunnel. The far-end next hop before iteration is actually the original next hop of the forwarding entry corresponding to the First Transit FEC, and the R flag in the DS Flags is set to 1. If it is not necessary to iterate over the outer tunnel, the R flag in DS Flags is set to zero. When the P2MP LSP is changed to the Downstream mapping information corresponding to each multicast member in the multicast forwarding entry corresponding to the target FEC, that is, when each echo request is sent to each multicast member, the echo request is modified in each echo request. The next hop information in the Downstream Mapping TLV is the next hop of the corresponding multicast member.

If the C flag is invalid, both the target FEC stack TLV and the Downstream Mapping TLV are modified. Specifically, in the case of a P2P LSP, if a target FEC stack occurs on the node Change, including FEC POP and PUSH, directly modify the target FEC stack TLV. In addition, the Downstream Mapping TLV is changed to the Downstream Mapping information of the next hop of the forwarding entry corresponding to the First Transit FEC. If the forwarding entry has multiple next hops to form ECMP, only one of them will be forwarded during the actual forwarding. Downstream Mapping The TLV is modified based on the next hop in the pick. The next hop information in the modified Downstream Mapping TLV is the far-end next hop before the tunnel iteration, because the C-flag is invalid, and the next hop in the selection needs to continue to iterate over the outer-layer PIPE tunnel. In fact, the original next hop of the forwarding entry corresponding to the First Transit FEC, the R flag in the DS Flags is set to 1. When the next hop in the selection needs to continue to iterate over the outer UNIFORM tunnel, the next hop information in the modified Downstream Mapping TLV is the next hop after the tunnel iteration, and the R flag in the DS Flags is set. 0. If it is not necessary to iterate over the outer tunnel, the R flag in DS Flags is set to zero. When the P2MP LSP is changed to the Downstream mapping information corresponding to each multicast member in the multicast forwarding entry corresponding to the target FEC, that is, when each echo request is sent to each multicast member, the echo request is modified in each echo request. The next hop information in the Downstream Mapping TLV is the next hop of the corresponding multicast member.

In addition, if the node finds that the R flag in the Downstream Mapping TLV is valid, it needs to compare whether the far-end next hop specified in the Downstream Mapping TLV is itself. Only you need to modify the Downstream according to the above process. Mapping TLV, otherwise it will not be modified.

FIG. 13 is a flowchart of a send reply message sent by a Responder node according to an embodiment of the present invention, including:

Step S801: The Transit or Egress node replies an echo reply as a responder node according to the processing result after the received echo request is sent to the control plane.

Step S802, constructing an Echo reply PDU as follows:

1) Sender's Handle, Sequence Number, TimeStamp Sent is copied from the request message.

2) The TimeStamp Received field is set to the relative time of day, seconds and microseconds.

3) The target FEC Stack TLV can be copied from the request message.

4) Return Code and Subcode must be set according to the processing result of receiving the request.

5) Includes Upstream Interface TLV, Responder Egress TLV or Responder Transit TLV.

6) When the Responder node is Transit, it can also include Downstream Mapping TLVs and mark the E/M/R as needed. In step 706, the next hop of the Downstream Mapping TLVs is determined according to whether the C flag is entered into the PIPE/UNIFORM type of the outer tunnel, and is not described here.

In step S803, IP/UDP is constructed as follows:

1) The source IP is a routable IP address on the Responder side.

2) The destination IP copies the source IP from the request message or from the Reply-to TLV.

3) IP TTL=255

4) Source PORT is 3503

5) Destination PORT copies source PORT from request message

6) Router Alert option: If the request indicates that the reply mode is "Reply via an IPv4 UDP packet with Router Alert", the Router Alert option must be included. If the LSP is returned, the top label is Router Alert label (1).

Step S804, the corresponding data link layer is normally encapsulated and then forwarded.

FIG. 14 is a flowchart of receiving an echo reply message by an Initiator node according to an embodiment of the present invention, including:

In step S901, the Initiator node receives the echo reply message.

In step S902, the Initiator obtains the Sender's Handle and the Sequence Number in the echo reply message, and matches the Sender's Handle and the Sequence Number corresponding to the locally saved echo request.

In step S903, it is checked whether the echo reply matches the echo request.

In step S904, if there is no match, the echo reply is discarded.

In step S905, if it matches, the Upstream Interface TLV in the echo reply message is continuously obtained in the traceroute mode, and the locally saved Downstream Mapping information is matched. Check whether all Downstream mapping information saved locally has a corresponding echo reply. Multiple Downstream Mappings with the E flag only need to match one of them; all those with the M flag need to match. When the mode is ping, no match is made, and the match is always considered successful.

Step S906, waiting for the timer for waiting to receive the echo reply to time out.

Step S907, after the timer expires, it is checked whether it is the ping mode.

Step S908, if it is the ping mode, the entire detection process ends, and the detection result is reported, such as which nodes replied to the echo reply, whether the desired reply node has replied, and the like. The Initiator can turn on the next round of duplicate detection as needed.

In step S909, if it is in the traceroute mode, it continues to check whether the locally saved Downstream Mapping information is all matched, or only partially matched but meets the matching pass policy, for example, the matched Downstream Mapping ratio exceeds a certain threshold. On a P2P LSP, multiple Downstream Mapping entries marked with the E flag may be saved locally. If one of these entries matches the echo reply, they are considered to be matched. When a P2MP LSP is used, multiple Downstream Mapping entries marked with the M flag may be saved locally. These entries need to be matched separately and with different echo responses.

If the locally saved Downstream Mapping match fails, the entire detection process ends and the detection result is reported.

In step S910, if the locally saved Downstream Mapping matches, the node that wants to reply to the echo reply continues to check whether the echo reply is replied.

If the desired node replies with an echo reply, the entire detection process ends and the test results are reported.

Step S911, if some of the desired nodes do not reply to the echo reply, continue to check whether all the echo reply contains any Downstream Mapping TLV.

If all the echo reply does not contain any Downstream Mapping TLV, the entire detection process ends and the detection result is reported.

Step S912: Delete all the Downstream mapping information that is saved locally, and obtain new Downstream Mapping information from all the echo replys, and save locally for matching with the next round of echo reply. Send the next round of echo request, label TTL increased by 1. Sender's Handle is unchanged and the Sequence Number is incremented by 1. Other processes in which the Initiator node sends an echo request message.

The following describes the MPLS LSP detection method in this embodiment, including:

Example 1

This embodiment will describe the detection flow of the P2P LSP. FIG. 15 is a network topology diagram according to the first embodiment of the present invention. As shown in FIG. 15, A is established as an ingress node to an LDP LSP whose egress node is H, and on the transit node B. The LDP LSP has ECMP. One of the next hops is the remote next hop D and the LDP over TE is formed. The path from the tunnel head node to the tunnel destination node is BCD, and the next hop of the LDP LSP on the B node. Is E.

At this time, the LSP traceroute LDP FEC H is initiated at the node A, and the parameter Constant is set to be valid. The detection process includes the following steps. For the sake of brevity, only the main processes related to this patent are described:

Step S1001

The first round of echo request message is constructed on the A node, and the Echo request PDU is set:

Global Flags: C=1

Target FEC stack TLV: {LDP FEC H}

Downstream Mapping TLV: {DS Flags: I=1, E/M/R=0; Downstream Address=B&B.port1}. B indicates the router-id, and port1 indicates the IP address of the interface.

Encapsulate the IP/UDP header and the label stack. The top label LDP Label TTL=1.

Set the data link layer type field (such as ethernet type=0x88DF) to indicate that it is an MPLS OAM packet.

The Downstream Mapping entry is saved locally on node A: {DS Flags: E/M=0; Downstream Address=B&B.port1}

Step S1002

The node B receives the echo request packet and sends it to the control plane because the label TTL=1 on the top label of the label stack. On the control plane, check that the label value is valid, the corresponding ILM exists, and the label operation is SWAP. Check that the next hop information in the Donstream Mapping TLV matches the incoming interface of the packet; check the label of the packet. The stack is consistent with the target FEC stack.

Node B replies with an echo reply message, including:

Upstream Interface TLV: {B&B.port1}

Responder Transit TLV: {B}

Downstream Mapping TLV1: {DS Flags: I=1, E=1, R=1; Downstream Address=D&D}. Here, because the C flag is valid, the Downstream Mapping TLV is filled in according to the next hop before the tunnel iteration.

Downstream Mapping TLV2: {DS Flags: I=1, E=1, R=0; Downstream Address=E&E.port1}.

Step S1003

The A node receives the ehco reply of the Node B, checks that it matches the current echo request, and the Upstream Interface TLV in the echo reply: {B&B.port1} and the locally saved Downstream Mapping entry: {DS Flags: E/M= 0; Downstream Address=B&B.port1} is a match.

Node A obtains the new Downstream Address information from the echo reply and saves it locally as:

Downstream Mapping entry 1: {DS Flags: E=1, R=1; Downstream Address=D&D}

Downstream Mapping entry 2: {DS Flags: E=1, R=0; Downstream Address=E&E.port1}

A initiates the next round of echo request, similar to step S1001, except that the top label LDP Label TTL=2. In particular, the included Downstream Mapping TLV is the same as in step S1001.

Step S1004

The B-node receives the echo request packet because the label TTL=2 on the top of the label stack and the transit node of the LDP LSP does not cause the control plane to be sent.

The B node quickly determines that the MPLS OAM packet is based on the type field of the data link layer, and the C flag in the echo request is 1 and the next hop in the Downstream Mapping TLV before the modification in the echo request is B. The text is actually sent to the remote next hop D through LDP over TE, and the Downstream Mapping TLV of the packet is modified to be: {DS Flags: I=1, E=1, R=1; Downstream Address=D&D}. Then the LDP Label TTL is decremented by 1, and the TE Label TTL is set to 255. The data link layer type field is set to indicate that it is an MPLS OAM packet. Forward the message.

Step S1005

The C-node receives the echo request packet because the label TTL=255 on the top of the label stack and the transit node of the TE LSP does not cause the control plane to be sent.

The C node quickly determines that it is an MPLS OAM packet according to the type field of the data link layer. However, if the next hop of the Downstream Mapping TLV before the modification in the echo request is not C, and the R flag is valid, C knows that it is somewhere else. In the layer tunnel, there is no modification to the Downstream Mapping TLV. Only the TE Label TTL is decremented by 1. The data link layer type field is set to indicate that it is an MPLS OAM packet. Forward the message.

Step S1006

The D-node receives the echo request packet, and the TE label is ejected or terminated in advance, so that the label LDP Label TTL=1 on the top label of the label stack is sent to the control plane. On the control plane, the check indicates that the tag value is valid, the corresponding ILM exists, and the tag operation is SWAP. The next hop information in the Donstream Mapping TLV is found to match the incoming interface of the packet. Check that the label stack of the packet is consistent with the target FEC stack.

The D node replies with an echo reply message, including:

Upstream Interface TLV: {D&D.port1}

Responder Transit TLV: {D}

Downstream Mapping TLV1: {DS Flags: I=1, E=0, R=0; Downstream Address=H&H.port1}

Step S1007

Node A receives the ehco reply of the D node, checks that it matches the current echo request, and the Upstream Interface TLV in the echo reply: {D&D.port1} and the locally saved Downstream Mapping entry 1: {DS Flags: E=1 , R=1; Downstream Address=D&D} is a match. Here, because the R flag is valid, it only matches the Router-id. Because the E flag of Downstream Mapping entry 2 is valid, it is considered to have passed the match.

Node A obtains the new Downstream Address information from the echo reply and saves it locally as:

Downstream Mapping entry: {DS Flags: E=0, R=0; Downstream Address=H&H.port1}

A initiates the next round of echo request, similar to step S1001, except that the top label LDP Label TTL=3. In particular, the included Downstream Mapping TLV is the same as in step S1001.

Step S1008

The B-node receives the echo request packet. The TTL of the label stack is TTL=3, and the transit node of the LDP LSP does not cause the control plane to be sent.

In the similar step S1004, the Downstream Mapping TLV of the packet is modified and then forwarded.

Step S1009

The C-node receives the echo request packet because the label TTL=255 on the top of the label stack and the transit node of the TE LSP does not cause the control plane to be sent.

In other steps, S1005, the Downstream Mapping TLV of the packet is not modified and forwarded.

Step S1010

The D-node receives the echo request packet because the label TTL=2 on the top of the label stack and the transit node of the LDP LSP does not cause the control plane to be sent.

The D node quickly determines that the MPLS OAM packet is based on the type field of the data link layer, and the C flag according to the echo request is 1, and the next hop in the Downstream Mapping TLV before the modification in the echo request is D, and the R flag. If the packet is valid, the packet is sent to the next hop H, and the Downstream Mapping TLV of the packet is modified to be: {DS Flags: I=1, E/M/R=0; Downstream Address=H&H.port1}. Then the LDP Label TTL is decremented by 1, and the data link layer type field is set to indicate that it is an MPLS OAM packet. Forward the message.

Step S1011

The H-node receives the echo request packet, and the label LDP Label TTL=1 on the top label of the label stack is sent to the control plane. On the control plane, check that the label value is valid, the corresponding ILM exists, and the label operation is POP. Check that the next hop information in the Donstream Mapping TLV matches the incoming interface of the packet; check the label of the packet. The stack is consistent with the target FEC stack.

The H node replies with an echo reply message, including:

Upstream Interface TLV: {H&H.port1}

Responder Egress TLV: {H}

Step S1012

The A node receives the ehco reply of the H node, checks that it matches the current echo request, and the Upstream Interface TLV in the echo reply: {H&H.port1} and the locally saved Downstream Mapping entry: {DS Flags: E/M= 0; Downstream Address=H&H.port1} is a match.

Node A cannot obtain new Downstream Address information from the echo reply. Detection After the test result is output, the echo reply of the Egress node H is received.

Example 2

16 is a network topology diagram according to Example 2 of the present invention. This embodiment is basically the same as Example 1. The difference is that the parameter Constant is invalid when the A node initiates the LSP traceroute LDP FEC H. The detection process includes the following steps:

Step S1101

The first round of echo request message is constructed on the A node, and the Echo request PDU is set:

Global Flags: C=1

Target FEC stack TLV: {LDP FEC H}

Downstream Mapping TLV: {DS Flags: I=1, E/M/R=0; Downstream Address=B&B.port1}. B indicates the router-id, and port1 indicates the IP address of the interface.

Encapsulate the IP/UDP header and the label stack. The top label LDP Label TTL=1.

Set the data link layer type field (such as ethernet type=0x88DF) to indicate that it is an MPLS OAM packet.

The Downstream Mapping entry is saved locally on node A: {DS Flags: E/M=0; Downstream Address=B&B.port1}

Step S1102

The node B receives the echo request packet and sends it to the control plane because the label LDP Label TTL=1 on the top label of the label stack. On the control plane, check that the label value is valid, the corresponding ILM exists, and the label operation is SWAP. Check that the next hop information in the Donstream Mapping TLV matches the incoming interface of the packet; check the label of the packet. The stack is consistent with the target FEC stack.

Node B replies with an echo reply message, including:

Upstream Interface TLV: {B&B.port1}

Responder Transit TLV: {B}

Downstream Mapping TLV1: {DS Flags: I=1, E=1, R=0; Downstream Address=C&C.port1}. Here, because the C flag is invalid, the Downstream Mapping TLV is filled in according to the next hop after the tunnel iteration.

Downstream Mapping TLV2: {DS Flags: I=1, E=1, R=0; Downstream Address=E&E.port1}

Step S1103

The A node receives the ehco reply of the Node B, checks that it matches the current echo request, and the Upstream Interface TLV in the echo reply: {B&B.port1} and the locally saved Downstream Mapping entry: {DS Flags: E/M= 0; Downstream Address=B&B.port1} is a match.

Node A obtains the new Downstream Address information from the echo reply and saves it locally as:

Downstream Mapping entry 1: {DS Flags: E=1, R=0; Downstream Address=C&C.port1}

Downstream Mapping entry 2: {DS Flags: E=1, R=0; Downstream Address=E&E.port1}

A initiates the next round of echo request, similar to step S1101, except that the top label LDP Label TTL=2. In particular, the included Downstream Mapping TLV is the same as in step S1101.

Step S1104

The B-node receives the echo request packet because the LDP Label TTL of the label on the top of the label stack is 2, and the transit node of the LDP LSP does not cause the control plane to be sent.

The B node quickly determines that the MPLS OAM packet is based on the type field of the data link layer, and the C flag in the echo request is 0, and the next hop in the Downstream Mapping TLV before the modification in the echo request is B. The actual LDP over TE is sent to the remote next hop D. The next hop of the tunnel is the Downstream of the packet. The Mapping TLV is modified to: {DS Flags: I=1, E=1, R=0; Downstream Address=C&C.port1}. And modify the target FEC stack TLV to: {LDP FEC H, TE FEC D}. Then, the LDP Label TTL is decremented by 1, and the TE Label TTL is copied from the LDP Label TTL. The data link layer type field is set to indicate that it is an MPLS OAM packet. Forward the message.

Step S1105

The C-node receives the echo request packet and sends it to the control plane because the top label of the label stack, TE Label TTL=1. On the control plane, check that the label value is valid, the corresponding ILM exists, and the label operation is SWAP. Check that the next hop information in the Donstream Mapping TLV matches the incoming interface of the packet; check the label of the packet. The stack is consistent with the target FEC stack.

The C node replies with an echo reply message, including:

Upstream Interface TLV: {C&C.port1}

Responder Transit TLV: {C}

Downstream Mapping TLV1: {DS Flags: I=1, E=0, R=0; Downstream Address=D&D.port1}.

Step S1106

The A node receives the ehco reply of the C node, checks that it matches the current echo request, and the Upstream Interface TLV in the echo reply: {C&C.port1} and the locally saved Downstream Mapping entry 1: {DS Flags: E=1 , R=0; Downstream Address=C&C.port1} is matched. Since the Downstream Mapping entry 2: {DS Flags: E=1, R=0; the E flag in Downstream Address=E&E.port1} is valid, then it also Think it is a match.

Node A obtains the new Downstream Address information from the echo reply and saves it locally as:

Downstream Mapping entry 1: {DS Flags: E=0, R=0; Downstream Address=D&D.port1}

A initiates the next round of echo request, similar to step S1101, except that the top label LDP Label TTL=3. In particular, the included Downstream Mapping TLV is the same as in step S1101.

Step S1107

The node B receives the echo request packet. The label LDP Label TTL=3 on the top of the label stack is used as the transit node of the LDP LSP.

In the similar step S1104, the target FEC stack TLV and the Downstream Mapping TLV of the packet are modified and then forwarded.

Step S1108

The C-node receives the echo request packet, because the top label of the label stack, TE Label TTL=2, and the transit node of the TE LSP does not cause the control plane to be sent.

The C node quickly determines that the MPLS OAM packet is based on the type field of the data link layer, and then the C flag in the echo request is 0, and the next hop in the Downstream Mapping TLV before the modification in the echo request is C. The Downstream Mapping TLV of the text is modified as follows: {DS Flags: I=1, E=0, R=0; Downstream Address=D&D.port1}. Then the TE Label TTL is decremented by 1, and the data link layer type field is set to indicate that it is an MPLS OAM packet. Forward the message.

Step S1109

The D-node receives the echo request packet, and the TE label is ejected or terminated in advance. The TE Label TTL is inherited to the LDP Label TTL. The LDP Label TTL=1 is sent to the control plane. On the control plane, check that the label value is valid, the corresponding ILM exists, and the label operation is SWAP. Check that the next hop information in the Donstream Mapping TLV matches the incoming interface of the packet; check the label of the packet. The stack is consistent with the target FEC stack.

The D node replies with an echo reply message, including:

Upstream Interface TLV: {D&D.port1}

Responder Transit TLV: {D}

Downstream Mapping TLV1: {DS Flags: I=1, E=0, R=0; Downstream Address=H&H.port1}

Step S1110

Node A receives the ehco reply from the D node, checks that it matches the current echo request, and the Upstream Interface TLV in the echo reply: {D&D.port1} and the locally saved Downstream Mapping entry: {DS Flags: E/M= 0; Downstream Address=D&D.port1} is a match.

Node A obtains the new Downstream Address information from the echo reply and saves it locally as:

Downstream Mapping entry 1: {DS Flags: E=0, R=0; Downstream Address=H&H.port1}

A initiates the next round of echo request, similar to step S1101, except that the top label LDP Label TTL=4. In particular, the included Downstream Mapping TLV is the same as in step S1101.

Step S1111

The B-node receives the echo request packet. The LDP Label TTL of the label on the top of the label stack is 4, and the transit node of the LDP LSP does not cause the control plane to be sent.

In the similar step S1104, the target FEC stack TLV and the Downstream Mapping TLV of the packet are modified and then forwarded.

Step S1112

The C-node receives the echo request packet because the top label of the label stack, TE Label TTL=3, and the transit node of the TE LSP does not cause the control plane to be sent.

In other similar steps, S1108, the Downstream Mapping TLV of the packet is modified. If the penultimate hop popup occurs, you need to modify the target FEC stack TLV of the packet to be {LDP FEC H}, otherwise it will not be modified.

Step S1113

The D-node receives the echo request packet, and the TE label is ejected or terminated in advance. The TE Label TTL is inherited to the LDP Label TTL. The LDP Label TTL=2 is not sent to the control plane.

The D node quickly determines that the MPLS OAM packet is based on the type field of the data link layer, and then the C flag in the echo request is 0, and the next hop in the Downstream Mapping TLV before the modification in the echo request is D. The Downstream Mapping TLV of the text is modified as follows: {DS Flags: I=1, E=0, R=0; Downstream Address=H&H.port1}. If no penultimate hop popup occurs on the previous C node, then the target node FEC POP is also required according to the TE Label POP on the D node, that is, the target FEC stack TLV is modified: {LDP FEC H}. Then the LDP Label TTL is decremented by 1, and the data link layer type field is set to indicate that it is an MPLS OAM packet. Forward the message.

Step S1114

The H-node receives the echo request packet, and the label LDP Label TTL=1 on the top label of the label stack is sent to the control plane. On the control plane, check that the label value is valid, the corresponding ILM exists, and the label operation is POP. Check that the next hop information in the Donstream Mapping TLV matches the incoming interface of the packet; check the label of the packet. The stack is consistent with the target FEC stack.

The H node replies with an echo reply message, including:

Upstream Interface TLV: {H&H.port1}

Responder Egress TLV: {H}

Step S1115

The A node receives the ehco reply of the H node, checks that it matches the current echo request, and the Upstream Interface TLV in the echo reply: {H&H.port1} and the locally saved Downstream Mapping entry: {DS Flags: E/M= 0; Downstream Address=H&H.port1} is a match.

Node A cannot obtain new Downstream Address information from the echo reply. After the detection is completed, the detection result is output, and the echo reply of the Egress node H is received.

Example 3

This embodiment will describe the detection flow of the P2MP LSP. FIG. 17 is a network topology diagram of the example 3 according to the present invention. As shown in FIG. 17, the multicast distribution tree with the R node as the root node establishes an mLDP LSP whose FEC is opaqueX.

At this point, the LSP traceroute mLDP FEC opaqueX is initiated at the R node. The detection process includes the following steps. For the sake of brevity, only the main processes related to this patent are described:

Step S1201

The first round of echo request packets is constructed on the R node, and the echo request is sent to the multicast member next hop A and the multicast member next hop B respectively.

Set the Echo request PDU sent to the multicast member next hop A:

Target FEC stack TLV: {mLDP FEC opaqueX}

Downstream Mapping TLV: {DS Flags: I=1, E/R=0, M=1; Downstream Address=A&A.port1}. A indicates the router-id, and port1 indicates the IP address of the interface.

Encapsulate the IP/UDP header and the label stack. The top label LDP Label TTL=1.

Set the data link layer type field (such as ethernet type=0x88DF) to indicate that it is an MPLS OAM packet.

A similar setting to the Echo request PDU sent by the multicast member to the next hop B:

Target FEC stack TLV: {mLDP FEC opaqueX}

Downstream Mapping TLV: {DS Flags: I=1, E/R=0, M=1; Downstream Address=B&B.port1}.

Encapsulate the IP/UDP header and the label stack. The top label LDP Label TTL=1.

Set the data link layer type field (such as ethernet type=0x88DF) to indicate that it is an MPLS OAM packet.

The Downstream Mapping entry 1 is saved locally on the R node: {DS Flags: E/R=0, M=1; Downstream Address=A&A.port1}, Downstream Mapping Entry 2: {DS Flags: E/R=0, M=1; Downstream Address=B&B.port1}

Step S1202

The node A receives the echo request packet and sends it to the control plane because the label TTL=1 on the top label of the label stack. On the control plane, check that the label value is valid, the corresponding ILM exists, and the label operation is SWAP. Check that the next hop information in the Donstream Mapping TLV matches the incoming interface of the packet; check the label of the packet. The stack is consistent with the target FEC stack.

The A node replies with an echo reply message, including:

Upstream Interface TLV: {A&A.port1}

Responder Transit TLV: {A}

Downstream Mapping TLV1: {DS Flags: I=1, E/R=0, M=1; Downstream Address=C&C.port1}.

Downstream Mapping TLV2: {DS Flags: I=1, E/R=0, M=1; Downstream Address=D&D.port1}.

Similarly, the Node B receives the echo request packet and replies to the echo reply packet, including:

Upstream Interface TLV: {B&B.port1}

Responder Transit TLV: {B}

Downstream Mapping TLV1: {DS Flags: I=1, E/R=0,, M=1; Downstream Address=E&E.port1}.

Downstream Mapping TLV2: {DS Flags: I=1, E/R=0,, M=1; Downstream Address=F&F.port1}.

Step S1203

The R node receives the ehco reply of the A node, checks that it matches the current echo request, and the Upstream Interface TLV in the echo reply: {A&A.port1} and the locally saved Downstream Mapping entry 1: {DS Flags: E/R =0, M=1; Downstream Address=A&A.port1} is a match.

Similarly, the R node receives the echo reply of the Node B, and the Upstream Interface TLV in the echo reply: {B&B.port1} and the locally saved Downstream Mapping entry 2: {DS Flags: E/R=0, M=1; Downstream Address=B&B.port1} is a match.

The R node obtains the new Downstream Address information from the echo reply of A and saves it locally as:

Downstream Mapping entry 1: {DS Flags: E/R=0, M=1; Downstream Address=C&C.port1}

Downstream Mapping entry 2: {DS Flags: E/R=0, M=1; Downstream Address=D&D.port1}

The R node obtains the new Downstream Address information from the echo reply of B and saves it locally as:

Downstream Mapping entry 3: {DS Flags: E/R=0, M=1; Downstream Address=E&E.port1}

Downstream Mapping entry 4: {DS Flags: E/R=0, M=1; Downstream Address=F&F.port1}

R initiates the next round of echo request, similar to step S1201, except that the top label LDP Label TTL=2. In particular, the included Downstream Mapping TLV is the same as in step S1201.

Step S1204

The node A received the echo request packet because the label LDP Label TTL=2 of the label stack and the transit node of the mLDP LSP did not cause the control plane to be sent.

The A node quickly determines that the MPLS OAM packet is based on the type field of the data link layer. If the next hop in the Downstream Mapping TLV before the modification is A, the node sends an echo to the multicast member next hop C. The Downstream Mapping TLV of the request packet is modified as follows: {DS Flags: I=1, E/R=0, M=1; Downstream Address=C&C.port1}. Downstream of the echo request message to be sent to the multicast member next hop D The Mapping TLV is modified to: {DS Flags: I=1, E/R=0, M=1; Downstream Address=D&D.port1}. Then the LDP Label TTL is decremented by 1, and the data link layer type field is set to indicate that it is an MPLS OAM packet. Forward the message.

Similarly, the Node B changes the Downstream Mapping TLV of the echo request packet sent to the next hop of the multicast member to: {DS Flags: I=1, E/R=0, M=1; Downstream Address=E&E. Port1}. The Downstream Mapping TLV of the echo request packet sent to the next hop of the multicast member is modified as follows: {DS Flags: I=1, E/R=0, M=1; Downstream Address=F&F.port1}. Then the LDP Label TTL is decremented by 1, and the data link layer type field is set to indicate that it is an MPLS OAM packet. Forward the message.

Step S1205

The C-node receives the echo request packet and sends it to the control plane because the label TTL=1 on the top label of the label stack. On the control plane, check that the label value is valid, the corresponding ILM exists, and the label operation is SWAP. Check that the next hop information in the Donstream Mapping TLV matches the incoming interface of the packet; check the label of the packet. The stack is consistent with the target FEC stack.

The C node replies with an echo reply message, including:

Upstream Interface TLV: {C&C.port1}

Responder Transit TLV: {C}

Downstream Mapping TLV1: {DS Flags: I=1, E/R=0, M=1; Downstream Address=G&G.port1}.

Downstream Mapping TLV2: {DS Flags: I=1, E/R=0, M=1; Downstream Address=H&H.port1}.

Similarly, the D node receives the echo request packet and replies to the echo reply packet, including:

Upstream Interface TLV: {D&D.port1}

Responder Egress TLV: {D}

Similarly, the E-node receives the echo request packet and replies to the echo reply packet, including:

Upstream Interface TLV: {E&E.port1}

Responder Egress TLV: {E}

Similarly, the F node receives the echo request packet and replies to the echo reply packet, including:

Upstream Interface TLV: {F&F.port1}

Responder Transit TLV:{F}

Downstream Mapping TLV1: {DS Flags: I=1, E/R=0, M=1; Downstream Address=I&I.port1}.

Downstream Mapping TLV2: {DS Flags: I=1, E/R=0, M=1; Downstream Address=J&J.port1}.

Step S1206

The R node receives the ehco reply of the C node, checks that it matches the current echo request, and the Upstream Interface TLV in the echo reply: {C&C.port1} and the locally saved Downstream Mapping entry 1: {DS Flags: E/R =0, M=1; Downstream Address=C&C.port1} is a match.

Similarly, the R node receives the echo reply of the D node, and the Upstream Interface TLV in the echo reply: {D&D.port1} and the locally saved Downstream Mapping entry 2: {DS Flags: E/R=0, M=1; Downstream Address=D&D.port1} is a match.

Similarly, the R node receives the echo reply of the E node, and the Upstream Interface TLV in the echo reply: {E&E.port1} and the locally saved Downstream Mapping entry 3: {DS Flags: E/R=0, M=1; Downstream Address=E&E.port1} is a match.

Similarly, the R node receives the echo reply of the F node, and the Upstream Interface TLV in the echo reply: {F&F.port1} and the locally saved Downstream Mapping entry 4: {DS Flags: E/R=0, M=1; Downstream Address=F&F.port1} is a match.

The R node obtains the new Downstream Address information from the echo reply of C and saves it locally as:

Downstream Mapping entry 1: {DS Flags: E/R=0, M=1; Downstream Address=G&G.port1}

Downstream Mapping entry 2: {DS Flags: E/R=0, M=1; Downstream Address=H&H.port1}

The R node obtains the new Downstream Address information from the echo reply of F and saves it locally as:

Downstream Mapping entry 3: {DS Flags: E/R=0, M=1; Downstream Address=I&I.port1}

Downstream Mapping entry 4: {DS Flags: E/R=0, M=1; Downstream Address=J&J.port1}

R initiates the next round of echo request, similar to step S1201, except that the top label LDP Label TTL=3. In particular, the included Downstream Mapping TLV is the same as in step S1201.

Step S1207

Similar to step S1204, the A and B nodes respectively modify the Downstream Mapping TLV in the echo request packet sent to the next hop of the specific multicast member, and then forward the packet.

Step S1208

Similar to step S1204, the C and F nodes respectively modify the Downstream Mapping TLV in the echo request message sent to the next hop of the specific multicast member, and then forward the packet.

D, the E node will reply the echo reply to the R node again, but the R node will not match its locally saved Downstream Mapping entry, and these echo reply will be discarded.

Step S1209

Similar to step S1205, the G node replies with an echo reply message, including:

Upstream Interface TLV: {G&G.port1}

Responder Egress TLV: {G}

Similarly, the H node receives the echo request message and replies to the echo reply message, including:

Upstream Interface TLV: {H&H.port1}

Responder Egress TLV: {H}

Similarly, the I node receives the echo request packet and replies to the echo reply packet, including:

Upstream Interface TLV: {I&I.port1}

Responder Egress TLV: {I}

Similarly, the J node receives the echo request message and replies to the echo reply message, including:

Upstream Interface TLV: {J&J.port1}

Responder Egress TLV: {J}

Step S1210

Similar to step S1203, the R node receives the echo reply from G, H, I, and J, respectively, and matches the locally saved Downstream Mapping entries 1 to 4.

The R node cannot obtain new Downstream Address information from the echo reply. After the detection is completed, the detection result is output, and the echo reply of the Egress node D, E, G, H, I, J is received.

Example 4

Embodiments of the present invention also provide a storage medium. Optionally, in the embodiment, the foregoing storage medium may be configured to store program code for performing the following steps:

S1, the detecting initiator sends an echo request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message;

S2: The receiving transmission node or the egress node responds to the response message according to the MPLS OAM packet, and detects whether the response response message matches the pre-stored information.

Optionally, in this embodiment, the foregoing storage medium may include, but not limited to, a USB flash drive, a Read-Only Memory (ROM), a Random Access Memory (RAM), a mobile hard disk, and a magnetic memory. A variety of media that can store program code, such as a disc or a disc.

Optionally, in this embodiment, the processor executes according to the stored program code in the storage medium. The line detection initiator sends a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message;

Optionally, in this embodiment, the processor performs, according to the stored program code in the storage medium, the response response message that is received by the transmitting node or the egress node according to the MPLS OAM packet, and detects whether the response response message and the pre-stored information are match.

For example, the specific examples in this embodiment may refer to the examples described in the foregoing embodiments and the optional embodiments, and details are not described herein again.

It will be apparent to those skilled in the art that the various modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein. The steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated as a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software.

The above description is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Industrial applicability

As described above, the method, device, and system for detecting and processing a multi-protocol exchange label provided by the embodiment have the following beneficial effects: the MPLS operation and maintenance management for identifying the multi-protocol exchange label is carried in the response request message. The type field of the OAM packet is such that the forwarding plane of the transmitting node modifies the packet according to the actual forwarding information and the corresponding set of detection processing flow. Therefore, the LSP detection distortion and the P2MP LSP detection inefficient and insufficient in the related art can be solved. problem.

Claims (16)

A method for detecting a multi-protocol exchange tag includes: The detecting initiator sends a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message; The receiving transmission node or the egress node responds to the response message sent by the MPLS OAM packet, and detects whether the response response message matches the pre-stored information. The method of claim 1, wherein the response request message further comprises: downstream mapping information, wherein the downstream mapping information corresponds to one or more next hop routes of the response request message. The method of claim 2, wherein detecting that the initiator sends the response request message further comprises: The detecting initiator determines whether the response request message is an initial response request message sent by the initial node; When the determination result is yes, the detecting initiator locally saves the downstream mapping information in the response request message locally at the initial node when sending the response request message. The method according to claim 3, wherein, in the case that the determination result is negative, the detecting initiator locally saves the downstream mapping carried in the last round of response response packets at the initial node when transmitting the response request message. information. The method of claim 1 wherein said type field is encapsulated in a data link layer header of said echo request message. The method according to claim 4, wherein detecting whether the response response message matches the pre-stored information comprises: Detecting whether the sender handle Sender's Handle in the response response message matches the first corresponding field in the response request message, and detecting the sequence number in the response response message and the response request message Whether the second corresponding field matches; When the Sender's Handle matches the first corresponding field, and the sequence number matches the second corresponding field, determining that the upstream interface information in the response response message is locally saved downstream of the initial node Whether the mapping information matches, and when the upstream interface information in the response response message matches the downstream mapping information saved locally by the initial node, determining that the response response message matches the pre-stored information. The method of claim 6, wherein when the plurality of downstream mapping information is saved locally, determining whether the upstream interface information in the response response message matches the downstream mapping information comprises: Determining whether the plurality of downstream mapping information saved locally has the corresponding response response message matching; And determining whether a matching success rate of the plurality of the downstream mapping information that is saved locally and the plurality of the response response messages is greater than a preset threshold. The method of claim 1, wherein after detecting whether the response response message matches the pre-stored information, the method further comprises: And determining, according to the detection result that the response response message matches the pre-stored information, whether to send the next response request message. The method according to claim 8, wherein determining whether to send the next response request message according to the detection result of whether the response response message matches the pre-stored information comprises: Detecting a transmission mode of the response request message; When the transmission mode is the Internet packet explorer ping mode, the next response request message is discarded; and/or, when the transmission mode is the traceroute mode, whether the locally saved downstream mapping information satisfies the match. The policy determines whether to send the next response request message. A method for processing a response request message, including: Receiving a response request message, where the response request message includes multiple identifiers for identifying Protocol exchange label MPLS operation and maintenance management type field of OAM packet; Identifying, by the type field, the MPLS OAM packet; Forwarding the response request message according to the preset forwarding entry. The method according to claim 10, wherein the forwarding request message is forwarded by the forwarding plane according to the preset forwarding entry, including one of the following: Forwarding, by the forwarding plane, the response request message to the control plane according to the first preset forwarding entry, and feeding back the response response message of the response request message; The forwarding plane modifies the content of the MPLS OAM packet, and forwards the response request packet to the next hop node of the data plane according to the second preset forwarding entry. The method of claim 11, wherein the modifying the content of the MPLS OAM message by the forwarding plane comprises: modifying the downstream mapping information in the response request message. A multi-protocol exchange label detecting device includes: a sending module, configured to send a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message; The detecting module is configured to receive the response response message fed back by the transmitting node or the egress node according to the MPLS OAM packet, and detect whether the response response message matches the pre-stored information. The apparatus according to claim 13, wherein the response request message further comprises: downstream mapping information, wherein the downstream mapping information corresponds to one or more next hop routes of the response request message. A processing device for responding to a request message, comprising: The receiving module is configured to receive a response request message, where the response request message includes an OAM message for identifying a multi-protocol switching label MPLS operation and maintenance management Type field An identification module, configured to identify the MPLS OAM packet by using the type field; The forwarding module is configured to forward the response request message according to the preset forwarding entry. A multi-protocol switching tag detection system, including an initial node, a transit node or an egress node, The initial node further includes: a sending module, configured to send a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message; The detecting module is configured to receive a response response message fed back by the transmitting node or the egress node according to the MPLS OAM packet, and detect whether the response response message matches the pre-stored information; The transit node or egress node also includes: The receiving module is configured to receive a response request message, where the response request message includes a type field for identifying a multi-protocol switching label MPLS operation and maintenance management OAM message; An identification module, configured to identify the MPLS OAM packet by using the type field; The forwarding module is configured to forward the response request message to the control plane according to the preset forwarding entry, and feed back the response response message of the response request message.

Images