RFC 7555

Proxy MPLS Echo Request

📅 published June 2015, from ietf

Abstract ✨

Okay bestie, let's get into it 🎀 This is RFC 7555, called Proxy MPLS Echo Request. It's an Internet Standards Track doc from the IETF, so it's basically the consensus of the whole community 🫶 It's by G. Swallow and V. Lim (both Cisco Systems) and S. Aldrin (Huawei Technologies). It's dated June 2015 and the ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so no drama there 💅

The abstract is the vibe check 🦋 It's about remotely starting MPLS Pings on Label Switched Paths. You send an MPLS Proxy Ping Request to any Label Switching Router along an LSP. The two big reasons for it are: first, to cut down on the number of messages and processing when you're using LSP Ping on big Point-to-Multipoint LSPs, and second, to let you trace from leaf to leaf (or root) 🌸

Status of This Memo

Okay so this section is the official "who approved this" part 📜 It's an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), it has the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🧚

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7555 💜

Copyright Notice

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, because they're what decides your rights and restrictions for this doc 🤓 Any Code Components pulled from this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🍓

   1. Introduction ....................................................3
      1.1. Requirements Language ......................................4
      1.2. Terminology ................................................5
   2. Proxy Ping Overview .............................................5
      2.1. Initiating Proxy Ping ......................................6
      2.2. Handling at Proxy LSR ......................................6
           2.2.1. Backward Compatibility ..............................6
   3. Proxy MPLS Echo Request/Reply Procedures ........................7
      3.1. Procedures for the Initiator ...............................7
      3.2. Procedures for the Proxy LSR ...............................9
           3.2.1. Proxy LSR Handling When It Is Egress for FEC .......11
           3.2.2. Downstream Detailed Maps and Downstream
                  Maps in Proxy Reply ................................12
           3.2.3. Sending an MPLS Proxy Ping Reply ...................12
           3.2.4. Sending the MPLS Echo Requests .....................13
                  3.2.4.1. Forming the Base MPLS Echo Request ........13
                  3.2.4.2. Per-Interface Sending Procedures ..........14
   4. Proxy Ping Request/Reply Messages ..............................15
      4.1. Proxy Ping Request/Reply Message Formats ..................15
      4.2. Proxy Ping Request Message Contents .......................15
      4.3. Proxy Ping Reply Message Contents .........................16
   5. TLV Formats ....................................................16
      5.1. Proxy Echo Parameters TLV .................................16
           5.1.1. Next Hop Sub-TLV ...................................20
      5.2. Reply-to Address TLV ......................................21
      5.3. Upstream Neighbor Address TLV .............................21
      5.4. Downstream Neighbor Address TLV ...........................22
   6. Security Considerations ........................................23
   7. IANA Considerations ............................................24
      7.1. Proxy Echo Parameters Sub-TLVs ............................24
      7.2. Proxy Flags ...............................................25
      7.3. Downstream Address Mapping Registry .......................25
      7.4. Next Hop Sub-TLV Address Type Registry ....................25
   8. References .....................................................26
      8.1. Normative References ......................................26
      8.2. Informative References ....................................27
   Acknowledgements ..................................................27
   Authors' Addresses ................................................28

1. Introduction ✨

Okay, the intro explains why this exists 💖 It's driven by two big problems when you're diagnosing Point-to-Multipoint (P2MP) Label Switched Paths. The first is scalability, because MPLS Echo Request messages get automatically replicated as they travel down the tree 😭 The second one is the main motivation for LDP-based P2MP and Multipoint-to-Multipoint (MP2MP) LSPs [RFC6388]: being able to trace a sub-LSP from a leaf node all the way to the root node 🌳

Here's the drama. When you trace from a source to one particular leaf in a P2MP or MP2MP tree, nodes that aren't on that path still have to process the MPLS Echo Request messages they receive 🙈 The MPLS Echo Replies start multiplying, since Label Switching Routers (LSRs) that are part of the tree but not on the trace path could also be answering the request. That can even overwhelm the source, which has to process every MPLS Echo Reply it gets. Honestly, the apps using P2MP/MP2MP tunnels are gonna need OAM that's both rigorous and scalable 💅

Now imagine you want to trace a P2MP LSP to pin down a fault hitting one egress or a set of egresses. The normal way to trace is to keep pinging from the root and bump the Time to Live (TTL) by one after every three or so pings. That can create a huge amount of processing at the P2MP-LSP midpoints and egresses, and it can also flood the root with an unwieldy number of replies 🌊

So one alternative is to start pinging from at or near the affected egress(es) and then work backwards toward the root 🔙 You can hold the TTL constant (say, two), which limits the responses to the number of next-next-hops of the point where the ping starts 🎯

With Resource Reservation Protocol Traffic Engineering (RSVP-TE), all setup starts at the root of the tree. So the root knows about all the leaf nodes and usually the topology of the whole tree, which means it can easily kick off that alternative itself 👑

[RFC6388] is a whole different story 👀 Leaf nodes start the connection to the tree, and the first node toward the root that's already part of the tree grants it. The root might only know about its immediately adjacent (downstream) nodes. A leaf only knows about the (upstream) node right next to it at first, but that's enough to start a trace 🧚 So first, you apply the procedure above by asking that node to ping across the final link. Basically, a message goes from the leaf to the upstream node, asking it to send an MPLS Echo Request for the Forward Equivalence Class (FEC) of the tree in question on that link. The leaf also asks for the identity of the upstream neighbor's upstream neighbor for that FEC. With that info, you can keep repeating the procedure until the fault is localized or the root is reached 🔁 In every case, the TTL for the request only needs to be at most 2. So each request is pretty light, since only a limited number of nodes will get it ✨

This document defines protocol extensions to MPLS ping [RFC4379] so a third party can remotely cause an MPLS Echo Request message to be sent down an LSP, or part of one 🦋 The procedure above does require that the initiator knows the previous-hop node to the one that got pinged on the prior iteration. That info is readily available in [RFC4875]. This document also gives a way to get that info for P2MP and MP2MP LSPs set up with LDP as described in [RFC6388] 💖

The motivation here came from multicast scaling concerns, but the applicability might be wider 🌈 The procedures in this document apply to all LSP Ping FEC types where the MPLS Echo Request/Reply are IP encapsulated and the MPLS Echo Reply can be sent out of band of the LSP over IP. Remote pinging of LSPs that use in-band control channels is out of scope 🙅‍♀️

Other uses of this facility are also out of scope. Specifically, the procedures here only allow testing of a FEC stack made up of a single FEC 🎀 They also don't let the initiator specify the label assigned to that FEC, and they don't let the initiator add any extra labels to the label stack of the actual MPLS Echo Request message 🫶

1.1. Requirements Language

Here's the decoder ring for the capital words 🔑 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖

The term "Must Be Zero" (MBZ) shows up in TLV descriptions for reserved fields 🧸 These fields MUST be set to zero when sent and ignored on receipt 💅

Based on context, "leaf" and "egress" are used interchangeably. "Egress" is used where it was judged appropriate for consistency with [RFC4379]. "Receiver" is used when talking about receiving protocol messages 🌸

1.2. Terminology

Here's the glossary, so nobody gets lost in the acronym soup 🍓

      Term  Definition
      ----- -------------------------------------------
      LSP   Label Switched Path
      LSR   Label Switching Router
      mLDP  Multipoint LDP
      MP2MP Multipoint to Multipoint
      MTU   Maximum Transmission Unit
      P2MP  Point to Multipoint
      TTL   Time to Live

Okay that's the first chunk done 🧚✨ The next part picks up with the Proxy Ping Overview in Section 2, so stay tuned 💜

2. Proxy Ping Overview ✨

okay so this part is all about the Proxy Ping, and it's giving teamwork 🫶 This doc defines a protocol interaction between a first LSR and another LSR that's part of an LSP. The first LSR asks that second LSR to start an LSP Ping for the LSP on the first LSR's behalf 💅 The second LSR sends the LSP Ping for the first one, so it doesn't keep any state to handle the LSP Ping response. Instead, the responder sends that response to either the first LSR or to another LSR that's configured to handle it. There are two new LSP Ping messages for remote pinging: the MPLS Proxy Ping Request and the MPLS Proxy Ping Reply 🧚

A remote ping on a P2MP LSP usually involves at least three LSRs. In some scenarios, none of them are the ingress (root) or an egress (leaf) of the LSP. main character energy 👑

We refer to these LSRs with the following terms:

Initiator: the LSR that starts the ping operation by sending an MPLS Proxy Ping Request message
Proxy LSR: the LSR that is the destination of the MPLS Proxy Ping Request message and the potential initiator of the MPLS Echo Request
Receiver(s): the LSR(s) that receive the MPLS Echo Request message
Responder: a receiver that responds to an MPLS Proxy Ping Request or an MPLS Echo Request

ngl, in some scenarios the initiator could also be the responder. In that case, the response stays inside the LSR itself 🙈

2.1. Initiating Proxy Ping

The initiator formats an MPLS Proxy Ping Request message and sends it to the Proxy LSR, which is an LSR it believes is on the path of the LSP 🦋 This message tells the Proxy LSR to either reply with Proxy information or send an MPLS Echo Request in-band of the LSP. The initiator asks for Proxy information so it can learn the extra stuff it needs to build a later MPLS Proxy Ping Request. For example, during LSP traceroute, an initiator needs the downstream map information to form an MPLS Echo Request. An initiator may also want to learn a Proxy LSR's FEC neighbor information so it can form Proxy Ping Requests to various LSRs along the LSP. it's giving planning ahead 🗺️

2.2. Handling at Proxy LSR

The Proxy LSR either replies with the Proxy information that was requested, or it checks that it has a label mapping for the specified FEC and that it's authorized to send the specified MPLS Echo Request on behalf of the initiator 🔥

If the Proxy LSR has a label mapping for the FEC and every authorization check passes, the Proxy LSR formats an MPLS Echo Request. If the source address of the MPLS Echo Request isn't set to the Proxy Request source address, the initiator MUST include a Reply-to Address TLV containing the source address to use in the MPLS Echo Request. Then it sends the MPLS Echo Request in-band of the LSP 🎀

The receivers process the MPLS Echo Request as normal and send their MPLS Echo Replies back to the initiator 💖

If the Proxy LSR couldn't send an MPLS Echo Request as normal because it ran into a problem while trying to send, an MPLS Proxy Ping Reply message gets sent back with a Return Code saying that the MPLS Echo Request could not be sent 😭

2.2.1. Backward Compatibility

As described in Section 4.4 of [RFC4379], if the packet is not well-formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code set to "Malformed echo request received" and the Return Subcode set to zero. If there are any TLVs that aren't marked as "Ignore" and the Proxy LSR doesn't understand them, the Proxy LSR SHOULD send an MPLS "TLV not understood" (as appropriate), and the Return Subcode is set to zero. 🙈

In the case where the targeted Proxy LSR doesn't understand the LSP Ping Echo Request at all, it's like any other LSR that doesn't understand the messages: it MUST drop the message and MUST NOT send any message back to the initiator. literally silent treatment, but make it protocol 💀

3. Proxy MPLS Echo Request/Reply Procedures 🌈

3.1. Procedures for the Initiator

The initiator creates an MPLS Proxy Ping request message.

The message MUST contain a Target FEC Stack that describes the FEC being tested. The topmost FEC in the Target FEC Stack is used at the Proxy LSR to look up the MPLS label stack that will be used to encapsulate the MPLS Echo Request packet 🍓

The MPLS Proxy Ping Request message MUST contain a Proxy Echo Parameters TLV. In that TLV, the address type is set to either IPv4 or IPv6. The Destination IP Address is set to the value the Proxy LSR will use to build the MPLS Echo Request packet. The MPLS Echo Request IP header destination address is as specified in [RFC4379]. If the Address Type is IPv4, it MUST be an address from the range 127/8. If the Address Type is IPv6, it MUST be an address from the range ::ffff:7f00:0/104 ✨

The Reply Mode and Global Flags of the Proxy Echo Parameters TLV are set to the values to be used in the MPLS Echo Request message header. The Source UDP Port is set to the value to be used in the MPLS Echo Request. (The source port is supplied by the Proxy Ping initiator because it, or an LSR known to it, handles the LSP Ping responses.) The TTL is set to the value to be used in the outgoing MPLS label stack. See Section 5.1 for further details. 💅

If the FEC's Upstream/Downstream Neighbor address information is required, the initiator sets the "Request for FEC neighbor information" Proxy Flags in the Proxy Echo Parameters TLV 🔥

If a Downstream Detailed Mapping TLV (or Downstream Mapping TLV, which is deprecated) is required in an MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream Detailed Mapping" (or "Request for Downstream Mapping") Proxy Flag in the Proxy Echo Parameters TLV. Only one of the two flags can be set 🦋

The Proxy Request Reply Mode is set to one of the Reply Modes defined in [RFC4379], as appropriate.

A list of next-hop IP addresses MAY be included to limit the next hops towards which the MPLS Echo Request message will be sent. These are encoded as Next Hop sub-TLVs and included in the Proxy Echo Parameters TLV 🎀

Although it isn't explicitly spelled out in [RFC4379], LSP Ping packets can be formed to a desired size using a Pad TLV and then used to test the Maximum Transmission Unit (MTU) of an LSP. When testing an LSP's MTU, if the message is transported as an IP datagram, the IP header DF bit MUST be set to prevent IP fragmentation by the IP forwarding layer. The Proxy Echo Parameter TLV MPLS Payload Size field is defined for this purpose and may be set to request that the MPLS Echo Request (including any IP and UDP header) be zero-padded to the specified size. When a non-zero MPLS payload size is specified, the Proxy LSR introduces a Pad TLV to build the MPLS Echo Request packet, so in this case, the Proxy Ping Request MUST NOT include a Pad TLV. it's a whole balancing act 🤹‍♀️

Any of the following TLVs MAY be included. These TLVs are used to form the MPLS Echo Request messages by the Proxy LSR:

Pad
Vendor Enterprise Number
Reply TOS Byte
P2MP Responder Identifier [RFC6425]
Echo Jitter [RFC6425]
Vendor Private TLVs

Downstream Detailed Mapping (DDMAP) or Downstream Mapping (DSMAP) TLVs MAY be included. These TLVs will be matched to the next-hop address for inclusion in those particular MPLS Echo Request messages 🧚

The message is then encapsulated in a UDP packet. The source UDP port for the MPLS Proxy Ping Request message is chosen by the initiator, and the destination UDP port is set to 3503. The IP header is set as follows: the source IP address is a routable address of the initiator, and the destination IP address is a routable address to the Proxy LSR. The packet is then sent with the IP TTL set to 255 🚀

3.2. Procedures for the Proxy LSR ✨

okay so the Proxy LSR is the one that catches the MPLS Proxy Ping Request and checks it's actually well-formed 🫶 it looks at the TLVs that aren't marked "Ignore" and makes sure it understands them. if any part of the message is messed up, the Return Code gets set to "Malformed echo request received" 💀. if everything's well-formed but some TLVs aren't understood, the Return Code is "TLV not understood" instead. the Return Subcode is zero for both cases, no notes 🎀

if the Reply Mode in the message header isn't 1 ("Do not reply"), an MPLS Proxy Ping Reply message SHOULD be sent, as described below 💖

if the Return Code is "TLV not understood", the Proxy LSR doesn't need to do any more processing of the request ✨ it just sends an MPLS Proxy Ping Reply with an Errored TLVs TLV containing (only) the TLVs it didn't understand 🦋

the MPLS Proxy Ping Request is expected to arrive at the Proxy LSR through regular IP forwarding 🌸 not the same tricks people use to shove an MPLS Echo Request into an LSP. an MPLS Echo Request would lean on IP TTL, MPLS TTL, and/or loopback addresses (IPv4 127.x.x.x or IPv6 ::ffff:7f00/104) in the IP header destination address field, so the packet gets pushed into an LSR's forwarding exception processing path 🧚

the Proxy LSR MUST check whether MPLS Proxy Ping Request packets arrive via the exception path 👑 packets arriving through IP TTL expiry, an IP destination address set to a loopback address, or label TTL expiry MUST be treated as "Unauthorized" packets 🙈 an MPLS Proxy Ping Reply MAY be sent with a Return Code of 16, "Proxy Ping not authorized" 💅

the Sender's Handle and Sequence Number header fields aren't examined 🍓 but they're included in the MPLS Proxy Ping Reply or MPLS Echo Request, if either one gets sent as a direct result of the received message ✨

the Proxy LSR checks that it has a label mapping for the specified FEC, works out whether it's an ingress, egress, transit or bud node, and then sets the Return Code to match 🔥 there's a new Return Code, 19, "Replying router has FEC mapping for topmost FEC", defined for when the Proxy LSR is an ingress (like the head of a TE tunnel or a transit router) 🦋 the existing Return Codes from RFC 4379 just don't fit that situation. like, when a Proxy LSR is a transit router, it's not right for the Return Code to describe how the packet would transit, because the MPLS Proxy Ping Request doesn't say which input interface the MPLS Echo Request would be switched from at the Proxy LSR 😭

the Proxy LSR then decides whether it's authorized to send the specified MPLS Echo Request on behalf of the initiator 💖 a Proxy LSR MUST be capable of filtering addresses to validate initiators 🫶 other filters on FECs or MPLS Echo Request contents MAY be applied 🌈 if a configured filter has been invoked and an address doesn't pass it, then an MPLS Echo Request message MUST NOT be sent, and the event SHOULD be logged 🙈 an MPLS Proxy Ping Reply MAY be sent with a Return Code of 16, "Proxy Ping not authorized" 💅

the destination address in the Proxy Echo Parameters TLV is checked to make sure it's in the allowed IPv4 or IPv6 address range 🎀 if not, the Return Code is "Malformed echo request received" and the Return Subcode is zero. if the Reply Mode isn't 1, an MPLS Proxy Ping Reply message SHOULD be sent as described below ✨

the TTL in the Proxy Echo Parameters TLV is checked to make sure it's in the range [1,255] 🧚 if it isn't, the Return Code MUST be set to 17, "Proxy Ping parameters need to be modified" 😭 if the Reply Mode isn't 1, an MPLS Proxy Ping Reply message SHOULD be sent as described below 💖

if the "Request for FEC Neighbor Address info" flag is set, the Upstream Neighbor Address and Downstream Neighbor Address TLVs get formatted for the MPLS Proxy Ping reply 🦋 if the Upstream or Downstream address is unknown, that TLV is omitted 🌸

if there are Next Hop sub-TLVs in the Proxy Echo Parameters TLV, each address gets checked to see if it's a valid next hop for this FEC 🔥 if any aren't, the Proxy Echo Parameters TLV SHOULD be updated to remove the unrecognized Next Hop sub-TLVs ✨ the updated Proxy Echo Parameters TLV MUST be included in the MPLS Proxy Ping Reply 👑

if the "Request for Downstream Detailed Mapping" or "Request for Downstream Mapping" flag is set, the Proxy LSR formats a DS/DDMAP TLV for each interface the MPLS Echo Request will be sent over, so they can go in the MPLS Proxy Ping Reply 💅

if the Proxy LSR is the egress for the FEC, what it does depends on whether it's the egress of a P2P LSP, a P2MP LSP, or an MP2MP LSP 🌈 there are more details in Section 3.2.1, "Proxy LSR Handling When It Is Egress for FEC" 🧚

if the Reply Mode of the MPLS Proxy Ping Request message header is 1 ("Do not reply"), no MPLS Proxy Ping Reply is sent 🙈 otherwise, an MPLS Proxy Ping Reply message or MPLS Echo Request SHOULD be sent as described below 💖

3.2.1. Proxy LSR Handling When It Is Egress for FEC ✨

this section covers the different behaviours for the Proxy LSR when it's the egress for the FEC 🦋 for the P2MP bud node and MP2MP bud node egress cases, different behaviour is required 🫶

if an MPLS Echo Request is originated by an LSR that's a bud or egress node of a P2MP/MP2MP, the MPLS Echo Replies come back from downstream/upstream LSRs and won't include an MPLS Echo Reply from the LSR that originated the request 💅 this section describes what a bud or egress node should or shouldn't return from MPLS Echo Replies in the Proxy Echo Reply, so that no changes are needed in implementations that are compliant with [RFC4379] 🌸 the Proxy Initiator should get the same MPLS Echo Replies as it would if it were the originator of the LSP Ping, and any extra info (like the Proxy LSR being a bud or egress node) is returned in the MPLS Proxy Ping Reply 🎀

when the Proxy LSR is the egress of a P2P FEC, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the Return Code set to 3, "Replying router is an egress for the FEC at stack-depth", and the Return Subcode set to zero 💖

when the Proxy LSR is the egress of a P2MP FEC, it can be either a bud node or just an egress 🧚 if it's a bud node, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the return code set to 3, "Replying router is an egress for the FEC at stack-depth", and Return Subcode set to zero 🔥 DS/DDMAPs are only included if the Proxy Initiator asked for information to be returned in an MPLS Proxy Ping Reply 🌈 if the Proxy LSR is a bud node but nobody asked for an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send MPLS Echo Request packet(s) to the downstream neighbors instead (no MPLS Echo Reply goes to the Proxy Initiator to show the Proxy LSR is an egress) 👑 if the Proxy LSR is just an egress, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the Return Code set to 3, "Replying router is an egress for the FEC at stack-depth", and Return Subcode set to zero 💅

when the Proxy LSR is the egress of a MP2MP FEC, it can be either a bud node or just an egress 🦋 LSP Pings sent from a leaf of a MP2MP behave differently in this case 🫶 MPLS Echo Requests are sent to all upstream/downstream neighbors, so the Proxy LSRs need to be consistent with that variation 🌸 if the Proxy LSR is a bud node or just an egress, an MPLS Proxy Ping Reply SHOULD be sent to the Proxy Initiator with the return code set to 3, "Replying router is an egress for the FEC at stack-depth", with Return Subcode set to zero, and DS/DDMAPs are included only if the Proxy Initiator asked for information to be returned in an MPLS Proxy Ping Reply 🎀 if the Proxy LSR wasn't asked to return info in an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send MPLS Echo Request packets to all upstream/downstream neighbors, the same way it would when sourcing an LSP Ping from a MP2MP leaf (no MPLS Echo Reply goes to the Proxy Initiator saying the Proxy LSR is an egress) ✨

3.2.2. Downstream Detailed Maps and Downstream Maps in Proxy Reply ✨

when the Proxy LSR is a transit or bud node, downstream maps for how the packet gets transited can't be supplied unless an ingress interface for the MPLS Echo Request is specified 🔥 since that info isn't available and all valid output paths are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) describing the entire set of paths the packet can be replicated onto 🦋 this is similar to when an LSP Ping gets initiated at the Proxy LSR 💖 for mLDP, there's a DS/DDMAP per upstream/downstream neighbor for MP2MP LSPs, or per downstream neighbor in the P2MP LSP case 🌈

when the Proxy LSR is a bud node or egress in an MP2MP LSP, or a bud node in a P2MP LSP, an LSP Ping initiated from the Proxy LSR would only send packets to the neighbors and not to itself, even though the Proxy LSR is itself an egress for the FEC 🧚 to match what an LSP Ping from the Proxy LSR would show, the Proxy Reply SHOULD contain DS/DDMAPs for only the paths to the upstream/downstream neighbors, with no DS/DDMAP describing its own egress paths 🫶 the Proxy LSR tells you it's an egress for the FEC using a different Proxy Reply Return Code 👑 that Return Code is either 19, "Replying router has FEC mapping for topmost FEC", or 3, "Replying router is an egress for the FEC at stack-depth" 💅

3.2.3. Sending an MPLS Proxy Ping Reply ✨

the Reply Mode, Sender's Handle, and Sequence Number fields are copied from the Proxy Ping Request message 🌸 the TLVs specified above get included 🎀 the message is encapsulated in a UDP packet 🦋 the source IP address is a routable address of the Proxy LSR, and the source port is the well-known UDP port for LSP Ping 🧚 the destination IP address and UDP port are copied from the source IP address and UDP port of the MPLS Proxy Ping Request 💖 and the IP TTL is set to 255 🔥

3.2.4. Sending the MPLS Echo Requests ✨

an MPLS Echo Request is formed as described in the next section 💅 the section below describes how the MPLS Echo Request is sent on each interface 🌈

3.2.4.1. Forming the Base MPLS Echo Request 🎀

Okay, so if Next Hop sub-TLVs came along in the received Proxy Echo Parameters TLV, the Next_Hop_List is built from the addresses in those sub-TLVs, adjusted as described in Section 3.2. If there are none, the list is set to every next hop the FEC would be forwarded to. Bestie, it's giving thorough 💅

Then the Proxy LSR formats an MPLS Echo Request message. The Global Flags and Reply Mode get copied over from the Proxy Echo Parameters TLV, and both the Return Code and Return Subcode are set to zero 🌸

The Sender's Handle and Sequence Number are copied from the remote MPLS Echo Request message ✨

The TimeStamp Sent is set to the time of day (in seconds and microseconds) when the MPLS Echo Request is sent, and the TimeStamp Received is set to zero 🦋

If the Reply-to Address TLV is there, it sets the MPLS Echo Request source address. If it's not, the source address falls back to the Proxy Request source address 💜

Now for the TLVs that get copied from the MPLS Proxy Ping Request message. Only the Target FEC Stack is REQUIRED to show up in that message, so that's the one that really matters 👑 The Pad TLV doesn't get copied if the Proxy Echo Parameter TLV MPLS payload size is non-zero 🙈

Target FEC Stack
Pad
Vendor Enterprise Number
Reply TOS Byte
P2MP Responder Identifier [RFC6425]
Echo Jitter [RFC6425]
Vendor Private TLVs

If the Proxy Echo Parameter TLV MPLS payload size is non-zero, the Proxy LSR adds a Pad TLV so the MPLS Echo Request (IP and UDP header included) gets zero-padded out to that payload size 🍓 The first octet in the Value part of the Pad TLV is set to 1, "Drop Pad TLV from reply", and the rest of the Value part is filled with zeros. If the IP header is used to encapsulate the MPLS Echo Request, the DF bit MUST be set to one. Non-negotiable, periodt 🔥

Next, the message gets wrapped in a UDP packet. The source UDP port is copied from the Proxy Echo Parameters TLV, and the destination port is copied from the MPLS Proxy Ping Request message 🧚

The source IP address is set to a routable address from the Reply-to Address TLV, or to the source address of the received Proxy Request. And as usual, the TTL of the IP packet is set to 1 🌈

If the Explicit Differentiated Services Code Point (DSCP) flag is set, the Requested DSCP byte gets checked. If that setting is permitted, the DSCP byte of the IP header of the MPLS Echo Request message is set to that value ✨ But if the Proxy LSR doesn't allow explicit control of the DSCP byte, the MPLS Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be included in any MPLS Proxy Ping Reply message. That's how the requestor finds out why the MPLS Echo Request was never sent 💀 The Return Code MUST be set to 17, "Proxy Ping parameters need to be modified". If the Explicit DSCP flag isn't set, the Proxy LSR SHOULD set the MPLS Echo Request DSCP settings to the value normally used to source LSP Ping packets 💖

3.2.4.2. Per-Interface Sending Procedures 🦋

The Proxy LSR now loops through the Next_Hop_List and tweaks the base MPLS Echo Request to form the MPLS Echo Request packet that actually gets sent out on each particular interface. It's giving assembly line, but make it cute 🌸

The outgoing label stack gets figured out for each next-hop address. The TTL for the label that matches the FEC in the FEC stack is set so the TTL on the wire is the TTL specified in the Proxy Echo Parameters. If any extra labels get pushed onto the stack, their TTLs are set to 255. This makes sure the requestor has no control over tunnels that have nothing to do with the FEC being tested 🔒

If the MPLS Proxy Ping Request message had Downstream Mapping TLVs or Downstream Detailed Mapping TLVs, those get checked. If the Downstream IP address matches the next-hop address, that Downstream Mapping TLV gets included in the MPLS Echo Request ✨

Then the packet is transmitted on that interface. Send it, bestie 🚀

4. Proxy Ping Request/Reply Messages ✨

This document defines two new LSP Ping messages: the MPLS Proxy Ping Request and the MPLS Proxy Ping Reply 🎀

4.1. Proxy Ping Request/Reply Message Formats 💜

The packet format is the one defined in [RFC4379]. Two new message types, Proxy Ping Request and Reply, are being added 🌈

Message Type

Type    Message
----    -------
   3    MPLS Proxy Ping Request
   4    MPLS Proxy Ping Reply

4.2. Proxy Ping Request Message Contents 🍓

The MPLS Proxy Ping Request message MAY contain the following TLVs:

       Type    TLV
       ----    -----------
          1    Target FEC Stack
          2    Downstream Mapping (DEPRECATED)
          3    Pad
          5    Vendor Enterprise Number
         10    Reply TOS Byte
         11    P2MP Responder Identifier [RFC6425]
         12    Echo Jitter [RFC6425]
         20    Downstream Detailed Mapping
         21    Reply Path [RFC7110]
         22    Reply TC [RFC7110]
         23    Proxy Echo Parameters
         24    Reply-to Address
          *    Vendor Private TLVs

      * TLVs types in the Vendor Private TLV Space MUST be ignored if
        not understood

4.3. Proxy Ping Reply Message Contents 🧚

The MPLS Proxy Ping Reply message MAY contain the following TLVs:

       Type    TLV
       ----    -----------
          1    Target FEC Stack
          2    Downstream Mapping (DEPRECATED)
          5    Vendor Enterprise Number
          9    Errored TLVs
         20    Downstream Detailed Mapping
         23    Proxy Echo Parameters
         25    Upstream Neighbor Address
         26    Downstream Neighbor Address (0 or more)
          *    Vendor Private TLVs

      * TLVs types in the Vendor Private TLV Space MUST be ignored if
        not understood

5. TLV Formats 🌟

5.1. Proxy Echo Parameters TLV ✨

Okay bestie, the Proxy Echo Parameters TLV is a TLV that MUST be included in an MPLS Proxy Ping Request message 🎀. Its length is 12 + K + S, where K is the length of the Destination IP Address field and S is the total length of the sub-TLVs 🧮. This TLV can be used for one of two jobs: 1) controlling the attributes used to compose and send an MPLS Echo Request, or 2) asking the Proxy LSR for info about the topmost FEC in the target FEC stack. It can't do both at once 🙅‍♀️. When the Proxy LSR is being queried (so the info has to come back in an MPLS Proxy Ping Reply), no MPLS Echo Request gets sent from the Proxy LSR 🦋. Also, the MPLS Proxy Ping Request Proxy Echo Parameters TLV's Proxy Flags SHOULD be set appropriately, as described below 💅.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Address Type |   Reply Mode  |        Proxy Flags            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TTL      |  Rqst'd DSCP  |        Source UDP Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Global Flags         |       MPLS Payload Size       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                      Destination IP Address                   :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                                                               :
   :                            Sub-TLVs                           :
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address Type 🏷️

This is the type and length of the address found in the Destination IP Address and Next Hop IP Addresses fields. The values are shared with the Downstream Mapping Address Type Registry. The type codes that apply here are in this table:

           Address Family   Type     Length

                IPv4          1         4
                IPv6          3        16

Reply Mode 📬

This is the reply mode to be sent in the MPLS Echo Request message. The values are as specified in [RFC4379].

Proxy Flags 🚩

The Proxy Request Initiator sets zero, one, or more of these flags to request actions at the Proxy LSR.

0x0001 Request for FEC Neighbor Address info 🌸

When this is set, it asks the Proxy LSR to supply the Upstream and Downstream neighbor address info in the MPLS Proxy Ping Reply message. This flag only applies to the topmost FEC in the FEC stack if the FEC type corresponds with a P2MP or MP2MP LSP. The Proxy LSR MUST respond (as applicable) with Upstream Neighbor Address and Downstream Neighbor Address TLV(s) in the MPLS Proxy Ping Reply message. The Upstream Neighbor Address TLV needs be included only if there is an upstream neighbor. Likewise, one Downstream Neighbor Address TLV needs to be included for each Downstream Neighbor the LSR learned bindings from.

Setting this flag makes the Proxy LSR cancel sending any MPLS Echo Request. The initiator can use the info learned from the MPLS Proxy Ping Reply that gets sent instead to generate subsequent proxy requests 🧠.

0x0002 Request for Downstream Mapping 🗺️

When this is set, it asks the Proxy LSR to supply a Downstream Mapping TLV (see [RFC4379]) in the MPLS Proxy Ping Reply message. Either this flag may be set or the "Request for Downstream Detailed Mapping" flag may be set, but not both.

Setting this flag makes the Proxy LSR cancel sending an MPLS Echo Request. The Proxy Initiator can use the info learned from such a Proxy Reply to generate subsequent Proxy Requests 💫.

0x0004 Request for Downstream Detailed Mapping 🔍

When this is set, it asks the Proxy LSR to supply a Downstream Detailed Mapping TLV (see [RFC6424]) in the MPLS Proxy Ping Reply message. It's not valid to have the "Request for Downstream Mapping" flag set when this flag is set. Setting this flag makes the Proxy LSR cancel sending an MPLS Echo Request. The initiator can use the info learned from the MPLS Proxy Ping Reply that gets sent instead to generate subsequent proxy requests 🦋.

0x0008 Explicit DSCP Request 💅

When this is set, it asks the Proxy LSR to use the supplied "Rqst'd DSCP" byte in the Echo Request message.

TTL ⏳

This is the TTL to be used in the label stack entry corresponding to the topmost FEC in the MPLS Echo Request packet. Valid values are in the range [1,255].

Requested DSCP 🎯

This field is only valid if the Explicit DSCP flag is set. If the flag isn't set, the field MUST be zero on transmission and ignored on receipt. When the flag is set, this field holds the DSCP value to be used in the MPLS Echo Request packet IP header.

Source UDP Port 🔌

This is the source UDP port to be sent in the MPLS Echo Request packet.

Global Flags 🚀

These are the Global Flags to be sent in the MPLS Echo Request message.

MPLS Payload Size 📏

This is used to request that the MPLS payload (IP header + UDP header + MPLS Echo Request) be padded using a zero-filled Pad TLV, so that the IP header, UDP header, and MPLS Echo Request add up to the specified size. If the field is set to zero, no size request is being made. If the requested size is less than the minimum size needed to form the MPLS Echo Request, the request is treated as best-effort, with the Proxy LSR building the smallest possible packet (so, not using a Pad TLV). The IP header DF bit MUST be set when this field is non-zero 🙌.

Destination IP Address 🎈

If the Address Type is IPv4, this is an address from the range 127/8. If the Address Type is IPv6, it's an address from the range ::ffff:7f00:0/104.

Sub-TLVs 🧩

This is a list of TLV-encoded sub-TLVs. Currently one is defined:

          Sub-Type       Length            Sub-TLV Name
          --------       ------            ------------
                 1         8+              Next Hop

5.1.1. Next Hop Sub-TLV 🦘

Okay, so this sub-TLV describes one particular next hop that the Echo Request packet should be sent towards 🧭. If the topmost FEC in the FEC stack is a multipoint LSP, this sub-TLV can show up multiple times.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Addr Type   |                      MBZ                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Next Hop IP Address (4 or 16 octets)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Next Hop Interface  (0, 4, or 16 octets)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address Type 🏷️

           Type     Type of Next Hop   Addr Length  Interface Field (IF)
                                                          Length
             1        IPv4 Numbered           4             4
             2        IPv4 Unnumbered         4             4
             3        IPv6 Numbered          16            16
             4        IPv6 Unnumbered        16             4
             5        Reserved
             6        IPv4 Protocol Adj       4             0
             7        IPv6 Protocol Adj      16             0

📝 Note: Types 1-4 line up with the types in the DSMAP TLV. They're expected to be filled in with info from a previously returned DSMAP TLV. Types 6 and 7 are meant to be filled in from the local address info in a previously returned Downstream Neighbor Address TLV or Upstream Neighbor Address TLV.

Next Hop IP Address 📍

This is a next hop address that the Echo Request message is to be sent towards.

Next Hop Interface 🔗

This is the identifier of the interface the Echo Request message is to be sent through. For Addr Type 5 and 6, the Next Hop Interface field isn't used and MUST be of an associated byte length of zero octets 🙈.

5.2. Reply-to Address TLV 💌

This TLV is used to specify the MPLS Echo Request IP source address. This address MUST be IP reachable via the Proxy LSR; otherwise, it will be rejected 🚫.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Address Type |                      MBZ                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                       Reply-to Address                        :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address Type 🏷️

A type code as specified in the table below:

           Type     Type of Address

             1        IPv4
             3        IPv6

5.3. Upstream Neighbor Address TLV 🦋

okay so this TLV is all about the friend who sits right before you in the line 🫶 it tells you who the immediate upstream neighbor is for the topmost FEC in the FEC stack. here's the layout:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Upst Addr Type |Local Addr Type|             MBZ               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                     Upstream Address                          :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                         Local Address                         :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Upst Addr Type and Local Addr Type 💜 are the two little fields that tell you what kind of address shows up next and how long it is. the codes are in this table:

       Type     Type of Address          Length

         0        No Address Supplied       0
         1        IPv4                      4
         3        IPv6                     16

Upstream Address 🌸 is the address of the immediate upstream neighbor for the topmost FEC in the FEC stack. the main rule here: if the protocol adjacency exists by which the label for this FEC was exchanged, this address MUST be the address used in that protocol exchange. no going rogue with a different one, bestie 💅

Local Address 🍓 is the local address used in the protocol adjacency by which the label for this FEC was exchanged. basically "this is me, the one who got the label" ✨

5.4. Downstream Neighbor Address TLV 🧚

this one is the mirror image of the last TLV, so it's giving déjà vu 😭 it carries the downstream friend instead. here's the layout:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Dnst Addr Type |Local Addr Type|             MBZ               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                     Downstream Address                        :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                         Local Address                         :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dnst Addr Type and Local Addr Type 🩵 work the same way as before: they set the type and length of each address. the codes:

          Type     Type of Address          Length

            0        No Address Supplied       0
            1        IPv4                      4
            3        IPv6                     16

Downstream Address 💖 is the address of an immediate downstream neighbor for the topmost FEC in the FEC stack. same deal as the upstream one: if the protocol adjacency exists by which the label for this FEC was exchanged, this address MUST be the address used in that protocol exchange. consistency is everything, periodt 👑

Local Address 🦋 is the local address used in the protocol adjacency by which the label for this FEC was exchanged. 🫶

6. Security Considerations 🛡️

ok security time, and it's serious, bestie 😤 the mechanisms in this document are meant to live inside a service provider network, and they should only be kicked off under the authority of that network's administration. no outsiders poking around 🚫

if that network also carries Internet traffic, or lets in IP access from other administrations, the MPLS Proxy Ping message SHOULD be discarded at the points where IP packets come in from other administrations. you can do that by filtering on source address, or by filtering all MPLS ping messages on UDP port. the border is where the bouncer stands 💅

any node that acts as a Proxy LSR SHOULD validate requests against a set of valid source addresses. an implementation MUST provide such filtering capabilities. no filter, no party 🎀

MPLS Proxy Ping Request messages are IP addressed directly to the Proxy LSR. so if a Proxy LSR receives an MPLS Proxy Ping message via expiration of the IP or Label Stack Entry TTL, it MUST NOT be acted upon. a message that got there by accident does not get to run the show 🙈

if an MPLS Proxy Ping Request's IP source address is not IP reachable by the Proxy LSR, the Proxy Request MUST NOT be acted upon. unreachable senders get ghosted 👻

the last bit is kind of iconic 👑 MPLS Proxy Ping Requests can only make their request by specifying a FEC. this makes sure that only valid MPLS Echo Request messages can get created, so no label-spoofing attacks are possible ✨

7. IANA Considerations 📋

per this document, IANA has made the following assignments 🌈

7.1. Proxy Echo Parameters Sub-TLVs 🧚

hmm okay so IANA made a brand new registry for Proxy Echo Parameters Sub-TLVs and it's kept up to date. assignments follow the same rules spelled out in Section 7.2 of [RFC4379] 💖 here's what's in it right now:

         Sub-Type     Sub-TLV Name
         --------     ------------
            0         Reserved
            1         Next Hop

7.2. Proxy Flags 🦋

IANA also created and maintains a new registry for the Proxy Flags used with the Proxy Echo Parameters TLV (more details in Section 5.1 🫶). it lives in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, which sits in the "Multiprotocol Label Switching Architecture (MPLS)" name space. the registration procedure is Standards Action [RFC5226]. the initial values look like this:

         Bit Number     Name
         ----------     ----
             0          Request for FEC Neighbor Address info
             1          Request for Downstream Mapping
             2          Request for Downstream Detailed Mapping
             3          Explicit DSCP Request
             4-15       Unassigned

7.3. Downstream Address Mapping Registry 🌸

this document adds some assignments to the Downstream Address Mapping Registry, and it also updates the registry defined by [RFC6426] ✨ the registration procedure stays Standards Action, and there's a note that got added:

When a code point is assigned that is not also assigned in the Next Hop Address Type Registry, the code point there must be marked "Reserved".

the new assignments look like this:

   Type #      Address Type         K Octets
   ------      ------------         --------
        6      Reserved             N/A       RFC 7555
        7      Reserved             N/A       RFC 7555

7.4. Next Hop Sub-TLV Address Type Registry 🍓

IANA made a brand new registry called the "Next Hop Address Type Registry" 🎀 the allocation policy is Standards Action, and there's also a note:

When a code point is assigned that is not also assigned in the Downstream Address Mapping Registry, the code point there must be marked "Reserved".

the initial allocations are:

      Type     Type of Next Hop   Addr Length  IF Length   Reference

      1        IPv4 Numbered           4          4        [RFC4379]
      2        IPv4 Unnumbered         4          4        [RFC4379]
      3        IPv6 Numbered          16         16        [RFC4379]
      4        IPv6 Unnumbered        16          4        [RFC4379]
      5        Reserved                                     RFC 7555
      6        IPv4 Protocol Adj       4          0         RFC 7555
      7        IPv6 Protocol Adj      16          0         RFC 7555
      8-255    Unassigned

8. References 📚

8.1. Normative References 💜

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, <http://www.rfc-editor.org/info/rfc6424>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <http://www.rfc-editor.org/info/rfc6425>.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, DOI 10.17487/RFC6426, November 2011, <http://www.rfc-editor.org/info/rfc6426>.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, DOI 10.17487/RFC7110, January 2014, <http://www.rfc-editor.org/info/rfc7110>.

8.2. Informative References 🦋

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.

Acknowledgements 🎀

big thank-yous to Nobo Akiya, Adrian Farrel, Tom Yu, Tom Taylor, and Warren Kumari 🫶 the authors wanted to thank them for their detailed reviews and insightful comments, and honestly the whole doc is better because of them 🥹✨

Authors' Addresses 💌

   George Swallow
   Cisco Systems
   1414 Massachusetts Ave
   Boxborough, MA  01719
   United States

   EMail: swallow@cisco.com

   Vanson Lim
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   United States

   EMail: vlim@cisco.com

   Sam Aldrin
   Huawei Technologies
   2330 Central Express Way
   Santa Clara, CA  95951
   United States

   EMail: aldrin.ietf@gmail.com

📦 where this page comes from

ietf: rfc7555 2015-06
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms

RFC 7555

Abstract ✨

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction ✨

1.1. Requirements Language

1.2. Terminology

2. Proxy Ping Overview ✨

2.1. Initiating Proxy Ping

2.2. Handling at Proxy LSR

2.2.1. Backward Compatibility

3. Proxy MPLS Echo Request/Reply Procedures 🌈

3.1. Procedures for the Initiator

3.2.1. Proxy LSR Handling When It Is Egress for FEC ✨

3.2.2. Downstream Detailed Maps and Downstream Maps in Proxy Reply ✨

3.2.3. Sending an MPLS Proxy Ping Reply ✨

3.2.4. Sending the MPLS Echo Requests ✨

3.2.4.1. Forming the Base MPLS Echo Request 🎀

3.2.4.2. Per-Interface Sending Procedures 🦋

4. Proxy Ping Request/Reply Messages ✨

4.1. Proxy Ping Request/Reply Message Formats 💜

4.2. Proxy Ping Request Message Contents 🍓

4.3. Proxy Ping Reply Message Contents 🧚

5. TLV Formats 🌟

5.1. Proxy Echo Parameters TLV ✨

5.1.1. Next Hop Sub-TLV 🦘

5.2. Reply-to Address TLV 💌

5.3. Upstream Neighbor Address TLV 🦋

5.4. Downstream Neighbor Address TLV 🧚

6. Security Considerations 🛡️

7. IANA Considerations 📋

7.1. Proxy Echo Parameters Sub-TLVs 🧚

7.2. Proxy Flags 🦋

7.3. Downstream Address Mapping Registry 🌸

7.4. Next Hop Sub-TLV Address Type Registry 🍓

8. References 📚

8.1. Normative References 💜

8.2. Informative References 🦋

Acknowledgements 🎀

Authors' Addresses 💌