draft-ietf-mpls-proxy-lsp-ping-05.txt   rfc7555.txt 
Network Working Group G. Swallow Internet Engineering Task Force (IETF) G. Swallow
Internet-Draft V. Lim Request for Comments: 7555 V. Lim
Intended status: Standards Track Cisco Systems Category: Standards Track Cisco Systems
Expires: September 26, 2015 S. Aldrin ISSN: 2070-1721 S. Aldrin
Huawei Technologies Huawei Technologies
March 25, 2015 June 2015
Proxy MPLS Echo Request Proxy MPLS Echo Request
draft-ietf-mpls-proxy-lsp-ping-05
Abstract Abstract
This document defines a means of remotely initiating Multiprotocol This document defines a means of remotely initiating Multiprotocol
Label Switched Protocol Pings on Label Switched Paths. An MPLS Proxy Label Switched Protocol (MPLS) Pings on Label Switched Paths. An
Ping Request is sent to any Label Switching Router along a Label MPLS Proxy Ping Request is sent to any Label Switching Router along a
Switched Path. The primary motivations for this facility are first to Label Switched Path. The primary motivations for this facility are
limit the number of messages and related processing when using LSP first to limit the number of messages and related processing when
Ping in large Point-to-Multipoint LSPs, and second to enable leaf to using LSP Ping in large Point-to-Multipoint LSPs, and second to
leaf/root tracing. enable tracing from leaf to leaf (or root).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (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.
This Internet-Draft will expire on September 26, 2015. 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language ......................................4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology ................................................5
2. Proxy Ping Overview . . . . . . . . . . . . . . . . . . . . . 5 2. Proxy Ping Overview .............................................5
2.1. Initiating Proxy Ping . . . . . . . . . . . . . . . . . . 6 2.1. Initiating Proxy Ping ......................................6
2.2. Handling at Proxy LSR . . . . . . . . . . . . . . . . . . 6 2.2. Handling at Proxy LSR ......................................6
2.2.1. Backward Compatibility . . . . . . . . . . . . . . . . 6 2.2.1. Backward Compatibility ..............................6
3. Proxy MPLS Echo Request / Reply Procedures . . . . . . . . . . 7 3. Proxy MPLS Echo Request/Reply Procedures ........................7
3.1. Procedures for the initiator . . . . . . . . . . . . . . . 7 3.1. Procedures for the Initiator ...............................7
3.2. Procedures for the Proxy LSR . . . . . . . . . . . . . . . 8 3.2. Procedures for the Proxy LSR ...............................9
3.2.1. Proxy LSR Handling when it is egress for FEC . . . . . 10 3.2.1. Proxy LSR Handling When It Is Egress for FEC .......11
3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply . . 11 3.2.2. Downstream Detailed Maps and Downstream
3.2.3. Sending an MPLS Proxy Ping Reply . . . . . . . . . . . 12 Maps in Proxy Reply ................................12
3.2.4. Sending the MPLS Echo Requests . . . . . . . . . . . . 12 3.2.3. Sending an MPLS Proxy Ping Reply ...................12
3.2.4.1. Forming the base MPLS Echo Request . . . . . . . . 12 3.2.4. Sending the MPLS Echo Requests .....................13
3.2.4.2. Per interface sending procedures . . . . . . . . . 14 3.2.4.1. Forming the Base MPLS Echo Request ........13
4. Proxy Ping Request / Reply Messages . . . . . . . . . . . . . 14 3.2.4.2. Per-Interface Sending Procedures ..........14
4.1. Proxy Ping Request / Reply Message formats . . . . . . . . 14 4. Proxy Ping Request/Reply Messages ..............................15
4.2. Proxy Ping Request Message contents . . . . . . . . . . . 15 4.1. Proxy Ping Request/Reply Message Formats ..................15
4.3. Proxy Ping Reply Message Contents . . . . . . . . . . . . 15 4.2. Proxy Ping Request Message Contents .......................15
5. TLV formats . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Proxy Ping Reply Message Contents .........................16
5.1. Proxy Echo Parameters TLV . . . . . . . . . . . . . . . . 16 5. TLV Formats ....................................................16
5.1.1. Next Hop sub-TLV . . . . . . . . . . . . . . . . . . . 19 5.1. Proxy Echo Parameters TLV .................................16
5.2. Reply-to Address TLV . . . . . . . . . . . . . . . . . . . 20 5.1.1. Next Hop Sub-TLV ...................................20
5.3. Upstream Neighbor Address TLV . . . . . . . . . . . . . . 20 5.2. Reply-to Address TLV ......................................21
5.4. Downstream Neighbor Address TLV . . . . . . . . . . . . . 21 5.3. Upstream Neighbor Address TLV .............................21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5.4. Downstream Neighbor Address TLV ...........................22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations ........................................23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations ............................................24
8.1. Proxy Echo Parameters Sub-TLVs . . . . . . . . . . . . . . 23 7.1. Proxy Echo Parameters Sub-TLVs ............................24
8.2. Downstream Address Mapping Registry [pending IANA 7.2. Proxy Flags ...............................................25
assignment] . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Downstream Address Mapping Registry .......................25
8.3. Next Hop Sub-TLV Address Type Registry . . . . . . . . . . 24 7.4. Next Hop Sub-TLV Address Type Registry ....................25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References .....................................................26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References ......................................26
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 8.2. Informative References ....................................27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgements ..................................................27
Authors' Addresses ................................................28
1. Introduction 1. Introduction
This document is motivated by two broad issues in connection with This document is motivated by two broad issues in connection with
diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs).
The first is scalability due to the automatic replication of The first is scalability due to the automatic replication of
Multiprotocol Label Switching (MPLS) Echo Request Messages as they Multiprotocol Label Switching (MPLS) Echo Request messages as they
proceed down the tree. The second, which is primarily motivated by proceed down the tree. The second, which is primarily motivated by
Label Distribution Protocol based Point-to-Multipoint (P2MP) and LDP-based P2MP and Multipoint-to-Multipoint (MP2MP) LSPs [RFC6388],
Multipoint-to-Multipoint (MP2MP) Label Switched Paths [RFC6388], is is the ability to trace a sub-LSP from leaf node to root node.
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 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 tree, nodes not along that path will need to process MPLS Echo
Request messages that are received. The number of MPLS Echo Replies Request messages that are received. The number of MPLS Echo Replies
sent in response to an MPLS Echo Request quickly multiplies, as the sent in response to an MPLS Echo Request quickly multiplies, as the
Label Switching Routers (LSRs), which are part of the tree but not 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 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 Echo Request as well. This could also overwhelm the source to
all the MPLS Echo Reply messages it receives. It is anticipated that process all the MPLS Echo Reply messages it receives. It is
many of the applications for P2MP/MP2MP tunnels will require OAM that anticipated that many of the applications for P2MP/MP2MP tunnels will
is both rigorous and scalable. require OAM that is both rigorous and scalable.
Suppose one wishes to trace a P2MP LSP to localize a fault which is 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 affecting one egress or a set of egresses. Suppose one follows the
normal procedure for tracing - namely repeatedly pinging from the normal procedure for tracing -- namely, repeatedly pinging from the
root, incrementing the Time to Live (TTL) by one after each three or 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 so pings. Such a procedure has the potential for producing a large
amount of processing at the P2MP-LSP midpoints and egresses. It also amount of processing at the P2MP-LSP midpoints and egresses. It also
could produce an unwieldy number of replies back to the root. could produce an unwieldy number of replies back to the root.
One alternative would be to begin sending pings from points at or One alternative would be to begin sending pings from points at or
near the affected egress(es) and then working backwards toward the near the affected egress(es) and then work backwards toward the root.
root. The TTL could be held constant, say two, limiting the number of 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 responses to the number of next-next-hops of the point where a ping
is initiated. is initiated.
In the case of Resource Reservation Protocol-Traffic Engineering In the case of Resource Reservation Protocol Traffic Engineering
(RSVP-TE), all setup is initiated from the root of the tree. Thus, (RSVP-TE), all setup is initiated from the root of the tree. Thus,
the root of the tree has knowledge of both all the leaf nodes and the root of the tree has knowledge of all the leaf nodes and usually
usually the topology of the entire tree. Thus the above alternative the topology of the entire tree. Thus, the above alternative can
can easily be initiated by the root node. easily be initiated by the root node.
In [RFC6388] the situation is quite different. Leaf nodes initiate In [RFC6388], the situation is quite different. Leaf nodes initiate
connectivity to the tree, which is granted by the first node toward 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 root that is part of the tree. The root node may only be aware
the immediately adjacent (downstream) nodes of the tree. Initially of the immediately adjacent (downstream) nodes of the tree.
the leaf node only has knowledge of the (upstream) node to which it Initially, the leaf node only has knowledge of the (upstream) node to
is immediately adjacent. However this is sufficient information to which it is immediately adjacent. However, this is sufficient
initiate a trace. First the above procedure is applied by asking that information to initiate a trace. First, the above procedure is
node to ping across the final link. That is, a message is sent from applied by asking that node to ping across the final link. That is,
the leaf to the upstream node requesting it to send an MPLS Echo a message is sent from the leaf to the upstream node requesting it to
Request for the Forward Equivalence Class (FEC) of the tree in send an MPLS Echo Request for the Forward Equivalence Class (FEC) of
question on said link. The leaf node also requests the identity of the tree in question on said link. The leaf node also requests the
the upstream neighbor's upstream neighbor for that FEC. With this identity of the upstream neighbor's upstream neighbor for that FEC.
information, the procedure can iteratively be applied until the fault With this information, the procedure can iteratively be applied until
is localized or the root node is reached. In all cases, the TTL for the fault is localized or the root node is reached. In all cases,
the request need only be at most 2. Thus the processing load of each the TTL for the request need only be at most 2. Thus, the processing
request is small, since only a limited number of nodes will receive load of each request is small, since only a limited number of nodes
the request. will receive the request.
This document defines protocol extensions to MPLS ping [RFC4379] to This document defines protocol extensions to MPLS ping [RFC4379] to
allow a third party to remotely cause an MPLS Echo Request message 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 be sent down an LSP or part of an LSP. The procedure described in
paragraphs above does require that the initiator know the previous- the paragraphs above does require that the initiator know the
hop node to the one which was pinged on the prior iteration. This previous-hop node to the one which was pinged on the prior iteration.
information is readily available in [RFC4875]. This document also This information is readily available in [RFC4875]. This document
provides a means for obtaining this information for [RFC6388]. 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 While the motivation for this document came from multicast scaling
concerns, it's applicability may be wider. The procedures presented concerns, its applicability may be wider. The procedures presented
in this document are applicable to all LSP ping FEC types where the 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 MPLS Echo Request/Reply are IP encapsulated and the MPLS Echo Reply
can sent out of band of the LSP over IP. Remote pinging of LSPs that can be sent out of band of the LSP over IP. Remote pinging of LSPs
involve the use of in-band control channels is beyond the scope of that involves the use of in-band control channels is beyond the scope
this document. of this document.
Other uses of this facility are beyond the scope of this document. In Other uses of this facility are beyond the scope of this document.
particular, the procedures defined in this document only allow In particular, the procedures defined in this document only allow
testing of a FEC stack consisting of a single FEC. The procedures 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 also do not allow the initiator to specify the label assigned to that
FEC, nor does it allow the initiator to cause any additional labels FEC, nor do the procedures allow the initiator to cause any
to be added to the label stack of the actual MPLS Echo Request additional labels to be added to the label stack of the actual MPLS
message. Echo Request message.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The term "Must Be Zero" (MBZ) is used in TLV descriptions for The term "Must Be Zero" (MBZ) is used in TLV descriptions for
reserved fields. These fields MUST be set to zero when sent and reserved fields. These fields MUST be set to zero when sent and
ignored on receipt. ignored on receipt.
Based on context the terms leaf and egress are used interchangeably. Based on context, the terms "leaf" and "egress" are used
Egress is used where consistency with[RFC4379] was deemed interchangeably. "Egress" is used where consistency with [RFC4379]
appropriate. Receiver is used in the context of receiving protocol was deemed appropriate. "Receiver" is used in the context of
messages. receiving protocol messages.
1.2. Terminology 1.2. Terminology
Term Definition Term Definition
----- ------------------------------------------- ----- -------------------------------------------
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
mLDP Multipoint LDP mLDP Multipoint LDP
MP2MP Multipoint to Multipoint MP2MP Multipoint to Multipoint
MTU Maximum Transmission Unit MTU Maximum Transmission Unit
P2MP Point to Multipoint P2MP Point to Multipoint
TTL Time to Live TTL Time to Live
2. Proxy Ping Overview 2. Proxy Ping Overview
This document defines a protocol interaction between a first LSR, an This document defines a protocol interaction between a first LSR and
LSR which is part of an LSP, to allow the first LSR to request that another LSR that is part of an LSP in order to allow the first LSR to
the second LSR initiate an LSP ping for the LSP on the first LSR's request that the second LSR initiate an LSP Ping for the LSP on the
behalf. Since the second LSR sends the LSP Ping on behalf of the first LSR's behalf. Since the second LSR sends the LSP Ping on
first LSR, it does not maintain state to be able to handle the behalf of the first LSR, it does not maintain state to be able to
corresponding LSP Ping response. Instead the responder to the LSP handle the corresponding LSP Ping response. Instead, the responder
ping sends the LSP Ping response to either the first LSR or another to the LSP Ping sends the LSP Ping response to either the first LSR
LSR configured to handle it. Two new LSP Ping messages are defined or another LSR configured to handle it. Two new LSP Ping messages
for remote pinging: the MPLS Proxy Ping Request and the MPLS Proxy are defined for remote pinging: the MPLS Proxy Ping Request and the
Ping Reply. MPLS Proxy Ping Reply.
A remote ping operation on a P2MP LSP generally involves at least 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 three LSRs; in some scenarios, none of these are the ingress (root)
an egress (leaf) of the LSP. or an egress (leaf) of the LSP.
We refer to these LSRs with the following terms: We refer to these LSRs with the following terms:
Initiator - the LSR which initiates the ping operation by sending Initiator - the LSR that initiates the ping operation by sending
an MPLS Proxy Ping Request message an MPLS Proxy Ping Request message
Proxy LSR - the LSR which is the destination of the MPLS Proxy Proxy LSR - the LSR that is the destination of the MPLS Proxy Ping
Ping Request message and potential initiator of the MPLS Echo Request message and the potential initiator of the MPLS Echo
Request Request
Receiver(s) - the LSR(s) which receive the MPLS Echo Request Receiver(s) - the LSR(s) that receive the MPLS Echo Request
message message
Responder - A receiver that responds to an MPLS Proxy Ping Request Responder - A receiver that responds to an MPLS Proxy Ping Request
or an MPLS Echo Request or an MPLS Echo Request
We note that in some scenarios, the initiator could also be the We note that in some scenarios, the initiator could also be the
responder, in which case the response would be internal to the LSR. responder; in that case, the response would be internal to the LSR.
2.1. Initiating Proxy Ping 2.1. Initiating Proxy Ping
The initiator formats an MPLS Proxy Ping Request message and sends it 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. to the Proxy LSR, an LSR it believes to be on the path of the LSP.
This message instructs the Proxy LSR to either Reply with Proxy This message instructs the Proxy LSR either to reply with Proxy
information or to send an MPLS Echo Request inband of the LSP. The information or to send an MPLS Echo Request in-band of the LSP. The
initiator requests Proxy information so that it can learn additional initiator requests Proxy information so that it can learn additional
information it needs to use to form a subsequent MPLS Proxy Ping information it needs to use to form a subsequent MPLS Proxy Ping
Request. For example, during LSP traceroute an initiator needs the Request. For example, during LSP traceroute, an initiator needs the
downstream map information to form an MPLS Echo Request. An initiator downstream map information to form an MPLS Echo Request. An
may also want to learn a Proxy LSR's FEC neighbor information so that initiator may also want to learn a Proxy LSR's FEC neighbor
it can form Proxy Ping Requests to various LSRs along the LSP. information so that it can form Proxy Ping Requests to various LSRs
along the LSP.
2.2. Handling at Proxy LSR 2.2. Handling at Proxy LSR
The Proxy LSR either replies with the requested Proxy information or The Proxy LSR either replies with the requested Proxy information or
it validates that it has a label mapping for the specified FEC and validates that it has a label mapping for the specified FEC and that
that it is authorized to send the specified MPLS Echo Request on it is authorized to send the specified MPLS Echo Request on behalf of
behalf of the initiator. the initiator.
If the Proxy LSR has a label mapping for the FEC and all If the Proxy LSR has a label mapping for the FEC and all
authorization checks have passed, the Proxy LSR formats an MPLS Echo authorization checks have passed, the Proxy LSR formats an MPLS Echo
Request. If the source address of the MPLS Echo Request is not to be Request. If the source address of the MPLS Echo Request is not set
set to the Proxy Request source address, the initiator MUST include a to the Proxy Request source address, the initiator MUST include a
Reply-to Address TLV containing the source address to use in the MPLS Reply-to Address TLV containing the source address to use in the MPLS
Echo Request. It then sends it inband of the LSP. 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 The receivers process the MPLS Echo Request as normal, sending their
MPLS Echo Replies back to the initiator. MPLS Echo Replies back to the initiator.
If the Proxy LSR failed to send an MPLS Echo Request as normal If the Proxy LSR failed to send an MPLS Echo Request as normal
because it encountered an issue while attempting to send, an MPLS because it encountered an issue while attempting to send, an MPLS
Proxy Ping Reply message is sent back with a Return Code indicating Proxy Ping Reply message is sent back with a Return Code indicating
that the MPLS Echo Request could not be sent. that the MPLS Echo Request could not be sent.
2.2.1. Backward Compatibility 2.2.1. Backward Compatibility
As described in sec 4.4 of [RFC4379], if the packet is not well-
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 formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code set
to "Malformed echo request received" and the Subcode to zero. If to "Malformed echo request received" and the Return Subcode to zero.
there are any TLVs not marked as "Ignore" that Proxy LSR does not If there are any TLVs not marked as "Ignore" that the Proxy LSR does
understand, Proxy LSR SHOULD send an MPLS "TLV not understood" (as not understand, the Proxy LSR SHOULD send an MPLS "TLV not
appropriate), and the Subcode set to zero. understood" (as appropriate), and the Return Subcode is set to zero.
In the case where the targeted Proxy LSR does not understand the LSP In the case where the targeted Proxy LSR does not understand the LSP
ping Echo Request at all, like any other LSR which does not Ping Echo Request at all, like any other LSR that does not understand
understand the messages, it MUST drop them and MUST NOT send any the messages, it MUST drop the message and MUST NOT send any message
message back to the initiator. back to the initiator.
3. Proxy MPLS Echo Request / Reply Procedures 3. Proxy MPLS Echo Request/Reply Procedures
3.1. Procedures for the initiator 3.1. Procedures for the Initiator
The initiator creates an MPLS Proxy Ping request message. The initiator creates an MPLS Proxy Ping request message.
The message MUST contain a Target FEC Stack that describes the FEC 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 being tested. The topmost FEC in the target FEC stack is used at the
Proxy LSR to lookup the MPLS label stack that will be used to Proxy LSR to look up the MPLS label stack that will be used to
encapsulate the MPLS Echo Request packet. encapsulate the MPLS Echo Request packet.
The MPLS Proxy Ping Request message MUST contain a Proxy Echo The MPLS Proxy Ping Request message MUST contain a Proxy Echo
Parameters TLV. In that TLV, the address type is set to either IPv4 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 or IPv6. The Destination IP Address is set to the value to be used
the Proxy LSR to build the MPLS Echo Request packet. The MPLS Echo by the Proxy LSR to build the MPLS Echo Request packet. The MPLS
Request IP header destination address as specified in [RFC4379], if Echo Request IP header destination address is as specified in
the Address Type is IPv4, MUST be an address is from the range 127/8; [RFC4379]. If the Address Type is IPv4, it MUST be an address is
If the Address Type is IPv6, MUST be an address from the range from the range 127/8; if the Address Type is IPv6, MUST be an address
::FFFF:7F00:0/104. from the range ::ffff:7f00:0/104.
The Reply mode and Global Flags of the Proxy Echo Parameters TLV are 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. 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 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 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 because it or an LSR known to it handles the LSP Ping responses).
TTL is set to the value to be used in the outgoing MPLS label stack. The TTL is set to the value to be used in the outgoing MPLS label
See Section 5.1 for further details. stack. See Section 5.1 for further details.
If the FEC's Upstream/Downstream Neighbor address information is If the FEC's Upstream/Downstream Neighbor address information is
required, the initiator sets the "Request for FEC neighbor required, the initiator sets the "Request for FEC neighbor
information" Proxy Flags in the Proxy Echo Parameters TLV. information" Proxy Flags in the Proxy Echo Parameters TLV.
If a Downstream Detailed or Downstream Mapping TLV is required in an If a Downstream Detailed Mapping TLV (or Downstream Mapping TLV,
MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream which is deprecated) is required in an MPLS Proxy Ping Reply, the
Detailed Mapping" or "Request for Downstream Mapping" Proxy Flags in initiator sets the "Request for Downstream Detailed Mapping" (or
the Proxy Echo Parameters TLV. Only one of the two flags can be set. "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 The Proxy Request Reply Mode is set with one of the Reply Modes
defined in [RFC4379] as appropriate. defined in [RFC4379] as appropriate.
A list of Next Hop IP Addresses MAY be included to limit the next 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 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 are encoded as Next Hop sub-TLVs and included in the Proxy Echo
Parameters TLV. Parameters TLV.
Although not explicitly spelled out in [RFC4379], LSP Ping packets 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 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 LSPs 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 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 DF bit MUST be set to prevent IP fragmentation by the IP forwarding
layer. The Proxy Echo Parameter TLV MPLS payload size field is 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 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 Request (including any IP and UDP header) be zero-padded to the
specified size. When a non zero MPLS payload size is specified, 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, 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. 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 Any of following TLVs MAY be included. These TLVs are used to form
the MPLS Echo Request messages by the Proxy LSR: the MPLS Echo Request messages by the Proxy LSR:
Pad Pad
Vendor Enterprise Number Vendor Enterprise Number
Reply TOS Byte Reply TOS Byte
P2MP Responder Identifier [RFC6425] P2MP Responder Identifier [RFC6425]
Echo Jitter TLV [RFC6425] Echo Jitter [RFC6425]
Vendor Private TLVs Vendor Private TLVs
Downstream Detailed Mapping (DDMAP) or Downstream Mapping (DSMAP) Downstream Detailed Mapping (DDMAP) or Downstream Mapping (DSMAP)
TLVs MAY be included. These TLVs will be matched to the next hop TLVs MAY be included. These TLVs will be matched to the next-hop
address for inclusion in those particular MPLS Echo Request messages. address for inclusion in those particular MPLS Echo Request messages.
The message is then encapsulated in a UDP packet. The source User The message is then encapsulated in a UDP packet. The source UDP
Datagram Protocol (UDP) port for the MPLS Proxy Ping Request message port for the MPLS Proxy Ping Request message is chosen by the
is chosen by the initiator; the destination UDP port is set to 3503. initiator; the destination UDP port is set to 3503. The IP header is
The IP header is set as follows: the source IP address is a routable set as follows: the source IP address is a routable address of the
address of the initiator; the destination IP address is a routable initiator; the destination IP address is a routable address to the
address to the Proxy LSR. The packet is then sent with the IP TTL set Proxy LSR. The packet is then sent with the IP TTL set to 255.
to 255.
3.2. Procedures for the Proxy LSR 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 A Proxy LSR that receives an MPLS Proxy Ping Request message parses
the TLVs that are not marked "Ignore" are understood. If any part of 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 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 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 not understood, the Return Code is set to "TLV not understood". The
Subcode is set to zero for both cases. Return Subcode is set to zero for both cases.
If the Reply Mode of the message header is not 1(Do not reply), an 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. MPLS Proxy Ping Reply message SHOULD be sent as described below.
If the Return Code is "TLV not understood", no more processing of the 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 Request message is required. The Proxy LSR sends an
MPLS Proxy Ping Reply message with an Errored TLVs TLV containing all MPLS Proxy Ping Reply message with an Errored TLVs TLV containing
the not understood TLVs (only). (only) the TLVs that were not understood.
The MPLS Proxy Ping Request is expected to be transported to the The MPLS Proxy Ping Request is expected to be transported to the
Proxy LSR via IP forwarding mechanisms instead of using the same Proxy LSR via IP forwarding mechanisms instead of using the same
techniques that are employed to inject an MPLS Echo Request packet techniques that are employed to inject an MPLS Echo Request packet
into an LSP and use IP TTL, MPLS TTL and or loopback addresses (IPv4 into an LSP. The MPLS Echo Request would use IP TTL, MPLS TTL,
127.x.x.x/IPv6::FFF:127/104) in the IP header destination address and/or loopback addresses (IPv4 127.x.x.x or IPv6 ::ffff:7f00/104) in
field to trigger the packet to be handled via an LSR's forwarding the IP header destination address field to trigger the packet to be
exception processing path. To gaurd against this, the Proxy LSR handled via an LSR's forwarding exception processing path. The Proxy
checks that the MPLS Proxy Ping Request message did not arrive via LSR MUST check whether or not MPLS Proxy Ping Request packets arrive
one of its exception processing paths. Packets arriving via IP TTL via exception path. Packets arriving via IP TTL expiry, IP
expiry, IP destination address set to a loopback address or label ttl destination address set to a loopback address, or label TTL expiry
expiry MUST be treated as "Unauthorized" packets. An MPLS Proxy Ping MUST be treated as "Unauthorized" packets. An MPLS Proxy Ping Reply
Reply message MAY be sent with a Return Code of <TBA-7>, "Proxy Ping message MAY be sent with a Return Code of 16, "Proxy Ping not
not authorized". authorized".
The header fields Sender's Handle and Sequence Number are not The header fields Sender's Handle and Sequence Number are not
examined, but they are included in the MPLS Proxy Ping Reply or MPLS 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 Echo Request message, if either is sent as a direct result of the
received message. received message.
The Proxy LSR validates that it has a label mapping for the specified The Proxy LSR validates that it has a label mapping for the specified
FEC, it then determines if it is an ingress, egress, transit or bud FEC, determines if it is an ingress, egress, transit or bud node, and
node and sets the Return Code as appropriate. A new Return Code of then sets the Return Code as appropriate. A new Return Code of 19,
<TBA-10>, "Replying router has FEC mapping for topmost FEC" has been "Replying router has FEC mapping for topmost FEC", has been defined
defined for the case where the Proxy LSR is an ingress (for example for the case where the Proxy LSR is an ingress (for example, the head
head of the TE tunnel or a transit router) because the existing of the TE tunnel or a transit router) because the existing Return
RFC4379 Return Codes don't match the situation. For example, when a Codes defined by RFC 4379 don't match the situation. For example,
Proxy LSR is a transit router, it's not appropriate for the Return when a Proxy LSR is a transit router, it's not appropriate for the
Code to describe how the packet would transit because the MPLS Proxy Return Code to describe how the packet would transit because the MPLS
Ping Request doesn't contain information about what input interface Proxy Ping Request doesn't contain information about what input
the MPLS Echo Request would be switched from at the Proxy LSR. 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 The Proxy LSR then determines if it is authorized to send the
specified MPLS Echo Request on behalf of the initiator. A Proxy LSR specified MPLS Echo Request on behalf of the initiator. A Proxy LSR
MUST be capable of filtering addresses to validate initiators. Other MUST be capable of filtering addresses to validate initiators. Other
filters on FECs or MPLS Echo Request contents MAY be applied. If a 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 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 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 event SHOULD be logged. An MPLS Proxy Ping Reply message MAY be sent
with a Return Code of <TBA-7>, "Proxy Ping not authorized". with a Return Code of 16, "Proxy Ping not authorized".
The destination address specified in the Proxy Echo Parameters TLV is The destination address specified in the Proxy Echo Parameters TLV is
checked to ensure that it conforms to the address allowed IPv4 or checked to ensure that it conforms to the allowed IPv4 or IPv6
IPv6 address range. If not, the Return Code set to "Malformed echo address range. If not, the Return Code is set to "Malformed echo
request received" and the Subcode set to zero. If the Reply Mode of request received" and the Return Subcode is set to zero. If the
the message header is not 1, an MPLS Proxy Ping Reply message SHOULD Reply Mode of the message header is not 1, an MPLS Proxy Ping Reply
be sent as described below. 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 If the "Request for FEC Neighbor Address info" flag is set, the
Upstream Neighbor Address and Downstream Neighbor Address TLVs are Upstream Neighbor Address and Downstream Neighbor Address TLVs are
formatted for inclusion in the MPLS Proxy Ping reply. If the Upstream formatted for inclusion in the MPLS Proxy Ping reply. If the
or Downstream address is unknown, the corresponding TLV is omitted. 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 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 address is examined to determine if it is a valid next hop for this
FEC. If any are not, Proxy Echo Parameters TLV SHOULD be updated FEC. If any are not, the Proxy Echo Parameters TLV SHOULD be updated
removing unrecognized Next Hop sub-TLVs. The updated Proxy Echo to remove unrecognized Next Hop sub-TLVs. The updated Proxy Echo
Parameters TLV MUST be included in the MPLS Proxy Ping Reply. Parameters TLV MUST be included in the MPLS Proxy Ping Reply.
If the "Request for Downstream Detailed Mapping" or "Request for If the "Request for Downstream Detailed Mapping" or "Request for
Downstream Mapping" flag is set, the Proxy LSR formats (for inclusion Downstream Mapping" flag is set, the Proxy LSR formats (for inclusion
in the MPLS Proxy Ping Reply) a Downstream Detailed/Downstream in the MPLS Proxy Ping Reply) a DS/DDMAP TLV for each interface over
Mapping (DD/DSMAP) TLV for each interface over which the MPLS Echo which the MPLS Echo Request will be sent.
Request will be sent.
If the Proxy LSR is the egress for the FEC, the behavior of the Proxy 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 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 the section P2MP LSP, or MP2MP LSP. Additional details can be found in Section
describing "Handling when Proxy LSR it is egress for FEC". 3.2.1, "Proxy LSR Handling When It Is Egress for FEC".
If the Reply Mode of the MPLS Proxy Ping Request message header is "1 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 ("Do not reply"), no MPLS Proxy Ping Reply is sent. Otherwise, an
Proxy Ping Reply message or MPLS Echo Request SHOULD be sent as MPLS Proxy Ping Reply message or MPLS Echo Request SHOULD be sent as
described below. described below.
3.2.1. Proxy LSR Handling when it is egress for FEC 3.2.1. Proxy LSR Handling When It Is Egress for FEC
This section describes the different behaviors for the Proxy LSR when 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 it's the egress for the FEC. In the P2MP bud node and MP2MP bud node
and egress cases, different behavior is required. egress cases, different behavior is required.
In the case where an MLSP Echo Request is originated by an LSR which 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 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 returned from downstream/upstream LSRs and will not include an MPLS
Echo Reply from the LSR that originated the MPLS Echo Request. This Echo Reply from the LSR that originated the MPLS Echo Request. This
section describes the behavior required at a bud or egress node to section describes the behavior required at a bud or egress node to
return or not return information from MPLS Echo Replies in the Proxy return or not return information from MPLS Echo Replies in the Proxy
Echo Reply so that no changes are required in [RFC4379] compliant Echo Reply so that no changes are required in implementations that
implementations. The Proxy Initiator should receive the same MPLS are compliant with [RFC4379]. The Proxy Initiator should receive the
Echo Replies as in the case where of the originator of the LSP ping, same MPLS Echo Replies as in the case of the originator of the LSP
any additional information such as the Proxy LSR being a bud or Ping; any additional information (such as the Proxy LSR being a bud
egress node is returned in the MPLS Proxy Ping Reply. 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 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, Reply SHOULD be sent to the initiator with the Return Code set to 3,
"Reply router is egress for FEC", with Return Subcode set to 0. "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 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, a MPLS 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 Proxy Ping Reply SHOULD be sent to the initiator with the return code
set to 3 (Reply router is Egress for FEC) with return Subcode set to set to 3, "Replying router is an egress for the FEC at stack-depth",
0. DS/DDMAPs are included only if the Proxy initiator requested and Return Subcode set to zero. DS/DDMAPs are included only if the
information to be returned in a MPLS Proxy Ping Reply. If the Proxy Proxy Initiator requested information be returned in an MPLS Proxy
LSR is a bud node but not requested to return an MPLS Proxy Ping Ping Reply. If the Proxy LSR is a bud node but there has not been a
Reply, the Proxy LSR SHOULD send MPLS Echo Request packet(s) to the request to return an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send
downstream neighbors (no MPLS Echo Reply is sent to the Proxy MPLS Echo Request packet(s) to the downstream neighbors (no MPLS Echo
Initiator to indicate that the Proxy LSR is an egress). If the Proxy Reply is sent to the Proxy Initiator to indicate that the Proxy LSR
LSR is just an egress, an MPLS Proxy Ping Reply SHOULD be sent to the is an egress). If the Proxy LSR is just an egress, an MPLS Proxy
initiator with the Return Code set to 3, "Reply router is egress for Ping Reply SHOULD be sent to the initiator with the Return Code set
FEC", and Return Subcode set to 0. 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 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 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 have different behavior in this case. MPLS Echo Requests are sent to
all upstream/downstream neighbors. The Proxy LSRs need to be all upstream/downstream neighbors. The Proxy LSRs need to be
consistent with this variation in behavior. If the Proxy LSR is a bud consistent with this variation in behavior. If the Proxy LSR is a
node or just an egress, an MPLS Proxy Ping Reply SHOULD be sent to bud node or just an egress, an MPLS Proxy Ping Reply SHOULD be sent
the Proxy Initiator with the return code set to 3, "Reply router is to the Proxy Initiator with the return code set to 3, "Replying
Egress for FEC", with Return Subcode set to 0 and DS/DDMAPs included router is an egress for the FEC at stack-depth", with Return Subcode
only if the Proxy initiator requested information to be returned in a set to zero and DS/DDMAPs included only if the Proxy Initiator
MPLS Proxy Ping Reply. If the Proxy LSR is not requested to return requested information be returned in an MPLS Proxy Ping Reply. If
information in an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send the Proxy LSR is not requested to return information in an MPLS Proxy
MPLS Echo Request packets to all upstream/downstream neighbors as Ping Reply, the Proxy LSR SHOULD send MPLS Echo Request packets to
would be done when sourcing an LSP ping from a MP2MP leaf (no MPLS all upstream/downstream neighbors as would be done when sourcing an
Echo Reply is sent to the Proxy initiator indicating that the Proxy LSP Ping from a MP2MP leaf (no MPLS Echo Reply is sent to the Proxy
LSR is an egress). Initiator indicating that the Proxy LSR is an egress).
3.2.2. Downstream Detailed Maps and Downstream Maps in Proxy Reply
3.2.2. Downstream Detailed/Downstream Maps in Proxy Reply
When the Proxy LSR is a transit or bud node, downstream maps When the Proxy LSR is a transit or bud node, downstream maps
corresponding to how the packet is transited cannot be supplied corresponding to how the packet is transited cannot be supplied
unless an ingress interface for the MPLS Echo Request is specified. unless an ingress interface for the MPLS Echo Request is specified.
Since this information is not available and all valid output paths Since this information is not available and all valid output paths
are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) to describe 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 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 similar to the case in which an LSP Ping is initiated at the Proxy
LSR. For mLDP, there is a DSMAP/DDMAP per upstream/downstream LSR. For mLDP, there is a DS/DDMAP per upstream/downstream neighbor
neighbor for MP2MP LSPs, or per downstream neighbor in the P2MP LSP for MP2MP LSPs, or per downstream neighbor in the P2MP LSP case.
case.
When the Proxy LSR is a bud node or egress in an MP2MP LSP or a bud 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 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 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 that the Proxy LSR is itself an egress for the FEC. In order to
the behavior as seen from LSP Ping initiated at the Proxy LSR, the match the behavior as seen from LSP Ping initiated at the Proxy LSR,
Proxy Reply SHOULD contain DSMAP/DDMAPs for only the paths to the the Proxy Reply SHOULD contain DS/DDMAPs for only the paths to the
upstream/downstream neighbors, but no DSMAP/DDMAP describing its own upstream/downstream neighbors, but no DS/DDMAP describing its own
egress paths. The proxy LSR identifies that it's an egress for the 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 FEC using a different Proxy Reply Return Code. The Proxy Reply
Code is either set to "Reply router has a mapping for the topmost Return Code is either set to 19, "Replying router has FEC mapping for
FEC" or "Reply router is egress for the FEC". topmost FEC", or 3, "Replying router is an egress for the FEC at
stack-depth".
3.2.3. Sending an MPLS Proxy Ping Reply 3.2.3. Sending an MPLS Proxy Ping Reply
The Reply mode, Sender's Handle and Sequence Number fields are copied The Reply Mode, Sender's Handle, and Sequence Number fields are
from the Proxy Ping Request message. The TLVs specified above are copied from the Proxy Ping Request message. The TLVs specified above
included. The message is encapsulated in a UDP packet. The source IP are included. The message is encapsulated in a UDP packet. The
address is a routable address of the Proxy LSR; the source port is source IP address is a routable address of the Proxy LSR; the source
the well-known UDP port for LSP ping. The destination IP address and port is the well-known UDP port for LSP Ping. The destination IP
UDP port are copied from the source IP address and UDP port of the address and UDP port are copied from the source IP address and UDP
MPLS Proxy Ping Request. The IP TTL is set to 255. port of the MPLS Proxy Ping Request. The IP TTL is set to 255.
3.2.4. Sending the MPLS Echo Requests 3.2.4. Sending the MPLS Echo Requests
An MPLS Echo Request is formed as described in the next section. The An MPLS Echo Request is formed as described in the next section. The
section below that describes how the MPLS Echo Request is sent on section below describes how the MPLS Echo Request is sent on each
each interface. interface.
3.2.4.1. Forming the base MPLS Echo Request 3.2.4.1. Forming the Base MPLS Echo Request
If Next Hop sub-TLVs were included in the received Proxy Echo If Next Hop sub-TLVs were included in the received Proxy Echo
Parameters TLV, the Next_Hop_List is created from the addresses in Parameters TLV, the Next_Hop_List is created from the addresses in
those sub-TLVs adjusted as described in Section 3.2. Otherwise, the 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. 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 The Proxy LSR then formats an MPLS Echo Request message. The Global
Flags and Reply Mode are copied from the Proxy Echo Parameters TLV. Flags and Reply Mode are copied from the Proxy Echo Parameters TLV.
The Return Code and Return Subcode are set to zero. The Return Code and Return Subcode are set to zero.
The Sender's Handle and Sequence Number are copied from the remote The Sender's Handle and Sequence Number are copied from the remote
echo request message. MPLS Echo Request message.
The TimeStamp Sent is set to the time-of-day (in seconds and The TimeStamp Sent is set to the time of day (in seconds and
microseconds) that the MPLS Echo Request is sent. The TimeStamp microseconds) that the MPLS Echo Request is sent. The TimeStamp
Received is set to zero. Received is set to zero.
If the reply-to address TLV is present, it is used to set the echo If the Reply-to Address TLV is present, it is used to set the MPLS
request source address; otherwise the echo request source address is Echo Request source address; otherwise, the MPLS Echo Request source
set to the Proxy Request source address. address is set to the Proxy Request source address.
The following TLVs are copied from the MPLS Proxy Ping Request The following TLVs are copied from the MPLS Proxy Ping Request
message. Note that of these, only the Target FEC Stack is REQUIRED to message. Note that, of these, only the Target FEC Stack is REQUIRED
appear in the MPLS Proxy Ping Request message. The Pad TLV is not 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 copied if the Proxy Echo Parameter TLV MPLS payload size is set to a
non zero value. non-zero value.
Target FEC Stack Target FEC Stack
Pad Pad
Vendor Enterprise Number Vendor Enterprise Number
Reply TOS Byte Reply TOS Byte
P2MP Responder Identifier [RFC6425] P2MP Responder Identifier [RFC6425]
Echo Jitter TLV [RFC6425] Echo Jitter [RFC6425]
Vendor Private TLVs Vendor Private TLVs
If the Proxy Echo Parameter TLV MPLS payload size is non zero, the 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 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 Request (including any IP and UDP header) is zero-padded to the
specified MPLS payload size. The First Octet in Value part of the specified MPLS payload size. The first octet in the Value part of
Pad TLV is set to 1, "Drop Pad TLV from Reply", the remaining Octets the Pad TLV is set to 1, "Drop Pad TLV from reply", and the remaining
of the Value part of the Pad TLV is filled with zeros. If IP header octets of the Value part of the Pad TLV are filled with zeros. If
is use to encapsulate in the MPLS Echo Request the DF bit MUST be set the IP header is used to encapsulate the MPLS Echo Request, the DF
to one. bit MUST be set to one.
The message is then encapsulated in a UDP packet. The source UDP port The message is then encapsulated in a UDP packet. The source UDP
is copied from the Proxy Echo Parameters TLV. The destination port is port is copied from the Proxy Echo Parameters TLV. The destination
copied from the MPLS Proxy Ping Request message. port is copied from the MPLS Proxy Ping Request message.
The source IP address is set to a routable address specified in the 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 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. Request. Per usual, the TTL of the IP packet is set to 1.
If the Explicit Differentiated Services Code Point (DSCP) flag is If the Explicit Differentiated Services Code Point (DSCP) flag is
set, the Requested DSCP byte is examined. If the setting is permitted set, the Requested DSCP byte is examined. If the setting is
then the DSCP byte of the IP header of the MPLS Echo Request message permitted, then the DSCP byte of the IP header of the MPLS Echo
is set to that value. If the Proxy LSR does not permit explicit Request message is set to that value. If the Proxy LSR does not
control for the DSCP byte, the MPLS Proxy Echo Parameters with the permit explicit control for the DSCP byte, the MPLS Proxy Echo
Explicit DSCP flag cleared MUST be included in any MPLS Proxy Ping Parameters with the Explicit DSCP flag cleared MUST be included in
Reply message to indicate why an MPLS Echo Request was not sent. The any MPLS Proxy Ping Reply message to indicate why an MPLS Echo
Return Code MUST be set to <TBA-8>, "Proxy Ping parameters need to be Request was not sent. The Return Code MUST be set to 17, "Proxy Ping
modified". If the Explicit DSCP flag is not set, the Proxy LSR SHOULD parameters need to be modified". If the Explicit DSCP flag is not
set the MPLS Echo Request DSCP settings to the value normally used to set, the Proxy LSR SHOULD set the MPLS Echo Request DSCP settings to
source LSP ping packets.. the value normally used to source LSP Ping packets.
3.2.4.2. Per interface sending procedures 3.2.4.2. Per-Interface Sending Procedures
The Proxy LSR now iterates through the Next_Hop_List modifying the The Proxy LSR now iterates through the Next_Hop_List modifying the
base MPLS Echo Request to form the MPLS Echo Request packet which is base MPLS Echo Request to form the MPLS Echo Request packet that is
then sent on that particular interface. then sent on that particular interface.
The outgoing label stack is determined for each next hop address. The The outgoing label stack is determined for each next-hop address.
TTL for the label corresponding to the FEC specified in the FEC stack The TTL for the label corresponding to the FEC specified in the FEC
is set such that the TTL on the wire will be other TTL specified in stack is set such that the TTL on the wire will be the TTL specified
the Proxy Echo Parameters. If any additional labels are pushed onto in the Proxy Echo Parameters. If any additional labels are pushed
the stack, their TTLs are set to 255. This will ensure that the 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 requestor will not have control over tunnels not relevant to the FEC
being tested. being tested.
If the MPLS Proxy Ping Request message contained Downstream Mapping/ If the MPLS Proxy Ping Request message contained Downstream Mapping
Downstream Detailed Mapping TLVs, they are examined. If the TLVs or Downstream Detailed Mapping TLVs, they are examined. If the
Downstream IP Address matches the next hop address, that Downstream Downstream IP address matches the next-hop address, that Downstream
Mapping TLV is included in the MPLS Echo Request. Mapping TLV is included in the MPLS Echo Request.
The packet is then transmitted on this interface. The packet is then transmitted on this interface.
4. Proxy Ping Request / Reply Messages 4. Proxy Ping Request/Reply Messages
This document defines two new LSP Ping messages, the MPLS Proxy Ping This document defines two new LSP Ping messages, the MPLS Proxy Ping
Request and the MPLS Proxy Ping Reply. Request and the MPLS Proxy Ping Reply.
4.1. Proxy Ping Request / Reply Message formats 4.1. Proxy Ping Request/Reply Message Formats
The packet format is as defined in [RFC4379]. Two new message types, The packet format is as defined in [RFC4379]. Two new message types,
Proxy Ping Request and Reply, are being added. Proxy Ping Request and Reply, are being added.
Message Type Message Type
Type Message Type Message
---- ------- ---- -------
TBA-1 MPLS Proxy Ping Request 3 MPLS Proxy Ping Request
(Pending IANA assignment) 4 MPLS Proxy Ping Reply
TBA-2 MPLS Proxy Ping Reply
(Pending IANA assignment)
4.2. Proxy Ping Request Message contents 4.2. Proxy Ping Request Message Contents
The MPLS Proxy Ping Request message MAY contain the following The MPLS Proxy Ping Request message MAY contain the following
TLVs: TLVs:
Type TLV Type TLV
---- ----------- ---- -----------
1 Target FEC Stack 1 Target FEC Stack
2 Downstream Mapping 2 Downstream Mapping (DEPRECATED)
3 Pad 3 Pad
5 Vendor Enterprise Number 5 Vendor Enterprise Number
10 Reply TOS Byte 10 Reply TOS Byte
11 P2MP Responder Identifier [RFC6425] 11 P2MP Responder Identifier [RFC6425]
12 Echo Jitter TLV [RFC6425] 12 Echo Jitter [RFC6425]
20 Downstream Detailed Mapping 20 Downstream Detailed Mapping
21 Reply Path [RFC7110] 21 Reply Path [RFC7110]
22 Reply TC [RFC7110] 22 Reply TC [RFC7110]
TBA-3 Proxy Echo Parameters (Pending IANA assignment) 23 Proxy Echo Parameters
TBA-4 Reply-to-Address TLV 24 Reply-to Address
* Vendor Private TLVs * Vendor Private TLVs
* TLVs types in the Vendor Private TLV Space MUST be * TLVs types in the Vendor Private TLV Space MUST be ignored if
ignored if not understood not understood
4.3. Proxy Ping Reply Message Contents 4.3. Proxy Ping Reply Message Contents
The MPLS Proxy Ping Reply message MAY contain the following TLVs: The MPLS Proxy Ping Reply message MAY contain the following TLVs:
Type TLV Type TLV
---- ----------- ---- -----------
1 Target FEC Stack 1 Target FEC Stack
2 Downstream Mapping 2 Downstream Mapping (DEPRECATED)
5 Vendor Enterprise Number 5 Vendor Enterprise Number
9 Errored TLVs 9 Errored TLVs
20 Downstream Detailed Mapping 20 Downstream Detailed Mapping
TBA-3 Proxy Echo Parameters (Pending IANA assignment) 23 Proxy Echo Parameters
TBA-5 Upstream Neighbor Address (Pending IANA assignment) 25 Upstream Neighbor Address
TBA-6 Downstream Neighbor Address (0 or more) 26 Downstream Neighbor Address (0 or more)
(Pending IANA assignment)
* Vendor Private TLVs * Vendor Private TLVs
* TLVs types in the Vendor Private TLV Space MUST be * TLVs types in the Vendor Private TLV Space MUST be ignored if
ignored if not understood not understood
5. TLV formats 5. TLV Formats
5.1. Proxy Echo Parameters TLV 5.1. Proxy Echo Parameters TLV
The Proxy Echo Parameters TLV is a TLV that MUST be included in an 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, MPLS Proxy Ping Request message. The length of the TLV is 12 + K +
where K is the length of the Destination IP Address field and S is 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 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 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 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 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 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 returned in an MPLS Proxy Ping Reply), no MPLS Echo Request will be
sent from the Proxy LSR. The MPLS Proxy Ping Request echo header's sent from the Proxy LSR. The MPLS Proxy Ping Request Proxy Echo
Reply Mode SHOULD be set to "Reply with Proxy Info". Parameters TLV's Proxy Flags SHOULD be set appropriately, as
described below.
0 1 2 3 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 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 | | Address Type | Reply Mode | Proxy Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Rqst'd DSCP | Source UDP Port | | TTL | Rqst'd DSCP | Source UDP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Flags | MPLS Payload size | | Global Flags | MPLS Payload Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Destination IP Address : : Destination IP Address :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: : : :
: Sub-TLVs : : Sub-TLVs :
: : : :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type Address Type
The type and length of the address found in the in the Destination 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 IP Address and Next Hop IP Addresses fields. The values are
with the Downstream Mapping Address Type Registry. shared with the Downstream Mapping Address Type Registry.
The type codes applicable in this case appear in the table below: The type codes applicable in this case appear in the table below:
Address Family Type Length Address Family Type Length
IPv4 1 4 IPv4 1 4
IPv6 3 16 IPv6 3 16
Reply mode Reply Mode
The reply mode to be sent in the MPLS Echo Request message; the The reply mode to be sent in the MPLS Echo Request message; the
values are as specified in [RFC4379]. values are as specified in [RFC4379].
Proxy Flags Proxy Flags
The Proxy Request Initiator sets zero, one or more of these flags The Proxy Request Initiator sets zero, one, or more of these flags
to request actions at the Proxy LSR. to request actions at the Proxy LSR.
0x01 Request for FEC Neighbor Address info 0x0001 Request for FEC Neighbor Address info
When set, this requests that the Proxy LSR supply the When set, this requests that the Proxy LSR supply the
Upstream and Downstream neighbor address information in the Upstream and Downstream neighbor address information in the
MPLS Proxy Ping Reply message. This flag is only applicable MPLS Proxy Ping Reply message. This flag is only applicable
for the topmost FEC in the FEC stack if the FEC type for the topmost FEC in the FEC stack if the FEC type
corresponds with a P2MP or MP2MP LSP. The Proxy LSR MUST corresponds with a P2MP or MP2MP LSP. The Proxy LSR MUST
respond as applicable with Upstream Neighbor Address and respond (as applicable) with Upstream Neighbor Address and
Downstream Neighbor Address TLV(s) in the MPLS Proxy Ping Downstream Neighbor Address TLV(s) in the MPLS Proxy Ping
Reply message. The Upstream Neighbor Address TLV needs be Reply message. The Upstream Neighbor Address TLV needs be
included only if there is an upstream neighbor. Similarly, included only if there is an upstream neighbor. Similarly,
one Downstream Neighbor Address TLV needs to be included for one Downstream Neighbor Address TLV needs to be included for
each Downstream Neighbor from which the LSR learned each Downstream Neighbor from which the LSR learned
bindings. bindings.
Setting this flag will cause the Proxy LSR to cancel sending Setting this flag will cause the Proxy LSR to cancel sending
any MPLS Echo Request. The initiator may use information any MPLS Echo Request. The initiator may use information
learned from the MPLS Proxy Ping Reply that is sent instead learned from the MPLS Proxy Ping Reply that is sent instead
to generate subsequent proxy requests. to generate subsequent proxy requests.
0x02 Request for Downstream Mapping 0x0002 Request for Downstream Mapping
When set, this requests that the Proxy LSR supply a When set, this requests that the Proxy LSR supply a
Downstream Mapping TLV see [RFC4379] in the MPLS Proxy Ping Downstream Mapping TLV (see [RFC4379]) in the MPLS Proxy
Reply message. Either this flag may be set or the Request Ping Reply message. Either this flag may be set or the
for Downstream Detailed Mapping flag may be set, but not "Request for Downstream Detailed Mapping" flag may be set,
both. but not both.
Setting this flag will cause the Proxy LSR to cancel sending Setting this flag will cause the Proxy LSR to cancel sending
an Echo request. Information learned with such Proxy Reply an MPLS Echo Request. Information learned with such a Proxy
may be used by the Proxy initiator to generate subsequent Reply may be used by the Proxy Initiator to generate
Proxy Requests. subsequent Proxy Requests.
0x04 Request for Downstream Detailed Mapping 0x0004 Request for Downstream Detailed Mapping
When set, this requests that the Proxy LSR supply a When set, this requests that the Proxy LSR supply a
Downstream Detailed Mapping TLV see [RFC6424] in the MPLS Downstream Detailed Mapping TLV (see [RFC6424]) in the MPLS
Proxy Ping Reply message. It's not valid to have Request for Proxy Ping Reply message. It's not valid to have the
Downstream Mapping flag set when this flag is set. Setting "Request for Downstream Mapping" flag set when this flag is
this flag will cause the Proxy LSR to cancel sending an Echo set. Setting this flag will cause the Proxy LSR to cancel
request. The initiator may use information learned from the sending an MPLS Echo Request. The initiator may use
MPLS Proxy Ping Reply that is sent instead to generate information learned from the MPLS Proxy Ping Reply that is
subsequent proxy requests. sent instead to generate subsequent proxy requests.
0x08 Explicit DSCP Request 0x0008 Explicit DSCP Request
When set, this requests that the Proxy LSR use the supplied When set, this requests that the Proxy LSR use the supplied
"Rqst'd DSCP" byte in the Echo Request message "Rqst'd DSCP" byte in the Echo Request message
TTL TTL
The TTL to be used in the label stack entry corresponding to The TTL to be used in the label stack entry corresponding to
the topmost FEC in the in the MPLS Echo Request packet. Valid the topmost FEC in the MPLS Echo Request packet. Valid values
values are in the range [1,255]. A setting of 0 SHOULD be are in the range [1,255].
ignored by the Proxy LSR.
Requested DSCP Requested DSCP
This field is valid only if the Explicit DSCP flag is set. If 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 not set, the field MUST be zero on transmission and ignored on
receipt. When the flag is set, this field contains the DSCP receipt. When the flag is set, this field contains the DSCP
value to be used in the MPLS Echo Request packet IP header. value to be used in the MPLS Echo Request packet IP header.
Source UDP Port Source UDP Port
The source UDP port to be sent in the MPLS Echo Request packet The source UDP port to be sent in the MPLS Echo Request packet
Global Flags Global Flags
The Global Flags to be sent in the MPLS Echo Request message The Global Flags to be sent in the MPLS Echo Request message
MPLS Payload Size MPLS Payload Size
Used to request that the MPLS payload (IP header + UDP header + Used to request that the MPLS payload (IP header + UDP header +
MPLS Echo Request) be padded using a zero filled Pad TLV so MPLS Echo Request) be padded using a zero-filled Pad TLV so
that the IP header, UDP header and MPLS Echo Request total the that the IP header, UDP header, and MPLS Echo Request total the
specified size. Field set to zero means no size request is specified size. Having the field set to zero means no size
being made. If the requested size is less than the minimum size request is being made. If the requested size is less than the
required to form the MPLS Echo Request, the request will be minimum size required to form the MPLS Echo Request, the
treated as a best effort request with the Proxy LSR building request will be treated as a best-effort request with the Proxy
the smallest possible packet (i.e. not using a Pad TLV). The IP LSR building the smallest possible packet (i.e., not using a
header DF bit MUST be set when this field is non zero. Pad TLV). The IP header DF bit MUST be set when this field is
non-zero.
Destination IP Address Destination IP Address
If the Address Type is IPv4, an address from the range 127/8; If the Address Type is IPv4, an address from the range 127/8;
If the Address Type is IPv6, an address from the range if the Address Type is IPv6, an address from the range
::FFFF:7F00:0/104 ::ffff:7f00:0/104
Sub-TLVs Sub-TLVs
List of TLV-encoded sub-TLVs. Currently one is defined. List of TLV-encoded sub-TLVs. Currently one is defined.
Sub-TLV Type Length Value Field Sub-Type Length Sub-TLV Name
------------ ------ ----------- -------- ------ ------------
<TBA-13> 8+ Next Hop 1 8+ Next Hop
5.1.1. Next Hop sub-TLV 5.1.1. Next Hop Sub-TLV
This sub-TLV is used to describe a particular next hop towards which 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 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 FEC stack is a multipoint LSP, this sub-TLV may appear multiple
times. times.
0 1 2 3 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 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 | MUST be Zero | | Addr Type | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop IP Address (4 or 16 octets) | | Next Hop IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Interface (0, 4 or 16 octets) | | Next Hop Interface (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type Address Type
Type Type of Next Hop Addr Length IF Length Type Type of Next Hop Addr Length Interface Field (IF)
Length
1 IPv4 Numbered 4 4 1 IPv4 Numbered 4 4
2 IPv4 Unnumbered 4 4 2 IPv4 Unnumbered 4 4
3 IPv6 Numbered 16 16 3 IPv6 Numbered 16 16
4 IPv6 Unnumbered 16 4 4 IPv6 Unnumbered 16 4
5 Reserved 5 Reserved
TBA-11 IPv4 Protocol Adj 4 0 6 IPv4 Protocol Adj 4 0
TBA-12 IPv6 Protocol Adj 16 0 7 IPv6 Protocol Adj 16 0
Note: Types 1-4 correspond to the types in the DS Mapping TLV.
They are expected to populated with information obtained Note: Types 1-4 correspond to the types in the DSMAP TLV.
through a previously returned DS Mapping TLV. Types They are expected to be populated with information
<TBA-11> and <TBA-12> are intended to be populated obtained through a previously returned DSMAP TLV. Types
from the local address information obtained from a 6 and 7 are intended to be populated from the local
previously returned Downstream Neighbor Address address information obtained from a previously returned
TLV(s)/Upstream Neighbor Address TLV. Downstream Neighbor Address TLV or Upstream Neighbor
Address TLV.
Next Hop IP Address Next Hop IP Address
A next hop address that the echo request message is to A next hop address that the Echo Request message is to be sent
be sent towards towards
Next Hop Interface Next Hop Interface
Identifier of the interface through which the echo request Identifier of the interface through which the Echo Request
message is to be sent. For Addr Type 5, and 6, the Next Hop 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 interface field isn't used and MUST be of an associated byte
length of "0" octets. length of zero octets.
5.2. Reply-to Address TLV 5.2. Reply-to Address TLV
Used to specify the MPLS Echo Request IP source address. This address Used to specify the MPLS Echo Request IP source address. This
MUST be IP reachable via the Proxy LSR; otherwise it will be address MUST be IP reachable via the Proxy LSR; otherwise, it will be
rejected. rejected.
0 1 2 3 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 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 | MUST be Zero | | Address Type | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Reply-to Address : : Reply-to Address :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type Address Type
A type code as specified in the table below: A type code as specified in the table below:
skipping to change at page 21, line 4 skipping to change at page 21, line 34
Type Type of Address Type Type of Address
1 IPv4 1 IPv4
3 IPv6 3 IPv6
5.3. Upstream Neighbor Address TLV 5.3. Upstream Neighbor Address TLV
0 1 2 3 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 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| MUST be Zero | |Upst Addr Type |Local Addr Type| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Upstream Address : : Upstream Address :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Local Address : : Local Address :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upst Addr Type; Local Addr Type Upst Addr Type; Local Addr Type
These two fields determine the type and length of the These two fields determine the type and length of the
respective addresses. The codes are specified in the table respective addresses. The codes are specified in the table
below: below:
Type Type of Address Length Type Type of Address Length
0 No Address Supplied 0 0 No Address Supplied 0
1 IPv4 4 1 IPv4 4
3 IPv6 16 3 IPv6 16
Upstream Address Upstream Address
The address of the immediate upstream neighbor for the topmost The address of the immediate upstream neighbor for the topmost
FEC in the FEC stack. If protocol adjacency exists by which the FEC in the FEC stack. If the protocol adjacency exists by
label for this FEC was exchanged, this address MUST be the which the label for this FEC was exchanged, this address MUST
address used in that protocol exchange. be the address used in that protocol exchange.
Local Address Local Address
The local address used in the protocol adjacency exists by The local address used in the protocol adjacency by which the
which the label for this FEC was exchanged. label for this FEC was exchanged.
5.4. Downstream Neighbor Address TLV 5.4. Downstream Neighbor Address TLV
0 1 2 3 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 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| MUST be Zero | |Dnst Addr Type |Local Addr Type| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Downstream Address : : Downstream Address :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: Local Address : : Local Address :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dnst Addr Type; Local Addr Type Dnst Addr Type; Local Addr Type
These two fields determine the type and length of the These two fields determine the type and length of the
respective addresses. The codes are specified in the table respective addresses. The codes are specified in the table
below: below:
Type Type of Address Length Type Type of Address Length
0 No Address Supplied 0 0 No Address Supplied 0
1 IPv4 4 1 IPv4 4
3 IPv6 16 3 IPv6 16
Downstream Address Downstream Address
The address of a immediate downstream neighbor for the topmost The address of an immediate downstream neighbor for the topmost
FEC in the FEC stack. If protocol adjacency exists by which the FEC in the FEC stack. If the protocol adjacency exists by
label for this FEC was exchanged, this address MUST be the which the label for this FEC was exchanged, this address MUST
address used in that protocol exchange. be the address used in that protocol exchange.
Local Address Local Address
The local address used in the protocol adjacency exists by The local address used in the protocol adjacency by which the
which the label for this FEC was exchanged. label for this FEC was exchanged.
6. Security Considerations 6. Security Considerations
The mechanisms described in this document are intended to be used The mechanisms described in this document are intended to be used
within a Service Provider network and to be initiated only under the within a service provider network and to be initiated only under the
authority of that administration. authority of that administration.
If such a network also carries Internet traffic, or permits IP access If such a network also carries Internet traffic, or permits IP access
from other administrations, MPLS Proxy Ping message SHOULD be from other administrations, the MPLS Proxy Ping message SHOULD be
discarded at the points that where the IP packet is received from the discarded at the points where IP packets are received from other
other administrations. This can be accomplished by filtering on administrations. This can be accomplished by filtering on source
source address or by filtering all MPLS ping messages on UDP port. address or by filtering all MPLS ping messages on UDP port.
Any node which acts as a Proxy LSR SHOULD validate requests against a Any node that acts as a Proxy LSR SHOULD validate requests against a
set of valid source addresses. An implementation MUST provide such set of valid source addresses. An implementation MUST provide such
filtering capabilities. filtering capabilities.
MPLS Proxy Ping Request messages are IP addressed directly to the MPLS Proxy Ping Request messages are IP addressed directly to the
Proxy LSR. If a Proxy LSR receives an MPLS Proxy Ping message via 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 expiration of the IP or Label Stack Entry TTL, it MUST NOT be acted
upon. upon.
If an MPLS Proxy Ping Request IP source address is not IP reachable 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. by the Proxy LSR, the Proxy Request MUST NOT be acted upon.
MPLS Proxy Ping Requests are limited to making their request via the MPLS Proxy Ping Requests are limited to making their request via the
specification of a FEC. This ensures that only valid MPLS Echo specification of a FEC. This ensures that only valid MPLS Echo
Request messages can be created. No label spoofing attacks are Request messages can be created. No label-spoofing attacks are
possible. possible.
7. Acknowledgements 7. IANA Considerations
The authors would like to thank Nobo Akiya, Adrian Farrel, Tom Yu,
Tom Taylor and Warren Kumari for their detailed review and insightful
comments.
8. IANA Considerations
This document makes the following assignments (pending IANA action) Per this document, IANA has made the following assignments.
MPLS LSP Ping Message Types MPLS LSP Ping Message Types
Type Value Field Value Meaning
---- ----------- ----- -------
TBA-1 MPLS Proxy Ping Request 3 MPLS Proxy Ping Request
TBA-2 MPLS Proxy Ping Reply 4 MPLS Proxy Ping Reply
TLVs TLVs
Type Value Field Type TLV Name
---- ----------- ---- --------
TBA-3 Proxy Echo Parameters 23 Proxy Echo Parameters
TBA-4 Reply-to Address 24 Reply-to Address
TBA-5 Upstream Neighbor Address 25 Upstream Neighbor Address
TBA-6 Downstream Neighbor Address 26 Downstream Neighbor Address
Return Code [pending IANA assignment] Return Codes
Value Meaning Value Meaning
----- ------- ----- -------
TBA-7 Proxy Ping not authorized. 16 Proxy Ping not authorized
TBA-8 Proxy Ping parameters need to be modified. 17 Proxy Ping parameters need to be modified
TBA-9 MPLS Echo Request Could not be sent. 18 MPLS Echo Request could not be sent
TBA-10 Replying router has FEC mapping for topmost FEC. 19 Replying router has FEC mapping for topmost FEC
8.1. Proxy Echo Parameters Sub-TLVs 7.1. Proxy Echo Parameters Sub-TLVs
The IANA will create and maintain this new registry for Proxy Echo The IANA has created and maintains this new registry for Proxy Echo
Parameters Sub-TLV's. Assignments will use the same rules spelled out Parameters Sub-TLVs. Assignments will use the same rules spelled out
in sec 7.2 of [RFC4379]. in Section 7.2 of [RFC4379].
Sub-TLV Type Meaning Sub-Type Sub-TLV Name
----------- ------- -------- ------------
0 Reserved 0 Reserved
TBA-13 Next Hop 1 Next Hop
8.2. Downstream Address Mapping Registry [pending IANA assignment] 7.2. Proxy Flags
This document makes the following assignments in the Downstream IANA has created and maintains a new registry for the Proxy Flags
Address Mapping Registry(pending IANA assignment). This document that are used with the Proxy Echo Parameters TLV. See Section 5.1
updates the registry defined by [RFC6426], modifying the allocation for details. The registry is in the "Multi-Protocol Label Switching
procedures. (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.
The allocation procedures of Downstream Mapping Address Type Registry Bit Number Name
is changed to read 'Standards action - each time a code point is ---------- ----
assigned from this registry, unless the same registration is made in 0 Request for FEC Neighbor Address info
both registries, the corresponding Next Hop Address Type Registry 1 Request for Downstream Mapping
must be Marked "Reserved". 2 Request for Downstream Detailed Mapping
3 Explicit DSCP Request
4-15 Unassigned
Value Meaning K Octets 7.3. Downstream Address Mapping Registry
----- ------- --------
TBA-11 Reserved N/A [this doc] This document makes the following assignments in the Downstream
TBA-12 Reserved N/A [this doc] 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:
8.3. Next Hop Sub-TLV Address Type Registry 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".
IANA is requested to create a new registry called "Next Hop Address Type # Address Type K Octets
Type Registry". The allocation policy for this registry is ------ ------------ --------
"Standards action". Further, each time a code point is assigned from 6 Reserved N/A RFC 7555
this registry, unless the same registration is made in both 7 Reserved N/A RFC 7555
registries, the corresponding Downstream Address Mapping Registry
must be Marked "Reserved". The initial allocations are: 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".
The initial allocations are:
Type Type of Next Hop Addr Length IF Length Reference Type Type of Next Hop Addr Length IF Length Reference
1 IPv4 Numbered 4 4 [RFC4379] 1 IPv4 Numbered 4 4 [RFC4379]
2 IPv4 Unnumbered 4 4 [RFC4379] 2 IPv4 Unnumbered 4 4 [RFC4379]
3 IPv6 Numbered 16 16 [RFC4379] 3 IPv6 Numbered 16 16 [RFC4379]
4 IPv6 Unnumbered 16 4 [RFC4379] 4 IPv6 Unnumbered 16 4 [RFC4379]
5 Reserved [this doc] 5 Reserved RFC 7555
TBA-11 IPv4 Protocol Adj 4 0 [this doc] 6 IPv4 Protocol Adj 4 0 RFC 7555
TBA-12 IPv6 Protocol Adj 16 0 [this doc] 7 IPv6 Protocol Adj 16 0 RFC 7555
x-255 Unassigned 8-255 Unassigned
9. References 8. References
9.1. Normative References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
Performing Label Switched Path Ping (LSP Ping) over MPLS Performing Label Switched Path Ping (LSP Ping) over MPLS
Tunnels", RFC 6424, November 2011. Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
<http://www.rfc-editor.org/info/rfc6424>.
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
S., and T. Nadeau, "Detecting Data-Plane Failures in Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC Failures in Point-to-Multipoint MPLS - Extensions to LSP
6425, November 2011. Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<http://www.rfc-editor.org/info/rfc6425>.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and Aggarwal, R., [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
"MPLS On-Demand Connectivity Verification and Route On-Demand Connectivity Verification and Route Tracing",
Tracing", RFC 6426, November 2011. 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 Delord, S., [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping", "Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, January 2014. RFC 7110, DOI 10.17487/RFC7110, January 2014,
<http://www.rfc-editor.org/info/rfc7110>.
9.2. Informative References 8.2. Informative References
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
"Extensions to Resource Reservation Protocol - Traffic Yasukawa, Ed., "Extensions to Resource Reservation
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Switched Paths (LSPs)", RFC 4875, May 2007. Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<http://www.rfc-editor.org/info/rfc4875>.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
"Label Distribution Protocol Extensions for Point-to- IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Multipoint and Multipoint-to-Multipoint Label Switched DOI 10.17487/RFC5226, May 2008,
Paths", RFC 6388, November 2011. <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.
Authors' Addresses Authors' Addresses
George Swallow George Swallow
Cisco Systems Cisco Systems
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
USA United States
EMail: swallow@cisco.com
Email: swallow@cisco.com
Vanson Lim Vanson Lim
Cisco Systems Cisco Systems
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA United States
Email: vlim@cisco.com EMail: vlim@cisco.com
Sam Aldrin Sam Aldrin
Huawei Technologies Huawei Technologies
2330 Central Express Way 2330 Central Express Way
Santa Clara, CA 95951 Santa Clara, CA 95951
USA United States
Email: aldrin.ietf@gmail.com EMail: aldrin.ietf@gmail.com
 End of changes. 205 change blocks. 
587 lines changed or deleted 620 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/