doc: Add RFC documents

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]
+