WO2018010560A1 - Procédé, appareil, et système de détection et de traitement de commutation multiprotocole avec étiquette - Google Patents

Procédé, appareil, et système de détection et de traitement de commutation multiprotocole avec étiquette Download PDF

Info

Publication number
WO2018010560A1
WO2018010560A1 PCT/CN2017/091477 CN2017091477W WO2018010560A1 WO 2018010560 A1 WO2018010560 A1 WO 2018010560A1 CN 2017091477 W CN2017091477 W CN 2017091477W WO 2018010560 A1 WO2018010560 A1 WO 2018010560A1
Authority
WO
WIPO (PCT)
Prior art keywords
response
request message
node
message
downstream
Prior art date
Application number
PCT/CN2017/091477
Other languages
English (en)
Chinese (zh)
Inventor
彭少富
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2018010560A1 publication Critical patent/WO2018010560A1/fr

Links

Images

Definitions

  • 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.
  • P2P peer to peer
  • P2MP peer to multiple peer
  • MPLS Multi-protocol Label Switching
  • 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).
  • TTL Time To Live
  • Rfc4379 Label Switching Path (LSP) ping/trace
  • MPLS BFD MPLS BFD
  • IPv4 Label Switching Path
  • IPv6 IPv6
  • 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.
  • the data plane also needs to be perceived in advance in a quick way to be MPLS.
  • 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:
  • the P2MP LSP ping/trace standard in the related art has the following problems of detecting inefficiency and insufficiency:
  • 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.
  • the received echo reply may burst and cause congestion.
  • 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.
  • 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.
  • a method for detecting a multi-protocol switching label 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.
  • 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.
  • 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.
  • the detecting initiator locally saves the downstream mapping information carried in the last round of the response response message in the initial node.
  • the type field is encapsulated in a data link layer header of the response request message.
  • 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
  • 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.
  • the downstream mapping information matches, it is determined that 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.
  • 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.
  • ping Packet Internet Groper
  • a method for processing a multi-protocol exchange label 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 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.
  • modifying, by the forwarding plane, the content of the MPLS OAM packet includes: modifying downlink mapping information in the response request packet.
  • a device for detecting a multi-protocol exchange label 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. .
  • 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.
  • a processing apparatus for a multi-protocol exchange label 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.
  • a detection system for a multi-protocol switching label 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.
  • 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.
  • 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.
  • a storage medium is also provided.
  • the storage medium is arranged to store program code for performing the following steps:
  • 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 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.
  • FIG. 1 is a flowchart of a method for detecting a multi-protocol exchange tag according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a method for processing a multi-protocol exchange tag according to an embodiment of the present invention
  • FIG. 3 is a structural block diagram of a multi-protocol exchange tag detecting apparatus according to an embodiment of the present invention.
  • FIG. 4 is a structural block diagram of a processing apparatus for a multi-protocol exchange tag according to an embodiment of the present invention
  • FIG. 5 is a structural block diagram of a detection system for a multi-protocol exchange tag according to an embodiment of the present invention
  • FIG. 6 is a format diagram of an LSP ping echo request/reply message according to an embodiment of the present invention.
  • FIG. 7 is a format diagram of a Downstream Mapping TLV according to an embodiment of the present invention.
  • FIG. 8 is a format diagram of an Upstream Interface TLV according to an embodiment of the present invention.
  • FIG. 9 is a format diagram of a Responder Egress TLV according to an embodiment of the present invention.
  • FIG. 10 is a format diagram of a Responder Transit TLV according to an embodiment of the present invention.
  • FIG. 11 is a flowchart of an Initiator node sending an echo request message according to an embodiment of the present invention
  • FIG. 13 is a flowchart of a send reply message sent by a Responder node according to an embodiment of the present invention.
  • Figure 15 is a network topology diagram according to Example 1 of the present invention.
  • Example 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.
  • 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.
  • the execution subject may be the detection initiator, or the detection party (same or different from the detection initiator).
  • 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.
  • 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.
  • the detecting initiator sends the response request message, which further includes:
  • the detecting initiator determines whether the response request message is an initial response request message sent by the initial node.
  • 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.
  • the type field is encapsulated in the data link layer header of the response request message.
  • detecting whether the response response message matches the pre-stored information specifically includes:
  • determining whether the upstream interface information in the response response packet matches the downstream mapping information includes the following two methods:
  • 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.
  • FIG. 2 is a multi-protocol exchange according to an embodiment of the present invention.
  • 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.
  • 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.
  • the forwarding plane modifies the content of the MPLS OAM packet, including: the downstream mapping information in the forwarding plane modification response request packet.
  • 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.
  • 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.
  • 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.
  • the term "module” may implement a combination of software and/or hardware of a predetermined function.
  • 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.
  • 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.
  • FIG. 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.
  • each of the above modules may be implemented by software or hardware.
  • 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.
  • the Initiator node 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.
  • the initiator 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 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.
  • the Initiator node 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.
  • FIG. 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.
  • FIG. 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:
  • 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.
  • Downstream Labels refers only to the labels corresponding to each FEC in the target FEC stack, and does not include other outer labels.
  • FIG. 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.
  • FIG. 9 is a format diagram of a Responder Egress TLV according to an embodiment of the present invention
  • 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.
  • FIG. 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:
  • TimeStamp Sent field is set to the relative time of day, seconds and microseconds.
  • 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.
  • 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.
  • 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.
  • 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.
  • step S603 the Initiator node constructs an IP/UDP header as follows:
  • the source IP is a routable IP address of the sender.
  • the destination IP is randomly selected from 127/8, or randomly selected from 0:0:0:0:0:FFFF:127/104
  • Source PORT is selected by the sender
  • 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.
  • 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.
  • 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.
  • step S607 the Initiator node determines whether it is the first round of echo request.
  • 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.
  • 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.
  • 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.
  • the C 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. .
  • 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.
  • 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:
  • step S701 the Transit or Egress node receives the echo request.
  • 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.
  • the mpls echo request message is sent to the control plane:
  • 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.
  • 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.
  • 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.
  • step S705 it is determined whether the above check is successful.
  • step S706 the check result is successful.
  • the Responder node 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.
  • 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.
  • 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.
  • step S707 the result of the check is a failure.
  • 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.
  • step S709 if it is not an MPLS OAM packet, the data plane immediately forwards the packet according to the normal data packet.
  • step S710 if it is an MPLS OAM packet, the data plane modifies the content of the packet before sending the packet.
  • 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.
  • 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.
  • the message can be modified according to the C flag carried in the echo request message.
  • 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.
  • 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.
  • 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.
  • the R flag in the DS Flags is set to 1.
  • 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.
  • the P2MP LSP 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.
  • 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:
  • TimeStamp Received field is set to the relative time of day, seconds and microseconds.
  • the target FEC Stack TLV can be copied from the request message.
  • the Responder node When the Responder node is Transit, it can also include Downstream Mapping TLVs and mark the E/M/R as needed.
  • 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.
  • IP/UDP is constructed as follows:
  • the source IP is a routable IP address on the Responder side.
  • the destination IP copies the source IP from the request message or from the Reply-to TLV.
  • Source PORT is 3503
  • 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:
  • step S901 the Initiator node receives the echo reply message.
  • 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.
  • step S903 it is checked whether the echo reply matches the echo request.
  • step S904 if there is no match, the echo reply is discarded.
  • 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.
  • 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.
  • the matched Downstream Mapping ratio exceeds a certain threshold.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 15 is a network topology diagram according to the first embodiment of the present invention.
  • 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.
  • 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:
  • the first round of echo request message is constructed on the A node, and the Echo request PDU is set:
  • Target FEC stack TLV ⁇ LDP FEC H ⁇
  • the label value is valid, the corresponding ILM exists, and the label operation is SWAP.
  • 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:
  • C flag is valid, the Downstream Mapping TLV is filled in according to the next hop before the tunnel iteration.
  • Node A obtains the new Downstream Address information from the echo reply and saves it locally as:
  • the included Downstream Mapping TLV is the same as in step S1001.
  • 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 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.
  • 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.
  • 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:
  • 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:
  • the included Downstream Mapping TLV is the same as in step S1001.
  • the B-node receives the echo request packet.
  • step S1004 the Downstream Mapping TLV of the packet is modified and then forwarded.
  • the control plane check that the label value is valid, the corresponding ILM exists, and the label operation is POP.
  • the stack is consistent with the target FEC stack.
  • the H node replies with an echo reply message, including:
  • 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 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:
  • the first round of echo request message is constructed on the A node, and the Echo request PDU is set:
  • Target FEC stack TLV ⁇ LDP FEC H ⁇
  • the label value is valid, the corresponding ILM exists, and the label operation is SWAP.
  • 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:
  • C flag is invalid, the Downstream Mapping TLV is filled in according to the next hop after the tunnel iteration.
  • Node A obtains the new Downstream Address information from the echo reply and saves it locally as:
  • the included Downstream Mapping TLV is the same as in step S1101.
  • 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 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.
  • On the control plane check that the label value is valid, the corresponding ILM exists, and the label operation is SWAP.
  • the stack is consistent with the target FEC stack.
  • the C node replies with an echo reply message, including:
  • Node A obtains the new Downstream Address information from the echo reply and saves it locally as:
  • the included Downstream Mapping TLV is the same as in step S1101.
  • the node B receives the echo request packet.
  • step S1104 the target FEC stack TLV and the Downstream Mapping TLV of the packet are modified and then forwarded.
  • 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 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 stack is consistent with the target FEC stack.
  • the D node replies with an echo reply message, including:
  • Node A obtains the new Downstream Address information from the echo reply and saves it locally as:
  • the included Downstream Mapping TLV is the same as in step S1101.
  • 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.
  • step S1104 the target FEC stack TLV and the Downstream Mapping TLV of the packet are modified and then forwarded.
  • 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.
  • 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 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 control plane check that the label value is valid, the corresponding ILM exists, and the label operation is POP.
  • the stack is consistent with the target FEC stack.
  • the H node replies with an echo reply message, including:
  • 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.
  • 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.
  • the detection process includes the following steps. For the sake of brevity, only the main processes related to this patent are described:
  • 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.
  • Target FEC stack TLV ⁇ mLDP FEC opaqueX ⁇
  • Target FEC stack TLV ⁇ mLDP FEC opaqueX ⁇
  • the label value is valid, the corresponding ILM exists, and the label operation is SWAP.
  • 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:
  • the Node B receives the echo request packet and replies to the echo reply packet, including:
  • the R node obtains the new Downstream Address information from the echo reply of A and saves it locally as:
  • the R node obtains the new Downstream Address information from the echo reply of B and saves it locally as:
  • the included Downstream Mapping TLV is the same as in step S1201.
  • 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 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.
  • the label value is valid, the corresponding ILM exists, and the label operation is SWAP.
  • 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:
  • the D node receives the echo request packet and replies to the echo reply packet, including:
  • the E-node receives the echo request packet and replies to the echo reply packet, including:
  • the F node receives the echo request packet and replies to the echo reply packet, including:
  • the R node obtains the new Downstream Address information from the echo reply of C and saves it locally as:
  • the R node obtains the new Downstream Address information from the echo reply of F and saves it locally as:
  • the included Downstream Mapping TLV is the same as in step S1201.
  • 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.
  • 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.
  • 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.
  • the G node replies with an echo reply message, including:
  • the H node receives the echo request message and replies to the echo reply message, including:
  • the I node receives the echo request packet and replies to the echo reply packet, including:
  • the J node receives the echo request message and replies to the echo reply message, including:
  • 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.
  • Embodiments of the present invention also provide a storage medium.
  • the foregoing storage medium may be configured to store program code for performing the following steps:
  • 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;
  • 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.
  • 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.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • a mobile hard disk e.g., a hard disk
  • magnetic memory e.g., a hard disk
  • 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;
  • 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.
  • 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.
  • the invention is not limited to any specific combination of hardware and software.
  • 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.

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne, dans ses modes de réalisation, un procédé, un appareil, et un système de détection et de traitement de commutation multiprotocole avec étiquette, le procédé de détection de commutation multiprotocole avec étiquette comportant les étapes consistant à: détecter un paquet de demande d'écho émis par une partie de déclenchement, le paquet de demande d'écho comportant un champ de type utilisé pour identifier des paquets d'exploitation, d'administration et de maintenance (OAM) de commutation multiprotocole avec étiquette (MPLS); recevoir un paquet de réponse d'écho renvoyé par un nœud d'émission ou un nœud de sortie sur la base des paquets d'OAM de MPLS, et détecter si le paquet de réponse d'écho concorde avec des informations stockées préalablement. Les modes de réalisation de la présente invention résolvent le problème, rencontré dans l'état antérieur de la technique, de la distorsion de la détection de LSP et du caractère inefficient et insuffisant de la détection de LSP P2MP.
PCT/CN2017/091477 2016-07-15 2017-07-03 Procédé, appareil, et système de détection et de traitement de commutation multiprotocole avec étiquette WO2018010560A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610567070.4 2016-07-15
CN201610567070.4A CN107623584A (zh) 2016-07-15 2016-07-15 多协议交换标签的检测、处理方法、装置及系统

Publications (1)

Publication Number Publication Date
WO2018010560A1 true WO2018010560A1 (fr) 2018-01-18

Family

ID=60952246

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/091477 WO2018010560A1 (fr) 2016-07-15 2017-07-03 Procédé, appareil, et système de détection et de traitement de commutation multiprotocole avec étiquette

Country Status (2)

Country Link
CN (1) CN107623584A (fr)
WO (1) WO2018010560A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020125651A1 (fr) * 2018-12-17 2020-06-25 中兴通讯股份有限公司 Procédé, appareil, et dispositif d'identification d'attribut d'étiquette, et support de stockage
EP3937437A1 (fr) * 2020-06-30 2022-01-12 Huawei Technologies Co., Ltd. Procédé de traitement de perte de paquets et dispositif de réseau
CN114500163A (zh) * 2020-10-23 2022-05-13 中国移动通信有限公司研究院 一种通信调度方法、装置和存储介质
CN116232996A (zh) * 2022-12-21 2023-06-06 中国人民解放军国防科技大学 基于标签交换的边缘网络数据包头压缩传输方法及系统

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110535771A (zh) * 2018-05-24 2019-12-03 中兴通讯股份有限公司 一种数据转发方法、网络设备和计算机可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101325584A (zh) * 2007-06-15 2008-12-17 华为技术有限公司 路由跟踪方法、mpls网络系统及其入口节点
CN101729391A (zh) * 2008-10-23 2010-06-09 华为技术有限公司 获取链路汇聚组信息的方法、节点和系统
US20120176911A1 (en) * 2010-06-10 2012-07-12 Ping Pan Supporting oam on protecting connections in shared mesh protection environment
US8472346B1 (en) * 2007-06-08 2013-06-25 Juniper Networks, Inc. Failure detection for tunneled label-switched paths

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8472346B1 (en) * 2007-06-08 2013-06-25 Juniper Networks, Inc. Failure detection for tunneled label-switched paths
CN101325584A (zh) * 2007-06-15 2008-12-17 华为技术有限公司 路由跟踪方法、mpls网络系统及其入口节点
CN101729391A (zh) * 2008-10-23 2010-06-09 华为技术有限公司 获取链路汇聚组信息的方法、节点和系统
US20120176911A1 (en) * 2010-06-10 2012-07-12 Ping Pan Supporting oam on protecting connections in shared mesh protection environment

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020125651A1 (fr) * 2018-12-17 2020-06-25 中兴通讯股份有限公司 Procédé, appareil, et dispositif d'identification d'attribut d'étiquette, et support de stockage
EP3937437A1 (fr) * 2020-06-30 2022-01-12 Huawei Technologies Co., Ltd. Procédé de traitement de perte de paquets et dispositif de réseau
US11570089B2 (en) 2020-06-30 2023-01-31 Huawei Technologies Co., Ltd. Packet loss processing method and network device
CN114500163A (zh) * 2020-10-23 2022-05-13 中国移动通信有限公司研究院 一种通信调度方法、装置和存储介质
CN116232996A (zh) * 2022-12-21 2023-06-06 中国人民解放军国防科技大学 基于标签交换的边缘网络数据包头压缩传输方法及系统
CN116232996B (zh) * 2022-12-21 2024-05-28 中国人民解放军国防科技大学 基于标签交换的边缘网络数据包头压缩传输方法及系统

Also Published As

Publication number Publication date
CN107623584A (zh) 2018-01-23

Similar Documents

Publication Publication Date Title
US10581732B2 (en) Target FEC (forwarding equivalence class) stack based FEC query in segment routing environments
WO2018010560A1 (fr) Procédé, appareil, et système de détection et de traitement de commutation multiprotocole avec étiquette
EP2995042B1 (fr) Apprentissage de plan de données de chaînes de service bidirectionnelles
WO2017148139A1 (fr) Procédé et dispositif de détection de défaillance
US11888726B2 (en) Path establishment method and controller
WO2019114437A1 (fr) Procédé, dispositif et système de détection de réseau bier-te
CN102404197B (zh) 分组的伪线层中包括的数据路径处理信息
US11627070B2 (en) Data packet processing method and apparatus, storage medium, and electronic device
US9350605B2 (en) Method and apparatus for multi-instance control plane for dynamic MPLS-TP tunnel management via in-band communication channel (G-ACH)
CN111614556B (zh) 一种基于bier的双向转发检测会话创建方法及相关设备
US11477114B2 (en) Packet forwarding method and apparatus
CN106656794A (zh) 一种报文传输方法及装置
EP4207685A1 (fr) Procédé et appareil de traitement d'en-tête de messages, support de stockage et dispositif électronique
CN106789725B (zh) 一种实现流量重定向的方法、装置和系统
EP3361683B1 (fr) Procédé et dispositif de calcul de trajet
CN107645401A (zh) 多协议标签交换的检测、处理方法、装置及系统
WO2020114083A1 (fr) Procédé et appareil de traitement d'informations ioam
CN106817273B (zh) 用于l3vpn业务诊断的方法和装置
CN117439935A (zh) 信息处理方法、设备和计算机可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17826897

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17826897

Country of ref document: EP

Kind code of ref document: A1