diff options
Diffstat (limited to 'doc/rfc/rfc7555.txt')
| -rw-r--r-- | doc/rfc/rfc7555.txt | 1571 |
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc7555.txt b/doc/rfc/rfc7555.txt new file mode 100644 index 0000000..cea33a1 --- /dev/null +++ b/doc/rfc/rfc7555.txt @@ -0,0 +1,1571 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Swallow +Request for Comments: 7555 V. Lim +Category: Standards Track Cisco Systems +ISSN: 2070-1721 S. Aldrin + Huawei Technologies + June 2015 + + + Proxy MPLS Echo Request + +Abstract + + This document defines a means of remotely initiating Multiprotocol + Label Switched Protocol (MPLS) Pings on Label Switched Paths. An + MPLS Proxy Ping Request is sent to any Label Switching Router along a + Label Switched Path. The primary motivations for this facility are + first to limit the number of messages and related processing when + using LSP Ping in large Point-to-Multipoint LSPs, and second to + enable tracing from leaf to leaf (or root). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7555. + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Swallow, et al. Standards Track [Page 1] + +RFC 7555 Proxy LSP Ping June 2015 + + +Table of Contents + + 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 + + + + + + + + + + + +Swallow, et al. Standards Track [Page 2] + +RFC 7555 Proxy LSP Ping June 2015 + + +1. Introduction + + This document is motivated by two broad issues in connection with + diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). + The first is scalability due to the automatic replication of + Multiprotocol Label Switching (MPLS) Echo Request messages as they + proceed down the tree. The second, which is primarily motivated by + LDP-based P2MP and Multipoint-to-Multipoint (MP2MP) LSPs [RFC6388], + is the ability to trace a sub-LSP from leaf node to root node. + + When tracing from a source to a particular leaf in a P2MP or MP2MP + tree, nodes not along that path will need to process MPLS Echo + Request messages that are received. The number of MPLS Echo Replies + sent in response to an MPLS Echo Request quickly multiplies, as the + Label Switching Routers (LSRs), which are part of the tree but not + along the path of the trace, could be responding to the received MPLS + Echo Request as well. This could also overwhelm the source to + process all the MPLS Echo Reply messages it receives. It is + anticipated that many of the applications for P2MP/MP2MP tunnels will + require OAM that is both rigorous and scalable. + + Suppose one wishes to trace a P2MP LSP to localize a fault that is + affecting one egress or a set of egresses. Suppose one follows the + normal procedure for tracing -- namely, repeatedly pinging from the + root, incrementing the Time to Live (TTL) by one after each three or + so pings. Such a procedure has the potential for producing a large + amount of processing at the P2MP-LSP midpoints and egresses. It also + could produce an unwieldy number of replies back to the root. + + One alternative would be to begin sending pings from points at or + near the affected egress(es) and then work backwards toward the root. + The TTL could be held constant (say, two), limiting the number of + responses to the number of next-next-hops of the point where a ping + is initiated. + + In the case of Resource Reservation Protocol Traffic Engineering + (RSVP-TE), all setup is initiated from the root of the tree. Thus, + the root of the tree has knowledge of all the leaf nodes and usually + the topology of the entire tree. Thus, the above alternative can + easily be initiated by the root node. + + In [RFC6388], the situation is quite different. Leaf nodes initiate + connectivity to the tree, which is granted by the first node toward + the root that is part of the tree. The root node may only be aware + of the immediately adjacent (downstream) nodes of the tree. + Initially, the leaf node only has knowledge of the (upstream) node to + which it is immediately adjacent. However, this is sufficient + information to initiate a trace. First, the above procedure is + + + +Swallow, et al. Standards Track [Page 3] + +RFC 7555 Proxy LSP Ping June 2015 + + + applied by asking that node to ping across the final link. That is, + a message is sent from the leaf to the upstream node requesting it to + send an MPLS Echo Request for the Forward Equivalence Class (FEC) of + the tree in question on said link. The leaf node also requests the + identity of the upstream neighbor's upstream neighbor for that FEC. + With this information, the procedure can iteratively be applied until + the fault is localized or the root node is reached. In all cases, + the TTL for the request need only be at most 2. Thus, the processing + load of each request is small, since only a limited number of nodes + will receive the request. + + This document defines protocol extensions to MPLS ping [RFC4379] to + allow a third party to remotely cause an MPLS Echo Request message to + be sent down an LSP or part of an LSP. The procedure described in + the paragraphs above does require that the initiator know the + previous-hop node to the one which was pinged on the prior iteration. + This information is readily available in [RFC4875]. This document + also provides a means for obtaining this information for P2MP and + MP2MP LSPs that are set up with LDP as described in [RFC6388]. + + While the motivation for this document came from multicast scaling + concerns, its applicability may be wider. The procedures presented + in this document are applicable 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 involves the use of in-band control channels is beyond the scope + of this document. + + Other uses of this facility are beyond the scope of this document. + In particular, the procedures defined in this document only allow + testing of a FEC stack consisting of a single FEC. The procedures + also do not allow the initiator to specify the label assigned to that + FEC, nor do the procedures allow the initiator to cause any + additional labels to be added to the label stack of the actual MPLS + Echo Request message. + +1.1. Requirements Language + + 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) is used in TLV descriptions for + reserved fields. These fields MUST be set to zero when sent and + ignored on receipt. + + + + + + +Swallow, et al. Standards Track [Page 4] + +RFC 7555 Proxy LSP Ping June 2015 + + + Based on context, the terms "leaf" and "egress" are used + interchangeably. "Egress" is used where consistency with [RFC4379] + was deemed appropriate. "Receiver" is used in the context of + receiving protocol messages. + +1.2. Terminology + + 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 + +2. Proxy Ping Overview + + This document defines a protocol interaction between a first LSR and + another LSR that is part of an LSP in order to allow the first LSR to + request that the second LSR initiate an LSP Ping for the LSP on the + first LSR's behalf. Since the second LSR sends the LSP Ping on + behalf of the first LSR, it does not maintain state to be able to + handle the corresponding LSP Ping response. Instead, the responder + to the LSP Ping sends the LSP Ping response to either the first LSR + or another LSR configured to handle it. Two new LSP Ping messages + are defined for remote pinging: the MPLS Proxy Ping Request and the + MPLS Proxy Ping Reply. + + A remote ping operation on a P2MP LSP generally involves at least + three LSRs; in some scenarios, none of these are the ingress (root) + or an egress (leaf) of the LSP. + + We refer to these LSRs with the following terms: + + Initiator - the LSR that initiates 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 + + + +Swallow, et al. Standards Track [Page 5] + +RFC 7555 Proxy LSP Ping June 2015 + + + We note that in some scenarios, the initiator could also be the + responder; in that case, the response would be internal to the LSR. + +2.1. Initiating Proxy Ping + + The initiator formats an MPLS Proxy Ping Request message and sends it + to the Proxy LSR, an LSR it believes to be on the path of the LSP. + This message instructs the Proxy LSR either to reply with Proxy + information or to send an MPLS Echo Request in-band of the LSP. The + initiator requests Proxy information so that it can learn additional + information it needs to use to form a subsequent 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 that it can form Proxy Ping Requests to various LSRs + along the LSP. + +2.2. Handling at Proxy LSR + + The Proxy LSR either replies with the requested Proxy information or + validates that it has a label mapping for the specified FEC and that + it is 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 all + authorization checks have passed, the Proxy LSR formats an MPLS Echo + Request. If the source address of the MPLS Echo Request is not 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. It then sends the MPLS Echo Request in-band of the + LSP. + + The receivers process the MPLS Echo Request as normal, sending their + MPLS Echo Replies back to the initiator. + + If the Proxy LSR failed to send an MPLS Echo Request as normal + because it encountered an issue while attempting to send, an MPLS + Proxy Ping Reply message is sent back with a Return Code indicating + 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 to zero. + If there are any TLVs not marked as "Ignore" that the Proxy LSR does + not understand, the Proxy LSR SHOULD send an MPLS "TLV not + understood" (as appropriate), and the Return Subcode is set to zero. + + + +Swallow, et al. Standards Track [Page 6] + +RFC 7555 Proxy LSP Ping June 2015 + + + In the case where the targeted Proxy LSR does not understand the LSP + Ping Echo Request at all, like any other LSR that does not understand + the messages, it MUST drop the message and MUST NOT send any message + back to the initiator. + +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 to be used + by the Proxy LSR 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 is + from the range 127/8; if the Address Type is IPv6, 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 with one of the Reply Modes + defined in [RFC4379] as appropriate. + + + + + + +Swallow, et al. Standards Track [Page 7] + +RFC 7555 Proxy LSP Ping June 2015 + + + 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 not 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. + + Any of 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; 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; the destination IP address is a routable address to the + Proxy LSR. The packet is then sent with the IP TTL set to 255. + + + + + + + + + +Swallow, et al. Standards Track [Page 8] + +RFC 7555 Proxy LSP Ping June 2015 + + +3.2. Procedures for the Proxy LSR + + A Proxy LSR that receives an MPLS Proxy Ping Request message parses + the packet to ensure that it is a well-formed packet. It checks that + the TLVs that are not marked "Ignore" are understood. If any part of + the message is malformed, it sets the Return Code to "Malformed echo + request received". If all the TLVs are well-formed and any TLVs are + not understood, the Return Code is set to "TLV not understood". The + Return Subcode is set to zero for both cases. + + If the Reply Mode of the message header is not 1 ("Do not reply"), an + MPLS Proxy Ping Reply message SHOULD be sent as described below. + + If the Return Code is "TLV not understood", no more processing of the + MPLS Proxy Ping Request message is required. The Proxy LSR sends an + MPLS Proxy Ping Reply message with an Errored TLVs TLV containing + (only) the TLVs that were not understood. + + The MPLS Proxy Ping Request is expected to be transported to the + Proxy LSR via IP forwarding mechanisms instead of using the same + techniques that are employed to inject an MPLS Echo Request packet + into an LSP. The MPLS Echo Request would use 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 to trigger the packet to be + handled via an LSR's forwarding exception processing path. The Proxy + LSR MUST check whether or not MPLS Proxy Ping Request packets arrive + via exception path. Packets arriving via IP TTL expiry, IP + destination address set to a loopback address, or label TTL expiry + MUST be treated as "Unauthorized" packets. An MPLS Proxy Ping Reply + message MAY be sent with a Return Code of 16, "Proxy Ping not + authorized". + + The header fields Sender's Handle and Sequence Number are not + examined, but they are included in the MPLS Proxy Ping Reply or MPLS + Echo Request message, if either is sent as a direct result of the + received message. + + The Proxy LSR validates that it has a label mapping for the specified + FEC, determines if it is an ingress, egress, transit or bud node, and + then sets the Return Code as appropriate. A new Return Code of 19, + "Replying router has FEC mapping for topmost FEC", has been defined + for the case where the Proxy LSR is an ingress (for example, the head + of the TE tunnel or a transit router) because the existing Return + Codes defined by RFC 4379 don't match the situation. For example, + when a Proxy LSR is a transit router, it's not appropriate for the + Return Code to describe how the packet would transit because the MPLS + + + + + +Swallow, et al. Standards Track [Page 9] + +RFC 7555 Proxy LSP Ping June 2015 + + + Proxy Ping Request doesn't contain information about what input + interface the MPLS Echo Request would be switched from at the Proxy + LSR. + + The Proxy LSR then determines if it is 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 does not pass the + filter, then an MPLS Echo Request message MUST NOT be sent, and the + event SHOULD be logged. An MPLS Proxy Ping Reply message MAY be sent + with a Return Code of 16, "Proxy Ping not authorized". + + The destination address specified in the Proxy Echo Parameters TLV is + checked to ensure that it conforms to the allowed IPv4 or IPv6 + address range. If not, the Return Code is set to "Malformed echo + request received" and the Return Subcode is set to zero. If the + Reply Mode of the message header is not 1, an MPLS Proxy Ping Reply + message SHOULD be sent as described below. + + The TTL specified in the Proxy Echo Parameters TLV is checked to + ensure it contains a value in the range [1,255]. If not, the Return + Code MUST be set to 17, "Proxy Ping parameters need to be modified". + If the Reply Mode of the message header is not 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 are + formatted for inclusion in the MPLS Proxy Ping reply. If the + Upstream or Downstream address is unknown, the corresponding TLV is + omitted. + + If there are Next Hop sub-TLVs in the Proxy Echo Parameters TLV, each + address is examined to determine if it is a valid next hop for this + FEC. If any are not, the Proxy Echo Parameters TLV SHOULD be updated + to remove 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 (for inclusion + in the MPLS Proxy Ping Reply) a DS/DDMAP TLV for each interface over + which the MPLS Echo Request will be sent. + + If the Proxy LSR is the egress for the FEC, the behavior of the Proxy + LSR varies depending on whether the LSR is an egress of a P2P LSP, a + P2MP LSP, or MP2MP LSP. Additional details can be found in Section + 3.2.1, "Proxy LSR Handling When It Is Egress for FEC". + + + + +Swallow, et al. Standards Track [Page 10] + +RFC 7555 Proxy LSP Ping June 2015 + + + 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 describes the different behaviors for the Proxy LSR when + it's the egress for the FEC. In the P2MP bud node and MP2MP bud node + egress cases, different behavior is required. + + In the case where an MPLS Echo Request is originated by an LSR that + is a bud or egress node of a P2MP/MP2MP, MPLS Echo Replies are + returned from downstream/upstream LSRs and will not include an MPLS + Echo Reply from the LSR that originated the MPLS Echo Request. This + section describes the behavior required at a bud or egress node to + return or not return information from MPLS Echo Replies in the Proxy + Echo Reply so that no changes are required in implementations that + are compliant with [RFC4379]. The Proxy Initiator should receive the + same MPLS Echo Replies as in the case of the originator of the LSP + Ping; any additional information (such as 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", with + 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 the Proxy LSR is 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 included only if the + Proxy Initiator requested information be returned in an MPLS Proxy + Ping Reply. If the Proxy LSR is a bud node but there has not been a + request to return an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send + MPLS Echo Request packet(s) to the downstream neighbors (no MPLS Echo + Reply is sent to the Proxy Initiator to indicate that 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 + have different behavior in this case. MPLS Echo Requests are sent to + all upstream/downstream neighbors. The Proxy LSRs need to be + consistent with this variation in behavior. If the Proxy LSR is a + + + +Swallow, et al. Standards Track [Page 11] + +RFC 7555 Proxy LSP Ping June 2015 + + + 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 included only if the Proxy Initiator + requested information be returned in an MPLS Proxy Ping Reply. If + the Proxy LSR is not requested to return information in an MPLS Proxy + Ping Reply, the Proxy LSR SHOULD send MPLS Echo Request packets to + all upstream/downstream neighbors as would be done when sourcing an + LSP Ping from a MP2MP leaf (no MPLS Echo Reply is sent to the Proxy + Initiator indicating that 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 + corresponding to how the packet is transited cannot be supplied + unless an ingress interface for the MPLS Echo Request is specified. + Since this information is not available and all valid output paths + are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) to describe + the entire set of paths that the packet can be replicated. This is + similar to the case in which an LSP Ping is initiated at the Proxy + LSR. For mLDP, there is 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 + source packets only to the neighbors but not itself, despite the fact + that the Proxy LSR is itself an egress for the FEC. In order to + match the behavior as seen from LSP Ping initiated at the Proxy LSR, + the Proxy Reply SHOULD contain DS/DDMAPs for only the paths to the + upstream/downstream neighbors, but no DS/DDMAP describing its own + egress paths. The proxy LSR identifies that it's an egress for the + FEC using a different Proxy Reply Return Code. The Proxy Reply + Return Code is either set to 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 + are included. The message is encapsulated in a UDP packet. The + source IP address is a routable address of the Proxy LSR; 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. The IP TTL is set to 255. + + + + + + +Swallow, et al. Standards Track [Page 12] + +RFC 7555 Proxy LSP Ping June 2015 + + +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 + + If Next Hop sub-TLVs were included in the received Proxy Echo + Parameters TLV, the Next_Hop_List is created from the addresses in + those sub-TLVs adjusted as described in Section 3.2. Otherwise, the + list is set to all the next hops to which the FEC would be forwarded. + + The Proxy LSR then formats an MPLS Echo Request message. The Global + Flags and Reply Mode are copied from the Proxy Echo Parameters TLV. + 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) that the MPLS Echo Request is sent. The TimeStamp + Received is set to zero. + + If the Reply-to Address TLV is present, it is used to set the MPLS + Echo Request source address; otherwise, the MPLS Echo Request source + address is set to the Proxy Request source address. + + The following TLVs are copied from the MPLS Proxy Ping Request + message. Note that, of these, only the Target FEC Stack is REQUIRED + to appear in the MPLS Proxy Ping Request message. The Pad TLV is not + copied if the Proxy Echo Parameter TLV MPLS payload size is set to a + non-zero value. + + Target FEC Stack + + Pad + + Vendor Enterprise Number + + Reply TOS Byte + + P2MP Responder Identifier [RFC6425] + + Echo Jitter [RFC6425] + + Vendor Private TLVs + + + + +Swallow, et al. Standards Track [Page 13] + +RFC 7555 Proxy LSP Ping June 2015 + + + If the Proxy Echo Parameter TLV MPLS payload size is non-zero, the + Proxy LSR introduces a Pad TLV such that size of the MPLS Echo + Request (including any IP and UDP header) is zero-padded to the + specified MPLS payload size. The first octet in the Value part of + the Pad TLV is set to 1, "Drop Pad TLV from reply", and the remaining + octets of the Value part of the Pad TLV are filled with zeros. If + the IP header is used to encapsulate the MPLS Echo Request, the DF + bit MUST be set to one. + + The message is then encapsulated in a UDP packet. The source UDP + port is copied from the Proxy Echo Parameters TLV. The destination + port is copied from the MPLS Proxy Ping Request message. + + The source IP address is set to a routable address specified in the + Reply-to Address TLV or the source address of the received Proxy + Request. Per 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 is examined. If the setting is + permitted, then the DSCP byte of the IP header of the MPLS Echo + Request message is set to that value. If the Proxy LSR does not + permit explicit control for the DSCP byte, the MPLS Proxy Echo + Parameters with the Explicit DSCP flag cleared MUST be included in + any MPLS Proxy Ping Reply message to indicate why an MPLS Echo + Request was not sent. The Return Code MUST be set to 17, "Proxy Ping + parameters need to be modified". If the Explicit DSCP flag is not + 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 iterates through the Next_Hop_List modifying the + base MPLS Echo Request to form the MPLS Echo Request packet that is + then sent on that particular interface. + + The outgoing label stack is determined for each next-hop address. + The TTL for the label corresponding to the FEC specified in the FEC + stack is set such that the TTL on the wire will be the TTL specified + in the Proxy Echo Parameters. If any additional labels are pushed + onto the stack, their TTLs are set to 255. This will ensure that the + requestor will not have control over tunnels not relevant to the FEC + being tested. + + + + + + + + + +Swallow, et al. Standards Track [Page 14] + +RFC 7555 Proxy LSP Ping June 2015 + + + If the MPLS Proxy Ping Request message contained Downstream Mapping + TLVs or Downstream Detailed Mapping TLVs, they are examined. If the + Downstream IP address matches the next-hop address, that Downstream + Mapping TLV is included in the MPLS Echo Request. + + The packet is then transmitted on this interface. + +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 as 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 + + + + +Swallow, et al. Standards Track [Page 15] + +RFC 7555 Proxy LSP Ping June 2015 + + +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 + + The Proxy Echo Parameters TLV is a TLV that MUST be included in an + MPLS Proxy Ping Request message. The length of the TLV 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. The Proxy Echo Parameters TLV can + be used either to 1) control attributes used in composing and sending + an MPLS Echo Request or 2) query the Proxy LSR for information about + the topmost FEC in the target FEC stack, but not both. In the case + where the Proxy LSR is being queried (i.e., information needs to be + returned in an MPLS Proxy Ping Reply), no MPLS Echo Request will be + sent from the Proxy LSR. The MPLS Proxy Ping Request Proxy Echo + Parameters TLV's Proxy Flags SHOULD be set appropriately, as + described below. + + + + + + + + + + + + + + + + +Swallow, et al. Standards Track [Page 16] + +RFC 7555 Proxy LSP Ping June 2015 + + + 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 + + The type and length of the address found in the 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 applicable in this case appear in the table below: + + Address Family Type Length + + IPv4 1 4 + IPv6 3 16 + + Reply Mode + + 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 set, this requests that the Proxy LSR supply the + Upstream and Downstream neighbor address information in the + MPLS Proxy Ping Reply message. This flag is only applicable + + + +Swallow, et al. Standards Track [Page 17] + +RFC 7555 Proxy LSP Ping June 2015 + + + for 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. Similarly, + one Downstream Neighbor Address TLV needs to be included for + each Downstream Neighbor from which the LSR learned + bindings. + + Setting this flag will cause the Proxy LSR to cancel sending + any MPLS Echo Request. The initiator may use information + learned from the MPLS Proxy Ping Reply that is sent instead + to generate subsequent proxy requests. + + 0x0002 Request for Downstream Mapping + + When set, this requests that the Proxy LSR 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 will cause the Proxy LSR to cancel sending + an MPLS Echo Request. Information learned with such a Proxy + Reply may be used by the Proxy Initiator to generate + subsequent Proxy Requests. + + 0x0004 Request for Downstream Detailed Mapping + + When set, this requests that the Proxy LSR 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 will cause the Proxy LSR to cancel + sending an MPLS Echo Request. The initiator may use + information learned from the MPLS Proxy Ping Reply that is + sent instead to generate subsequent proxy requests. + + 0x0008 Explicit DSCP Request + + When set, this requests that the Proxy LSR use the supplied + "Rqst'd DSCP" byte in the Echo Request message + + + + + + + + +Swallow, et al. Standards Track [Page 18] + +RFC 7555 Proxy LSP Ping June 2015 + + + TTL + + 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 valid only if the Explicit DSCP flag is set. If + not set, the field MUST be zero on transmission and ignored on + receipt. When the flag is set, this field contains the DSCP + value to be used in the MPLS Echo Request packet IP header. + + Source UDP Port + + The source UDP port to be sent in the MPLS Echo Request packet + + Global Flags + + The Global Flags to be sent in the MPLS Echo Request message + + MPLS Payload Size + + 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 total the + specified size. Having the field set to zero means no size + request is being made. If the requested size is less than the + minimum size required to form the MPLS Echo Request, the + request will be treated as a best-effort request with the Proxy + LSR building the smallest possible packet (i.e., 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, an address from the range 127/8; + if the Address Type is IPv6, an address from the range + ::ffff:7f00:0/104 + + Sub-TLVs + + List of TLV-encoded sub-TLVs. Currently one is defined. + + Sub-Type Length Sub-TLV Name + -------- ------ ------------ + 1 8+ Next Hop + + + + +Swallow, et al. Standards Track [Page 19] + +RFC 7555 Proxy LSP Ping June 2015 + + +5.1.1. Next Hop Sub-TLV + + This sub-TLV is used to describe a particular next hop towards which + the Echo Request packet should be sent. If the topmost FEC in the + FEC stack is a multipoint LSP, this sub-TLV may appear 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 correspond to the types in the DSMAP TLV. + They are expected to be populated with information + obtained through a previously returned DSMAP TLV. Types + 6 and 7 are intended to be populated from the local + address information obtained from a previously returned + Downstream Neighbor Address TLV or Upstream Neighbor + Address TLV. + + Next Hop IP Address + + A next hop address that the Echo Request message is to be sent + towards + + Next Hop Interface + + Identifier of the interface through which the Echo Request + message is to be sent. 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. + + + +Swallow, et al. Standards Track [Page 20] + +RFC 7555 Proxy LSP Ping June 2015 + + +5.2. Reply-to Address TLV + + 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 + + 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; Local Addr Type + + These two fields determine the type and length of the + respective addresses. The codes are specified in the table + below: + + + + + +Swallow, et al. Standards Track [Page 21] + +RFC 7555 Proxy LSP Ping June 2015 + + + Type Type of Address Length + + 0 No Address Supplied 0 + 1 IPv4 4 + 3 IPv6 16 + + Upstream Address + + The address of the immediate upstream neighbor for the topmost + FEC in the FEC stack. 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. + + Local Address + + The local address used in the protocol adjacency by which the + label for this FEC was exchanged. + +5.4. Downstream Neighbor Address TLV + + 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; Local Addr Type + + These two fields determine the type and length of the + respective addresses. The codes are specified in the table + below: + + Type Type of Address Length + + 0 No Address Supplied 0 + 1 IPv4 4 + 3 IPv6 16 + + + + + + +Swallow, et al. Standards Track [Page 22] + +RFC 7555 Proxy LSP Ping June 2015 + + + Downstream Address + + The address of an immediate downstream neighbor for the topmost + FEC in the FEC stack. 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. + + Local Address + + The local address used in the protocol adjacency by which the + label for this FEC was exchanged. + +6. Security Considerations + + The mechanisms described in this document are intended to be used + within a service provider network and to be initiated only under the + authority of that administration. + + If such a network also carries Internet traffic, or permits IP access + from other administrations, the MPLS Proxy Ping message SHOULD be + discarded at the points where IP packets are received from other + administrations. This can be accomplished by filtering on source + address or by filtering all MPLS ping messages on UDP port. + + 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. + + MPLS Proxy Ping Request messages are IP addressed directly to the + Proxy LSR. 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. + + If an MPLS Proxy Ping Request IP source address is not IP reachable + by the Proxy LSR, the Proxy Request MUST NOT be acted upon. + + MPLS Proxy Ping Requests are limited to making their request via the + specification of a FEC. This ensures that only valid MPLS Echo + Request messages can be created. No label-spoofing attacks are + possible. + + + + + + + + + + + +Swallow, et al. Standards Track [Page 23] + +RFC 7555 Proxy LSP Ping June 2015 + + +7. IANA Considerations + + Per this document, IANA has made the following assignments. + + MPLS LSP Ping Message Types + + Value Meaning + ----- ------- + 3 MPLS Proxy Ping Request + 4 MPLS Proxy Ping Reply + + TLVs + + Type TLV Name + ---- -------- + 23 Proxy Echo Parameters + 24 Reply-to Address + 25 Upstream Neighbor Address + 26 Downstream Neighbor Address + + + Return Codes + + Value Meaning + ----- ------- + 16 Proxy Ping not authorized + 17 Proxy Ping parameters need to be modified + 18 MPLS Echo Request could not be sent + 19 Replying router has FEC mapping for topmost FEC + +7.1. Proxy Echo Parameters Sub-TLVs + + The IANA has created and maintains this new registry for Proxy Echo + Parameters Sub-TLVs. Assignments will use the same rules spelled out + in Section 7.2 of [RFC4379]. + + Sub-Type Sub-TLV Name + -------- ------------ + 0 Reserved + 1 Next Hop + + + + + + + + + + + +Swallow, et al. Standards Track [Page 24] + +RFC 7555 Proxy LSP Ping June 2015 + + +7.2. Proxy Flags + + IANA has created and maintains a new registry for the Proxy Flags + that are used with the Proxy Echo Parameters TLV. See Section 5.1 + for details. The registry is in the "Multi-Protocol Label Switching + (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the + "Multiprotocol Label Switching Architecture (MPLS)" name space. The + registration procedure is Standards Action [RFC5226]. The initial + values are as follows. + + 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 makes the following assignments in the Downstream + Address Mapping Registry. This document updates the registry defined + by [RFC6426]. The registration procedure remains Standards Action + and a note has been added as follows: + + 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". + + 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 has created a new registry called the "Next Hop Address Type + Registry". The allocation policy for this registry is Standards + Action. Further, a note has been added as follows: + + 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". + + + + + + + + +Swallow, et al. Standards Track [Page 25] + +RFC 7555 Proxy LSP Ping June 2015 + + + 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>. + + + + +Swallow, et al. Standards Track [Page 26] + +RFC 7555 Proxy LSP Ping June 2015 + + +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 + + The authors would like to thank Nobo Akiya, Adrian Farrel, Tom Yu, + Tom Taylor, and Warren Kumari for their detailed reviews and + insightful comments. + + + + + + + + + + + + + + + + + + + + + + + + + + +Swallow, et al. Standards Track [Page 27] + +RFC 7555 Proxy LSP Ping June 2015 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + +Swallow, et al. Standards Track [Page 28] + |