Internet Engineering Task Force (IETF) G. Swallow
Request for Comments: 7555 V. Lim
Category: Standards Track Cisco Systems
ISSN: 2070-1721 S. Aldrin
Huawei Technologies
June 2015
Internet Engineering Task Force (IETF) G. Swallow
Request for Comments: 7555 V. Lim
Category: Standards Track Cisco Systems
ISSN: 2070-1721 S. Aldrin
Huawei Technologies
June 2015
Proxy MPLS Echo Request
代理MPLS回显请求
Abstract
摘要
This document defines a means of remotely initiating Multiprotocol Label Switched Protocol (MPLS) Pings on Label Switched Paths. An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root).
本文档定义了在标签交换路径上远程启动多协议标签交换协议（MPLS）ping的方法。MPLS代理Ping请求沿着标签交换路径发送到任何标签交换路由器。此功能的主要动机首先是在大型点对多点LSP中使用LSP Ping时限制消息数量和相关处理，其次是启用从叶到叶（或根）的跟踪。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7555.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. Terminology ................................................5
2. Proxy Ping Overview .............................................5
2.1. Initiating Proxy Ping ......................................6
2.2. Handling at Proxy LSR ......................................6
2.2.1. Backward Compatibility ..............................6
3. Proxy MPLS Echo Request/Reply Procedures ........................7
3.1. Procedures for the Initiator ...............................7
3.2. Procedures for the Proxy LSR ...............................9
3.2.1. Proxy LSR Handling When It Is Egress for FEC .......11
3.2.2. Downstream Detailed Maps and Downstream
Maps in Proxy Reply ................................12
3.2.3. Sending an MPLS Proxy Ping Reply ...................12
3.2.4. Sending the MPLS Echo Requests .....................13
3.2.4.1. Forming the Base MPLS Echo Request ........13
3.2.4.2. Per-Interface Sending Procedures ..........14
4. Proxy Ping Request/Reply Messages ..............................15
4.1. Proxy Ping Request/Reply Message Formats ..................15
4.2. Proxy Ping Request Message Contents .......................15
4.3. Proxy Ping Reply Message Contents .........................16
5. TLV Formats ....................................................16
5.1. Proxy Echo Parameters TLV .................................16
5.1.1. Next Hop Sub-TLV ...................................20
5.2. Reply-to Address TLV ......................................21
5.3. Upstream Neighbor Address TLV .............................21
5.4. Downstream Neighbor Address TLV ...........................22
6. Security Considerations ........................................23
7. IANA Considerations ............................................24
7.1. Proxy Echo Parameters Sub-TLVs ............................24
7.2. Proxy Flags ...............................................25
7.3. Downstream Address Mapping Registry .......................25
7.4. Next Hop Sub-TLV Address Type Registry ....................25
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
Acknowledgements ..................................................27
Authors' Addresses ................................................28
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. Terminology ................................................5
2. Proxy Ping Overview .............................................5
2.1. Initiating Proxy Ping ......................................6
2.2. Handling at Proxy LSR ......................................6
2.2.1. Backward Compatibility ..............................6
3. Proxy MPLS Echo Request/Reply Procedures ........................7
3.1. Procedures for the Initiator ...............................7
3.2. Procedures for the Proxy LSR ...............................9
3.2.1. Proxy LSR Handling When It Is Egress for FEC .......11
3.2.2. Downstream Detailed Maps and Downstream
Maps in Proxy Reply ................................12
3.2.3. Sending an MPLS Proxy Ping Reply ...................12
3.2.4. Sending the MPLS Echo Requests .....................13
3.2.4.1. Forming the Base MPLS Echo Request ........13
3.2.4.2. Per-Interface Sending Procedures ..........14
4. Proxy Ping Request/Reply Messages ..............................15
4.1. Proxy Ping Request/Reply Message Formats ..................15
4.2. Proxy Ping Request Message Contents .......................15
4.3. Proxy Ping Reply Message Contents .........................16
5. TLV Formats ....................................................16
5.1. Proxy Echo Parameters TLV .................................16
5.1.1. Next Hop Sub-TLV ...................................20
5.2. Reply-to Address TLV ......................................21
5.3. Upstream Neighbor Address TLV .............................21
5.4. Downstream Neighbor Address TLV ...........................22
6. Security Considerations ........................................23
7. IANA Considerations ............................................24
7.1. Proxy Echo Parameters Sub-TLVs ............................24
7.2. Proxy Flags ...............................................25
7.3. Downstream Address Mapping Registry .......................25
7.4. Next Hop Sub-TLV Address Type Registry ....................25
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................27
Acknowledgements ..................................................27
Authors' Addresses ................................................28
This document is motivated by two broad issues in connection with diagnosing Point-to-Multipoint (P2MP) Label Switched Paths (LSPs). The first is scalability due to the automatic replication of Multiprotocol Label Switching (MPLS) Echo Request messages as they proceed down the tree. The second, which is primarily motivated by LDP-based P2MP and Multipoint-to-Multipoint (MP2MP) LSPs [RFC6388], is the ability to trace a sub-LSP from leaf node to root node.
本文档的动机是与诊断点对多点（P2MP）标签交换路径（LSP）相关的两大问题。第一个是可伸缩性，这是由于多协议标签交换（MPLS）回显请求消息在树下进行时自动复制所致。第二个主要由基于LDP的P2MP和多点对多点（MP2MP）LSP[RFC6388]驱动，是从叶节点到根节点跟踪子LSP的能力。
When tracing from a source to a particular leaf in a P2MP or MP2MP tree, nodes not along that path will need to process MPLS Echo Request messages that are received. The number of MPLS Echo Replies sent in response to an MPLS Echo Request quickly multiplies, as the Label Switching Routers (LSRs), which are part of the tree but not along the path of the trace, could be responding to the received MPLS Echo Request as well. This could also overwhelm the source to process all the MPLS Echo Reply messages it receives. It is anticipated that many of the applications for P2MP/MP2MP tunnels will require OAM that is both rigorous and scalable.
当从源跟踪到P2MP或MP2MP树中的特定叶时，不沿该路径的节点将需要处理接收到的MPLS回显请求消息。为响应MPLS回送请求而发送的MPLS回送回复的数量会快速增加，因为标签交换路由器（LSR）是树的一部分，但不沿跟踪路径，也可能响应接收到的MPLS回送请求。这也可能使源无法处理它接收到的所有MPLS回显回复消息。预计P2MP/MP2MP隧道的许多应用程序将需要严格且可扩展的OAM。
Suppose one wishes to trace a P2MP LSP to localize a fault that is affecting one egress or a set of egresses. Suppose one follows the normal procedure for tracing -- namely, repeatedly pinging from the root, incrementing the Time to Live (TTL) by one after each three or so pings. Such a procedure has the potential for producing a large amount of processing at the P2MP-LSP midpoints and egresses. It also could produce an unwieldy number of replies back to the root.
假设希望跟踪P2MP LSP以定位影响一个出口或一组出口的故障。假设有人遵循正常的跟踪过程——即从根节点重复ping，在大约三次ping之后，将生存时间（TTL）增加一次。这样的程序有可能在P2MP-LSP中点和出口处产生大量处理。它还可能产生数量庞大的回复回根目录。
One alternative would be to begin sending pings from points at or near the affected egress(es) and then work backwards toward the root. The TTL could be held constant (say, two), limiting the number of responses to the number of next-next-hops of the point where a ping is initiated.
一种替代方法是从受影响出口处或附近的点开始发送ping，然后向后向根方向工作。TTL可以保持不变（例如，两个），将响应数限制为ping启动点的下一跳数。
In the case of Resource Reservation Protocol Traffic Engineering (RSVP-TE), all setup is initiated from the root of the tree. Thus, the root of the tree has knowledge of all the leaf nodes and usually the topology of the entire tree. Thus, the above alternative can easily be initiated by the root node.
在资源预留协议流量工程（RSVP-TE）的情况下，所有设置都从树的根开始。因此，树的根知道所有叶节点，通常也知道整个树的拓扑结构。因此，上述替代方案可以容易地由根节点发起。
In [RFC6388], the situation is quite different. Leaf nodes initiate connectivity to the tree, which is granted by the first node toward the root that is part of the tree. The root node may only be aware of the immediately adjacent (downstream) nodes of the tree. Initially, the leaf node only has knowledge of the (upstream) node to which it is immediately adjacent. However, this is sufficient information to initiate a trace. First, the above procedure is
在[RFC6388]中，情况完全不同。叶节点启动到树的连接，该连接由第一个节点向作为树一部分的根节点授予。根节点可能只知道树的紧邻（下游）节点。最初，叶节点仅知道其紧邻的（上游）节点。但是，这些信息足以启动跟踪。首先，上述程序是正确的
applied by asking that node to ping across the final link. That is, a message is sent from the leaf to the upstream node requesting it to send an MPLS Echo Request for the Forward Equivalence Class (FEC) of the tree in question on said link. The leaf node also requests the identity of the upstream neighbor's upstream neighbor for that FEC. With this information, the procedure can iteratively be applied until the fault is localized or the root node is reached. In all cases, the TTL for the request need only be at most 2. Thus, the processing load of each request is small, since only a limited number of nodes will receive the request.
通过请求该节点在最终链接上ping来应用。也就是说，将消息从叶发送到上游节点，请求其在所述链路上发送针对所述树的前向等价类（FEC）的MPLS回送请求。叶节点还请求该FEC的上游邻居的上游邻居的身份。有了这些信息，可以迭代地应用该过程，直到故障定位或到达根节点。在所有情况下，请求的TTL最多只需要2个。因此，每个请求的处理负载很小，因为只有有限数量的节点将接收该请求。
This document defines protocol extensions to MPLS ping [RFC4379] to allow a third party to remotely cause an MPLS Echo Request message to be sent down an LSP or part of an LSP. The procedure described in the paragraphs above does require that the initiator know the previous-hop node to the one which was pinged on the prior iteration. This information is readily available in [RFC4875]. This document also provides a means for obtaining this information for P2MP and MP2MP LSPs that are set up with LDP as described in [RFC6388].
本文档定义了MPLS ping[RFC4379]的协议扩展，以允许第三方远程导致将MPLS回送请求消息发送到LSP或LSP的一部分。以上段落中描述的过程确实要求启动器知道前一跳节点与在前一次迭代中ping的节点。该信息可在[RFC4875]中找到。本文件还提供了一种获取P2MP和MP2MP LSP信息的方法，如[RFC6388]所述，这些LSP是用LDP设置的。
While the motivation for this document came from multicast scaling concerns, its applicability may be wider. The procedures presented in this document are applicable to all LSP Ping FEC types where the MPLS Echo Request/Reply are IP encapsulated and the MPLS Echo Reply can be sent out of band of the LSP over IP. Remote pinging of LSPs that involves the use of in-band control channels is beyond the scope of this document.
虽然本文档的动机来自多播扩展问题，但其适用范围可能更广。本文档中介绍的过程适用于所有LSP Ping FEC类型，其中MPLS回送请求/回复是IP封装的，并且MPLS回送回复可以通过IP发送到LSP的带外。涉及使用带内控制通道的LSP远程ping超出了本文档的范围。
Other uses of this facility are beyond the scope of this document. In particular, the procedures defined in this document only allow testing of a FEC stack consisting of a single FEC. The procedures also do not allow the initiator to specify the label assigned to that FEC, nor do the procedures allow the initiator to cause any additional labels to be added to the label stack of the actual MPLS Echo Request message.
本设施的其他用途超出本文件的范围。特别是，本文件中定义的程序仅允许测试由单个FEC组成的FEC堆栈。这些过程也不允许启动器指定分配给该FEC的标签，也不允许启动器将任何附加标签添加到实际MPLS回显请求消息的标签堆栈中。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The term "Must Be Zero" (MBZ) is used in TLV descriptions for reserved fields. These fields MUST be set to zero when sent and ignored on receipt.
术语“必须为零”（MBZ）用于保留字段的TLV描述中。这些字段在发送时必须设置为零，在接收时忽略。
Based on context, the terms "leaf" and "egress" are used interchangeably. "Egress" is used where consistency with [RFC4379] was deemed appropriate. "Receiver" is used in the context of receiving protocol messages.
根据上下文，“叶”和“出口”这两个术语可以互换使用。如果认为与[RFC4379]一致，则使用“出口”。“接收方”用于接收协议消息的上下文中。
Term Definition
----- -------------------------------------------
LSP Label Switched Path
LSR Label Switching Router
mLDP Multipoint LDP
MP2MP Multipoint to Multipoint
MTU Maximum Transmission Unit
P2MP Point to Multipoint
TTL Time to Live
Term Definition
----- -------------------------------------------
LSP Label Switched Path
LSR Label Switching Router
mLDP Multipoint LDP
MP2MP Multipoint to Multipoint
MTU Maximum Transmission Unit
P2MP Point to Multipoint
TTL Time to Live
This document defines a protocol interaction between a first LSR and another LSR that is part of an LSP in order to allow the first LSR to request that the second LSR initiate an LSP Ping for the LSP on the first LSR's behalf. Since the second LSR sends the LSP Ping on behalf of the first LSR, it does not maintain state to be able to handle the corresponding LSP Ping response. Instead, the responder to the LSP Ping sends the LSP Ping response to either the first LSR or another LSR configured to handle it. Two new LSP Ping messages are defined for remote pinging: the MPLS Proxy Ping Request and the MPLS Proxy Ping Reply.
本文档定义了第一LSR和作为LSP一部分的另一LSR之间的协议交互，以允许第一LSR代表第一LSR请求第二LSR为LSP发起LSP Ping。由于第二个LSR代表第一个LSR发送LSP Ping，因此它不能保持能够处理相应LSP Ping响应的状态。相反，LSP Ping的响应者将LSP Ping响应发送到第一个LSR或配置为处理它的另一个LSR。为远程Ping定义了两个新的LSP Ping消息：MPLS代理Ping请求和MPLS代理Ping回复。
A remote ping operation on a P2MP LSP generally involves at least three LSRs; in some scenarios, none of these are the ingress (root) or an egress (leaf) of the LSP.
P2MP LSP上的远程ping操作通常涉及至少三个LSR；在某些场景中，这些都不是LSP的入口（根）或出口（叶）。
We refer to these LSRs with the following terms:
我们使用以下术语来指这些LSR：
Initiator - the LSR that initiates the ping operation by sending an MPLS Proxy Ping Request message
启动器—通过发送MPLS代理ping请求消息来启动ping操作的LSR
Proxy LSR - the LSR that is the destination of the MPLS Proxy Ping Request message and the potential initiator of the MPLS Echo Request
代理LSR—作为MPLS代理Ping请求消息的目标和MPLS回显请求的潜在发起方的LSR
Receiver(s) - the LSR(s) that receive the MPLS Echo Request message
接收方—接收MPLS回显请求消息的LSR
Responder - A receiver that responds to an MPLS Proxy Ping Request or an MPLS Echo Request
响应器-响应MPLS代理Ping请求或MPLS回显请求的接收器
We note that in some scenarios, the initiator could also be the responder; in that case, the response would be internal to the LSR.
我们注意到，在某些场景中，发起者也可能是响应者；在这种情况下，响应将位于LSR内部。
The initiator formats an MPLS Proxy Ping Request message and sends it to the Proxy LSR, an LSR it believes to be on the path of the LSP. This message instructs the Proxy LSR either to reply with Proxy information or to send an MPLS Echo Request in-band of the LSP. The initiator requests Proxy information so that it can learn additional information it needs to use to form a subsequent MPLS Proxy Ping Request. For example, during LSP traceroute, an initiator needs the downstream map information to form an MPLS Echo Request. An initiator may also want to learn a Proxy LSR's FEC neighbor information so that it can form Proxy Ping Requests to various LSRs along the LSP.
发起方格式化MPLS代理Ping请求消息并将其发送到代理LSR，即它认为位于LSP路径上的LSR。此消息指示代理LSR使用代理信息进行回复，或在LSP的频带内发送MPLS回显请求。发起方请求代理信息，以便它可以了解需要用于形成后续MPLS代理Ping请求的其他信息。例如，在LSP跟踪路由期间，发起方需要下游映射信息来形成MPLS回送请求。发起者还可能想要学习代理LSR的FEC邻居信息，以便它能够形成对LSP上的各种LSR的代理Ping请求。
The Proxy LSR either replies with the requested Proxy information or validates that it has a label mapping for the specified FEC and that it is authorized to send the specified MPLS Echo Request on behalf of the initiator.
代理LSR使用请求的代理信息进行回复，或验证其是否具有指定FEC的标签映射，以及是否有权代表启动器发送指定的MPLS回显请求。
If the Proxy LSR has a label mapping for the FEC and all authorization checks have passed, the Proxy LSR formats an MPLS Echo Request. If the source address of the MPLS Echo Request is not set to the Proxy Request source address, the initiator MUST include a Reply-to Address TLV containing the source address to use in the MPLS Echo Request. It then sends the MPLS Echo Request in-band of the LSP.
如果代理LSR具有FEC的标签映射，并且所有授权检查都已通过，则代理LSR将格式化MPLS回显请求。如果MPLS回显请求的源地址未设置为代理请求源地址，则发起方必须包括一个回复地址TLV，其中包含要在MPLS回显请求中使用的源地址。然后，它在LSP的频带内发送MPLS回显请求。
The receivers process the MPLS Echo Request as normal, sending their MPLS Echo Replies back to the initiator.
接收方正常处理MPLS回送请求，将其MPLS回送回复发送回启动器。
If the Proxy LSR failed to send an MPLS Echo Request as normal because it encountered an issue while attempting to send, an MPLS Proxy Ping Reply message is sent back with a Return Code indicating that the MPLS Echo Request could not be sent.
如果代理LSR由于在尝试发送时遇到问题而无法正常发送MPLS回显请求，则会发送一条MPLS代理Ping回复消息，返回代码指示无法发送MPLS回显请求。
As described in Section 4.4 of [RFC4379], if the packet is not well-formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code set to "Malformed echo request received" and the Return Subcode to zero. If there are any TLVs not marked as "Ignore" that the Proxy LSR does not understand, the Proxy LSR SHOULD send an MPLS "TLV not understood" (as appropriate), and the Return Subcode is set to zero.
如[RFC4379]第4.4节所述，如果数据包格式不正确，LSR X应发送MPLS回送回复，返回码设置为“收到格式错误的回送请求”，返回子码设置为零。如果代理LSR不理解任何未标记为“忽略”的TLV，则代理LSR应发送MPLS“TLV未理解”（视情况而定），并且返回子码设置为零。
In the case where the targeted Proxy LSR does not understand the LSP Ping Echo Request at all, like any other LSR that does not understand the messages, it MUST drop the message and MUST NOT send any message back to the initiator.
在目标代理LSR根本不理解LSP Ping Echo请求的情况下，就像任何其他不理解消息的LSR一样，它必须删除消息，并且不得将任何消息发送回启动器。
The initiator creates an MPLS Proxy Ping request message.
启动器创建MPLS代理Ping请求消息。
The message MUST contain a Target FEC Stack that describes the FEC being tested. The topmost FEC in the target FEC stack is used at the Proxy LSR to look up the MPLS label stack that will be used to encapsulate the MPLS Echo Request packet.
消息必须包含描述正在测试的FEC的目标FEC堆栈。目标FEC堆栈中最顶层的FEC在代理LSR处用于查找将用于封装MPLS回送请求数据包的MPLS标签堆栈。
The MPLS Proxy Ping Request message MUST contain a Proxy Echo Parameters TLV. In that TLV, the address type is set to either IPv4 or IPv6. The Destination IP Address is set to the value to be used by the Proxy LSR to build the MPLS Echo Request packet. The MPLS Echo Request IP header destination address is as specified in [RFC4379]. If the Address Type is IPv4, it MUST be an address is from the range 127/8; if the Address Type is IPv6, MUST be an address from the range ::ffff:7f00:0/104.
MPLS代理Ping请求消息必须包含代理回显参数TLV。在该TLV中，地址类型设置为IPv4或IPv6。目标IP地址设置为代理LSR用于构建MPLS回送请求数据包的值。MPLS回显请求IP报头目标地址如[RFC4379]中所述。如果地址类型为IPv4，则必须是127/8范围内的地址；如果地址类型为IPv6，则必须是范围：：ffff:7f00:0/104中的地址。
The Reply Mode and Global Flags of the Proxy Echo Parameters TLV are set to the values to be used in the MPLS Echo Request message header. The Source UDP Port is set to the value to be used in the MPLS Echo Request (the source port is supplied by the Proxy Ping initiator because it or an LSR known to it handles the LSP Ping responses). The TTL is set to the value to be used in the outgoing MPLS label stack. See Section 5.1 for further details.
代理回显参数TLV的应答模式和全局标志设置为MPLS回显请求消息头中使用的值。源UDP端口设置为MPLS回显请求中要使用的值（源端口由代理Ping启动器提供，因为它或已知的LSR处理LSP Ping响应）。TTL设置为要在传出MPLS标签堆栈中使用的值。详见第5.1节。
If the FEC's Upstream/Downstream Neighbor address information is required, the initiator sets the "Request for FEC neighbor information" Proxy Flags in the Proxy Echo Parameters TLV.
如果需要FEC的上游/下游邻居地址信息，则发起方在代理回波参数TLV中设置“请求FEC邻居信息”代理标志。
If a Downstream Detailed Mapping TLV (or Downstream Mapping TLV, which is deprecated) is required in an MPLS Proxy Ping Reply, the initiator sets the "Request for Downstream Detailed Mapping" (or "Request for Downstream Mapping") Proxy Flag in the Proxy Echo Parameters TLV. Only one of the two flags can be set.
如果MPLS代理Ping应答中需要下游详细映射TLV（或不推荐使用的下游映射TLV），则发起方在代理回显参数TLV中设置“请求下游详细映射”（或“请求下游映射”）代理标志。只能设置两个标志中的一个。
The Proxy Request Reply Mode is set with one of the Reply Modes defined in [RFC4379] as appropriate.
代理请求-应答模式根据需要使用[RFC4379]中定义的应答模式之一进行设置。
A list of next-hop IP addresses MAY be included to limit the next hops towards which the MPLS Echo Request message will be sent. These are encoded as Next Hop sub-TLVs and included in the Proxy Echo Parameters TLV.
可以包括下一跳IP地址的列表，以限制MPLS回波请求消息将被发送到的下一跳。这些被编码为下一跳子TLV，并包含在代理回波参数TLV中。
Although not explicitly spelled out in [RFC4379], LSP Ping packets can be formed to a desired size using a Pad TLV and then used to test the Maximum Transmission Unit (MTU) of an LSP. When testing an LSP's MTU, if the message is transported as an IP datagram, the IP header DF bit MUST be set to prevent IP fragmentation by the IP forwarding layer. The Proxy Echo Parameter TLV MPLS Payload Size field is defined for this purpose and may be set to request that the MPLS Echo Request (including any IP and UDP header) be zero-padded to the specified size. When a non-zero MPLS payload size is specified, the Proxy LSR introduces a Pad TLV to build the MPLS Echo Request packet, so in this case, the Proxy Ping Request MUST NOT include a Pad TLV.
尽管[RFC4379]中没有明确说明，但是可以使用Pad TLV将LSP Ping分组形成所需的大小，然后用于测试LSP的最大传输单元（MTU）。测试LSP的MTU时，如果消息作为IP数据报传输，则必须设置IP头DF位，以防止IP转发层造成IP碎片。代理回送参数TLV MPLS Payload Size字段是为此目的定义的，可以设置为请求将MPLS回送请求（包括任何IP和UDP报头）零填充到指定的大小。当指定非零MPLS有效负载大小时，代理LSR引入Pad TLV来构建MPLS回送请求数据包，因此在这种情况下，代理Ping请求不得包括Pad TLV。
Any of following TLVs MAY be included. These TLVs are used to form the MPLS Echo Request messages by the Proxy LSR:
可包括以下任何TLV。这些TLV用于通过代理LSR形成MPLS回显请求消息：
Pad
衬垫
Vendor Enterprise Number
供应商企业编号
Reply TOS Byte
应答TOS字节
P2MP Responder Identifier [RFC6425]
P2MP应答器标识符[RFC6425]
Echo Jitter [RFC6425]
回波抖动[RFC6425]
Vendor Private TLVs
供应商专用TLV
Downstream Detailed Mapping (DDMAP) or Downstream Mapping (DSMAP) TLVs MAY be included. These TLVs will be matched to the next-hop address for inclusion in those particular MPLS Echo Request messages.
可能包括下游详细测绘（DDMAP）或下游测绘（DSMAP）TLV。这些TLV将与下一跳地址相匹配，以包含在这些特定MPLS回送请求消息中。
The message is then encapsulated in a UDP packet. The source UDP port for the MPLS Proxy Ping Request message is chosen by the initiator; the destination UDP port is set to 3503. The IP header is set as follows: the source IP address is a routable address of the initiator; the destination IP address is a routable address to the Proxy LSR. The packet is then sent with the IP TTL set to 255.
然后将消息封装在UDP数据包中。MPLS代理Ping请求消息的源UDP端口由启动器选择；目标UDP端口设置为3503。IP报头设置如下：源IP地址是发起方的可路由地址；目标IP地址是到代理LSR的可路由地址。然后，在IP TTL设置为255的情况下发送数据包。
A Proxy LSR that receives an MPLS Proxy Ping Request message parses the packet to ensure that it is a well-formed packet. It checks that the TLVs that are not marked "Ignore" are understood. If any part of the message is malformed, it sets the Return Code to "Malformed echo request received". If all the TLVs are well-formed and any TLVs are not understood, the Return Code is set to "TLV not understood". The Return Subcode is set to zero for both cases.
接收MPLS代理Ping请求消息的代理LSR解析数据包以确保它是格式良好的数据包。它检查未标记为“忽略”的TLV是否被理解。如果消息的任何部分格式不正确，它会将返回代码设置为“收到格式不正确的回显请求”。如果所有TLV格式良好，且任何TLV都未理解，则返回代码设置为“TLV未理解”。对于这两种情况，返回子代码都设置为零。
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.
如果消息头的回复模式不是1（“不回复”），则应按如下所述发送MPLS代理Ping回复消息。
If the Return Code is "TLV not understood", no more processing of the MPLS Proxy Ping Request message is required. The Proxy LSR sends an MPLS Proxy Ping Reply message with an Errored TLVs TLV containing (only) the TLVs that were not understood.
如果返回代码为“TLV未理解”，则不需要再处理MPLS代理Ping请求消息。代理LSR发送带有错误TLV TLV的MPLS代理Ping回复消息，其中包含（仅）未理解的TLV。
The MPLS Proxy Ping Request is expected to be transported to the Proxy LSR via IP forwarding mechanisms instead of using the same techniques that are employed to inject an MPLS Echo Request packet into an LSP. The MPLS Echo Request would use IP TTL, MPLS TTL, and/or loopback addresses (IPv4 127.x.x.x or IPv6 ::ffff:7f00/104) in the IP header destination address field to trigger the packet to be handled via an LSR's forwarding exception processing path. The Proxy LSR MUST check whether or not MPLS Proxy Ping Request packets arrive via exception path. Packets arriving via IP TTL expiry, IP destination address set to a loopback address, or label TTL expiry MUST be treated as "Unauthorized" packets. An MPLS Proxy Ping Reply message MAY be sent with a Return Code of 16, "Proxy Ping not authorized".
MPLS代理Ping请求期望通过IP转发机制传输到代理LSR，而不是使用用于将MPLS回波请求分组注入LSP的相同技术。MPLS回显请求将使用IP报头目标地址字段中的IP TTL、MPLS TTL和/或环回地址（IPv4 127.x.x.x或IPv6:：ffff:7f00/104）来触发通过LSR的转发异常处理路径处理的数据包。代理LSR必须检查MPLS代理Ping请求数据包是否通过异常路径到达。通过IP TTL到期、设置为环回地址的IP目标地址或标签TTL到期到达的数据包必须视为“未经授权”数据包。发送MPLS代理Ping回复消息时，返回码为16，“代理Ping未授权”。
The header fields Sender's Handle and Sequence Number are not examined, but they are included in the MPLS Proxy Ping Reply or MPLS Echo Request message, if either is sent as a direct result of the received message.
报头字段发送者的句柄和序列号未被检查，但它们包含在MPLS代理Ping应答或MPLS Echo请求消息中，如果其中任何一个是作为收到消息的直接结果发送的。
The Proxy LSR validates that it has a label mapping for the specified FEC, determines if it is an ingress, egress, transit or bud node, and then sets the Return Code as appropriate. A new Return Code of 19, "Replying router has FEC mapping for topmost FEC", has been defined for the case where the Proxy LSR is an ingress (for example, the head of the TE tunnel or a transit router) because the existing Return Codes defined by RFC 4379 don't match the situation. For example, when a Proxy LSR is a transit router, it's not appropriate for the Return Code to describe how the packet would transit because the MPLS
代理LSR验证它是否具有指定FEC的标签映射，确定它是入口、出口、中转还是bud节点，然后根据需要设置返回代码。在代理LSR是入口（例如，TE隧道或中转路由器的头部）的情况下，定义了一个新的返回码19，“应答路由器具有最高FEC的FEC映射”，因为RFC 4379定义的现有返回码与该情况不匹配。例如，当代理LSR是传输路由器时，返回代码不适合描述数据包将如何传输，因为MPLS
Proxy Ping Request doesn't contain information about what input interface the MPLS Echo Request would be switched from at the Proxy LSR.
代理Ping请求不包含有关MPLS回显请求将在代理LSR处从哪个输入接口切换的信息。
The Proxy LSR then determines if it is authorized to send the specified MPLS Echo Request on behalf of the initiator. A Proxy LSR MUST be capable of filtering addresses to validate initiators. Other filters on FECs or MPLS Echo Request contents MAY be applied. If a configured filter has been invoked and an address does not pass the filter, then an MPLS Echo Request message MUST NOT be sent, and the event SHOULD be logged. An MPLS Proxy Ping Reply message MAY be sent with a Return Code of 16, "Proxy Ping not authorized".
然后，代理LSR确定它是否被授权代表发起方发送指定的MPLS回显请求。代理LSR必须能够筛选地址以验证启动器。可以应用FECs或MPLS回波请求内容上的其他过滤器。如果已调用配置的筛选器，且某个地址未通过筛选器，则不得发送MPLS回显请求消息，并应记录该事件。发送MPLS代理Ping回复消息时，返回码为16，“代理Ping未授权”。
The destination address specified in the Proxy Echo Parameters TLV is checked to ensure that it conforms to the allowed IPv4 or IPv6 address range. If not, the Return Code is set to "Malformed echo request received" and the Return Subcode is set to zero. If the Reply Mode of the message header is not 1, an MPLS Proxy Ping Reply message SHOULD be sent as described below.
将检查代理回送参数TLV中指定的目标地址，以确保其符合允许的IPv4或IPv6地址范围。如果不是，则返回代码设置为“收到格式错误的回显请求”，返回子代码设置为零。如果消息头的回复模式不是1，则应按如下所述发送MPLS代理Ping回复消息。
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.
检查代理回波参数TLV中指定的TTL，以确保其包含范围[1255]内的值。如果不是，则返回代码必须设置为17，“需要修改代理Ping参数”。如果消息头的回复模式不是1，则应按如下所述发送MPLS代理Ping回复消息。
If the "Request for FEC Neighbor Address info" flag is set, the Upstream Neighbor Address and Downstream Neighbor Address TLVs are formatted for inclusion in the MPLS Proxy Ping reply. If the Upstream or Downstream address is unknown, the corresponding TLV is omitted.
如果设置了“请求FEC邻居地址信息”标志，则上游邻居地址和下游邻居地址TLV将被格式化以包含在MPLS代理Ping应答中。如果上游或下游地址未知，则省略相应的TLV。
If there are Next Hop sub-TLVs in the Proxy Echo Parameters TLV, each address is examined to determine if it is a valid next hop for this FEC. If any are not, the Proxy Echo Parameters TLV SHOULD be updated to remove unrecognized Next Hop sub-TLVs. The updated Proxy Echo Parameters TLV MUST be included in the MPLS Proxy Ping Reply.
如果代理Echo参数TLV中存在下一跳子TLV，则检查每个地址以确定它是否是此FEC的有效下一跳。如果没有，则应更新代理回显参数TLV，以删除无法识别的下一跳子TLV。更新的代理回显参数TLV必须包含在MPLS代理Ping应答中。
If the "Request for Downstream Detailed Mapping" or "Request for Downstream Mapping" flag is set, the Proxy LSR formats (for inclusion in the MPLS Proxy Ping Reply) a DS/DDMAP TLV for each interface over which the MPLS Echo Request will be sent.
如果设置了“请求下游详细映射”或“请求下游映射”标志，则代理LSR（用于包含在MPLS代理Ping应答中）将为每个将发送MPLS回显请求的接口格式化DS/DDMAP TLV。
If the Proxy LSR is the egress for the FEC, the behavior of the Proxy LSR varies depending on whether the LSR is an egress of a P2P LSP, a P2MP LSP, or MP2MP LSP. Additional details can be found in Section 3.2.1, "Proxy LSR Handling When It Is Egress for FEC".
如果代理LSR是FEC的出口，则代理LSR的行为根据LSR是P2P LSP、P2MP LSP还是MP2MP LSP的出口而变化。更多详情见第3.2.1节“FEC出口时的代理LSR处理”。
If the Reply Mode of the MPLS Proxy Ping Request message header is 1 ("Do not reply"), no MPLS Proxy Ping Reply is sent. Otherwise, an MPLS Proxy Ping Reply message or MPLS Echo Request SHOULD be sent as described below.
如果MPLS代理Ping请求消息头的回复模式为1（“不回复”），则不发送MPLS代理Ping回复。否则，应按如下所述发送MPLS代理Ping回复消息或MPLS回显请求。
This section describes the different behaviors for the Proxy LSR when it's the egress for the FEC. In the P2MP bud node and MP2MP bud node egress cases, different behavior is required.
本节描述代理LSR作为FEC出口时的不同行为。在P2MP bud节点和MP2MP bud节点出口情况下，需要不同的行为。
In the case where an MPLS Echo Request is originated by an LSR that is a bud or egress node of a P2MP/MP2MP, MPLS Echo Replies are returned from downstream/upstream LSRs and will not include an MPLS Echo Reply from the LSR that originated the MPLS Echo Request. This section describes the behavior required at a bud or egress node to return or not return information from MPLS Echo Replies in the Proxy Echo Reply so that no changes are required in implementations that are compliant with [RFC4379]. The Proxy Initiator should receive the same MPLS Echo Replies as in the case of the originator of the LSP Ping; any additional information (such as the Proxy LSR being a bud or egress node) is returned in the MPLS Proxy Ping Reply.
在MPLS回显请求由作为P2MP/MP2MP的bud或出口节点的LSR发起的情况下，MPLS回显回复从下游/上游LSR返回，并且将不包括来自发起MPLS回显请求的LSR的MPLS回显回复。本节描述了bud或出口节点在代理回送回复中从MPLS回送回复返回或不返回信息所需的行为，以便在符合[RFC4379]的实现中不需要更改。代理发起人应收到与LSP Ping发起人相同的MPLS回显回复；在MPLS代理Ping应答中返回任何附加信息（例如代理LSR是bud或出口节点）。
When the Proxy LSR is the egress of a P2P FEC, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the Return Code set to 3, "Replying router is an egress for the FEC at stack-depth", with Return Subcode set to zero.
当代理LSR是P2P FEC的出口时，应向启动器发送MPLS代理Ping应答，返回码设置为3，“应答路由器是堆栈深度FEC的出口”，返回子码设置为零。
When the Proxy LSR is the egress of a P2MP FEC, it can be either a bud node or just an egress. If the Proxy LSR is a bud node, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the return code set to 3, "Replying router is an egress for the FEC at stack-depth", and Return Subcode set to zero. DS/DDMAPs are included only if the Proxy Initiator requested information be returned in an MPLS Proxy Ping Reply. If the Proxy LSR is a bud node but there has not been a request to return an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send MPLS Echo Request packet(s) to the downstream neighbors (no MPLS Echo Reply is sent to the Proxy Initiator to indicate that the Proxy LSR is an egress). If the Proxy LSR is just an egress, an MPLS Proxy Ping Reply SHOULD be sent to the initiator with the Return Code set to 3, "Replying router is an egress for the FEC at stack-depth", and Return Subcode set to zero.
当代理LSR是P2MP FEC的出口时，它可以是bud节点，也可以只是出口。如果代理LSR是bud节点，则应向启动器发送MPLS代理Ping应答，返回码设置为3，“应答路由器是堆栈深度FEC的出口”，返回子码设置为零。仅当代理启动器请求在MPLS代理Ping回复中返回信息时，才会包括DS/DDMAP。如果代理LSR是bud节点，但没有返回MPLS代理Ping应答的请求，则代理LSR应向下游邻居发送MPLS回显请求数据包（没有向代理启动器发送MPLS回显应答以指示代理LSR是出口）。如果代理LSR只是一个出口，则应向启动器发送MPLS代理Ping应答，返回码设置为3，“应答路由器是堆栈深度FEC的出口”，返回子码设置为零。
When the Proxy LSR is the egress of a MP2MP FEC, it can be either a bud node or just an egress. LSP Pings sent from a leaf of a MP2MP have different behavior in this case. MPLS Echo Requests are sent to all upstream/downstream neighbors. The Proxy LSRs need to be consistent with this variation in behavior. If the Proxy LSR is a
当代理LSR是MP2MP FEC的出口时，它可以是bud节点，也可以只是出口。在这种情况下，从MP2MP的叶发送的LSP ping具有不同的行为。MPLS回显请求被发送到所有上游/下游邻居。代理LSR需要与这种行为变化保持一致。如果代理LSR是
bud node or just an egress, an MPLS Proxy Ping Reply SHOULD be sent to the Proxy Initiator with the return code set to 3, "Replying router is an egress for the FEC at stack-depth", with Return Subcode set to zero and DS/DDMAPs included only if the Proxy Initiator requested information be returned in an MPLS Proxy Ping Reply. If the Proxy LSR is not requested to return information in an MPLS Proxy Ping Reply, the Proxy LSR SHOULD send MPLS Echo Request packets to all upstream/downstream neighbors as would be done when sourcing an LSP Ping from a MP2MP leaf (no MPLS Echo Reply is sent to the Proxy Initiator indicating that the Proxy LSR is an egress).
bud node或只是一个出口，MPLS代理Ping回复应发送给代理启动器，返回码设置为3，“应答路由器是堆栈深度FEC的出口”，返回子码设置为零，仅当代理启动器请求在MPLS代理Ping回复中返回信息时才包括DS/DDMAP。如果未请求代理LSR在MPLS代理Ping应答中返回信息，则代理LSR应向所有上游/下游邻居发送MPLS回显请求数据包，就像从MP2MP叶寻找LSP Ping时所做的那样（未向代理启动器发送MPLS回显应答，指示代理LSR是出口）。
When the Proxy LSR is a transit or bud node, downstream maps corresponding to how the packet is transited cannot be supplied unless an ingress interface for the MPLS Echo Request is specified. Since this information is not available and all valid output paths are of interest, the Proxy LSR SHOULD include DS/DDMAP(s) to describe the entire set of paths that the packet can be replicated. This is similar to the case in which an LSP Ping is initiated at the Proxy LSR. For mLDP, there is a DS/DDMAP per upstream/downstream neighbor for MP2MP LSPs, or per downstream neighbor in the P2MP LSP case.
当代理LSR是传输节点或bud节点时，除非为MPLS回送请求指定了入口接口，否则无法提供与数据包传输方式相对应的下游映射。由于该信息不可用，并且所有有效的输出路径都值得关注，因此代理LSR应该包括DS/DDMAP，以描述数据包可以复制的整个路径集。这类似于在代理LSR处启动LSP Ping的情况。对于mLDP，对于MP2MP LSP，每个上游/下游邻居都有DS/DDMAP，对于P2MP LSP，每个下游邻居都有DS/DDMAP。
When the Proxy LSR is a bud node or egress in an MP2MP LSP or a bud node in a P2MP LSP, an LSP Ping initiated from the Proxy LSR would source packets only to the neighbors but not itself, despite the fact that the Proxy LSR is itself an egress for the FEC. In order to match the behavior as seen from LSP Ping initiated at the Proxy LSR, the Proxy Reply SHOULD contain DS/DDMAPs for only the paths to the upstream/downstream neighbors, but no DS/DDMAP describing its own egress paths. The proxy LSR identifies that it's an egress for the FEC using a different Proxy Reply Return Code. The Proxy Reply Return Code is either set to 19, "Replying router has FEC mapping for topmost FEC", or 3, "Replying router is an egress for the FEC at stack-depth".
当代理LSR是MP2MP LSP中的bud节点或出口或P2MP LSP中的bud节点时，从代理LSR发起的LSP Ping将仅向邻居而不是自身发送分组，尽管代理LSR本身是FEC的出口。为了匹配从代理LSR启动的LSP Ping中看到的行为，代理回复应该只包含到上游/下游邻居的路径的DS/DDMAP，而不包含描述其自身出口路径的DS/DDMAP。代理LSR使用不同的代理回复返回码标识它是FEC的出口。代理应答返回码设置为19，“应答路由器具有最顶层FEC的FEC映射”，或3，“应答路由器是堆栈深度FEC的出口”。
The Reply Mode, Sender's Handle, and Sequence Number fields are copied from the Proxy Ping Request message. The TLVs specified above are included. The message is encapsulated in a UDP packet. The source IP address is a routable address of the Proxy LSR; the source port is the well-known UDP port for LSP Ping. The destination IP address and UDP port are copied from the source IP address and UDP port of the MPLS Proxy Ping Request. The IP TTL is set to 255.
应答模式、发送方句柄和序列号字段从代理Ping请求消息中复制。包括上述规定的TLV。消息被封装在UDP数据包中。源IP地址是代理LSR的可路由地址；源端口是众所周知的用于LSP Ping的UDP端口。从MPLS代理Ping请求的源IP地址和UDP端口复制目标IP地址和UDP端口。IP TTL设置为255。
An MPLS Echo Request is formed as described in the next section. The section below describes how the MPLS Echo Request is sent on each interface.
如下一节所述形成MPLS回送请求。以下部分描述了如何在每个接口上发送MPLS回显请求。
If Next Hop sub-TLVs were included in the received Proxy Echo Parameters TLV, the Next_Hop_List is created from the addresses in those sub-TLVs adjusted as described in Section 3.2. Otherwise, the list is set to all the next hops to which the FEC would be forwarded.
如果接收到的代理回波参数TLV中包括下一跳子TLV，则根据第3.2节中所述调整的子TLV中的地址创建下一跳列表。否则，该列表被设置为FEC将转发到的所有下一跳。
The Proxy LSR then formats an MPLS Echo Request message. The Global Flags and Reply Mode are copied from the Proxy Echo Parameters TLV. The Return Code and Return Subcode are set to zero.
然后，代理LSR格式化MPLS回显请求消息。全局标志和应答模式从代理回送参数TLV复制。返回代码和返回子代码设置为零。
The Sender's Handle and Sequence Number are copied from the remote MPLS Echo Request message.
发送方的句柄和序列号从远程MPLS回显请求消息中复制。
The TimeStamp Sent is set to the time of day (in seconds and microseconds) that the MPLS Echo Request is sent. The TimeStamp Received is set to zero.
发送的时间戳设置为发送MPLS回显请求的时间（以秒和微秒为单位）。接收的时间戳设置为零。
If the Reply-to Address TLV is present, it is used to set the MPLS Echo Request source address; otherwise, the MPLS Echo Request source address is set to the Proxy Request source address.
如果存在回复地址TLV，则用于设置MPLS回送请求源地址；否则，将MPLS回显请求源地址设置为代理请求源地址。
The following TLVs are copied from the MPLS Proxy Ping Request message. Note that, of these, only the Target FEC Stack is REQUIRED to appear in the MPLS Proxy Ping Request message. The Pad TLV is not copied if the Proxy Echo Parameter TLV MPLS payload size is set to a non-zero value.
以下TLV是从MPLS代理Ping请求消息复制的。注意，其中，只有目标FEC堆栈需要出现在MPLS代理Ping请求消息中。如果代理回波参数TLV MPLS有效负载大小设置为非零值，则不会复制Pad TLV。
Target FEC Stack
目标FEC堆栈
Pad
衬垫
Vendor Enterprise Number
供应商企业编号
Reply TOS Byte
应答TOS字节
P2MP Responder Identifier [RFC6425]
P2MP应答器标识符[RFC6425]
Echo Jitter [RFC6425]
回波抖动[RFC6425]
Vendor Private TLVs
供应商专用TLV
If the Proxy Echo Parameter TLV MPLS payload size is non-zero, the Proxy LSR introduces a Pad TLV such that size of the MPLS Echo Request (including any IP and UDP header) is zero-padded to the specified MPLS payload size. The first octet in the Value part of the Pad TLV is set to 1, "Drop Pad TLV from reply", and the remaining octets of the Value part of the Pad TLV are filled with zeros. If the IP header is used to encapsulate the MPLS Echo Request, the DF bit MUST be set to one.
如果代理回送参数TLV MPLS有效负载大小为非零，则代理LSR将引入Pad TLV，以便将MPLS回送请求（包括任何IP和UDP标头）的大小零填充到指定的MPLS有效负载大小。焊盘TLV值部分的第一个八位字节设置为1，“从应答中删除焊盘TLV”，焊盘TLV值部分的其余八位字节用零填充。如果IP报头用于封装MPLS回送请求，则DF位必须设置为1。
The message is then encapsulated in a UDP packet. The source UDP port is copied from the Proxy Echo Parameters TLV. The destination port is copied from the MPLS Proxy Ping Request message.
然后将消息封装在UDP数据包中。源UDP端口是从代理回显参数TLV复制的。从MPLS代理Ping请求消息复制目标端口。
The source IP address is set to a routable address specified in the Reply-to Address TLV or the source address of the received Proxy Request. Per usual, the TTL of the IP packet is set to 1.
源IP地址设置为回复地址TLV中指定的可路由地址或接收到的代理请求的源地址。通常，IP数据包的TTL设置为1。
If the Explicit Differentiated Services Code Point (DSCP) flag is set, the Requested DSCP byte is examined. If the setting is permitted, then the DSCP byte of the IP header of the MPLS Echo Request message is set to that value. If the Proxy LSR does not permit explicit control for the DSCP byte, the MPLS Proxy Echo Parameters with the Explicit DSCP flag cleared MUST be included in any MPLS Proxy Ping Reply message to indicate why an MPLS Echo Request was not sent. The Return Code MUST be set to 17, "Proxy Ping parameters need to be modified". If the Explicit DSCP flag is not set, the Proxy LSR SHOULD set the MPLS Echo Request DSCP settings to the value normally used to source LSP Ping packets.
如果设置了显式区分服务代码点（DSCP）标志，则会检查请求的DSCP字节。如果允许该设置，则将MPLS回送请求消息的IP头的DSCP字节设置为该值。如果代理LSR不允许显式控制DSCP字节，则清除显式DSCP标志的MPLS代理回显参数必须包含在任何MPLS代理Ping回复消息中，以指示未发送MPLS回显请求的原因。返回代码必须设置为17，“需要修改代理Ping参数”。如果未设置显式DSCP标志，则代理LSR应将MPLS回显请求DSCP设置设置为通常用于源LSP Ping数据包的值。
The Proxy LSR now iterates through the Next_Hop_List modifying the base MPLS Echo Request to form the MPLS Echo Request packet that is then sent on that particular interface.
代理LSR现在迭代下一跳列表，修改基本MPLS回显请求，以形成MPLS回显请求包，然后在该特定接口上发送。
The outgoing label stack is determined for each next-hop address. The TTL for the label corresponding to the FEC specified in the FEC stack is set such that the TTL on the wire will be the TTL specified in the Proxy Echo Parameters. If any additional labels are pushed onto the stack, their TTLs are set to 255. This will ensure that the requestor will not have control over tunnels not relevant to the FEC being tested.
为每个下一跳地址确定传出标签堆栈。设置与FEC堆栈中指定的FEC对应的标签的TTL，以便导线上的TTL将是代理回波参数中指定的TTL。如果将任何其他标签推送到堆栈上，则其TTL设置为255。这将确保请求者不会控制与正在测试的FEC无关的隧道。
If the MPLS Proxy Ping Request message contained Downstream Mapping TLVs or Downstream Detailed Mapping TLVs, they are examined. If the Downstream IP address matches the next-hop address, that Downstream Mapping TLV is included in the MPLS Echo Request.
如果MPLS代理Ping请求消息包含下游映射TLV或下游详细映射TLV，则会对其进行检查。如果下游IP地址与下一跳地址匹配，则该下游映射TLV将包含在MPLS回显请求中。
The packet is then transmitted on this interface.
然后在该接口上传输数据包。
This document defines two new LSP Ping messages, the MPLS Proxy Ping Request and the MPLS Proxy Ping Reply.
本文档定义了两条新的LSP Ping消息，即MPLS代理Ping请求和MPLS代理Ping回复。
The packet format is as defined in [RFC4379]. Two new message types, Proxy Ping Request and Reply, are being added.
数据包格式如[RFC4379]中所定义。正在添加两种新的消息类型：代理Ping请求和回复。
Message Type
消息类型
Type Message
---- -------
3 MPLS Proxy Ping Request
4 MPLS Proxy Ping Reply
Type Message
---- -------
3 MPLS Proxy Ping Request
4 MPLS Proxy Ping Reply
The MPLS Proxy Ping Request message MAY contain the following TLVs:
MPLS代理Ping请求消息可能包含以下TLV：
Type TLV
---- -----------
1 Target FEC Stack
2 Downstream Mapping (DEPRECATED)
3 Pad
5 Vendor Enterprise Number
10 Reply TOS Byte
11 P2MP Responder Identifier [RFC6425]
12 Echo Jitter [RFC6425]
20 Downstream Detailed Mapping
21 Reply Path [RFC7110]
22 Reply TC [RFC7110]
23 Proxy Echo Parameters
24 Reply-to Address
* Vendor Private TLVs
Type TLV
---- -----------
1 Target FEC Stack
2 Downstream Mapping (DEPRECATED)
3 Pad
5 Vendor Enterprise Number
10 Reply TOS Byte
11 P2MP Responder Identifier [RFC6425]
12 Echo Jitter [RFC6425]
20 Downstream Detailed Mapping
21 Reply Path [RFC7110]
22 Reply TC [RFC7110]
23 Proxy Echo Parameters
24 Reply-to Address
* Vendor Private TLVs
* TLVs types in the Vendor Private TLV Space MUST be ignored if not understood
* 如果无法理解，则必须忽略供应商专用TLV空间中的TLV类型
The MPLS Proxy Ping Reply message MAY contain the following TLVs:
MPLS代理Ping回复消息可能包含以下TLV：
Type TLV
---- -----------
1 Target FEC Stack
2 Downstream Mapping (DEPRECATED)
5 Vendor Enterprise Number
9 Errored TLVs
20 Downstream Detailed Mapping
23 Proxy Echo Parameters
25 Upstream Neighbor Address
26 Downstream Neighbor Address (0 or more)
* Vendor Private TLVs
Type TLV
---- -----------
1 Target FEC Stack
2 Downstream Mapping (DEPRECATED)
5 Vendor Enterprise Number
9 Errored TLVs
20 Downstream Detailed Mapping
23 Proxy Echo Parameters
25 Upstream Neighbor Address
26 Downstream Neighbor Address (0 or more)
* Vendor Private TLVs
* TLVs types in the Vendor Private TLV Space MUST be ignored if not understood
* 如果无法理解，则必须忽略供应商专用TLV空间中的TLV类型
The Proxy Echo Parameters TLV is a TLV that MUST be included in an MPLS Proxy Ping Request message. The length of the TLV is 12 + K + S, where K is the length of the Destination IP Address field and S is the total length of the sub-TLVs. The Proxy Echo Parameters TLV can be used either to 1) control attributes used in composing and sending an MPLS Echo Request or 2) query the Proxy LSR for information about the topmost FEC in the target FEC stack, but not both. In the case where the Proxy LSR is being queried (i.e., information needs to be returned in an MPLS Proxy Ping Reply), no MPLS Echo Request will be sent from the Proxy LSR. The MPLS Proxy Ping Request Proxy Echo Parameters TLV's Proxy Flags SHOULD be set appropriately, as described below.
代理回显参数TLV是必须包含在MPLS代理Ping请求消息中的TLV。TLV的长度为12+K+S，其中K是目标IP地址字段的长度，S是子TLV的总长度。代理回送参数TLV可用于1）控制组成和发送MPLS回送请求时使用的属性，或2）查询代理LSR以获取有关目标FEC堆栈中最顶层FEC的信息，但不能同时使用这两个参数。在查询代理LSR的情况下（即，需要在MPLS代理Ping应答中返回信息），将不会从代理LSR发送MPLS回显请求。应适当设置MPLS代理Ping请求代理回波参数TLV的代理标志，如下所述。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Reply Mode | Proxy Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Rqst'd DSCP | Source UDP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Flags | MPLS Payload Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Destination IP Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Sub-TLVs :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Reply Mode | Proxy Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Rqst'd DSCP | Source UDP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Flags | MPLS Payload Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Destination IP Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
: Sub-TLVs :
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type
地址类型
The type and length of the address found in the in the Destination IP Address and Next Hop IP Addresses fields. The values are shared with the Downstream Mapping Address Type Registry.
在目标IP地址和下一跳IP地址字段中找到的地址的类型和长度。这些值与下游映射地址类型注册表共享。
The type codes applicable in this case appear in the table below:
适用于这种情况的类型代码如下表所示：
Address Family Type Length
地址族类型长度
IPv4 1 4 IPv6 3 16
IPv4 1 4 IPv6 3 16
Reply Mode
答复方式
The reply mode to be sent in the MPLS Echo Request message; the values are as specified in [RFC4379].
MPLS回显请求报文中发送的应答方式；这些值如[RFC4379]中所规定。
Proxy Flags
代理标志
The Proxy Request Initiator sets zero, one, or more of these flags to request actions at the Proxy LSR.
代理请求启动器设置零、一个或多个这些标志，以在代理LSR上请求操作。
0x0001 Request for FEC Neighbor Address info
0x0001请求FEC邻居地址信息
When set, this requests that the Proxy LSR supply the Upstream and Downstream neighbor address information in the MPLS Proxy Ping Reply message. This flag is only applicable
设置后，请求代理LSR在MPLS代理Ping回复消息中提供上游和下游邻居地址信息。此标志仅适用
for the topmost FEC in the FEC stack if the FEC type corresponds with a P2MP or MP2MP LSP. The Proxy LSR MUST respond (as applicable) with Upstream Neighbor Address and Downstream Neighbor Address TLV(s) in the MPLS Proxy Ping Reply message. The Upstream Neighbor Address TLV needs be included only if there is an upstream neighbor. Similarly, one Downstream Neighbor Address TLV needs to be included for each Downstream Neighbor from which the LSR learned bindings.
如果FEC类型对应于P2MP或MP2MP LSP，则为FEC堆栈中最顶层的FEC。代理LSR必须在MPLS代理Ping回复消息中使用上游邻居地址和下游邻居地址TLV进行响应（如适用）。仅当存在上游邻居时，才需要包括上游邻居地址TLV。类似地，LSR从中学习绑定的每个下游邻居都需要包含一个下游邻居地址TLV。
Setting this flag will cause the Proxy LSR to cancel sending any MPLS Echo Request. The initiator may use information learned from the MPLS Proxy Ping Reply that is sent instead to generate subsequent proxy requests.
设置此标志将导致代理LSR取消发送任何MPLS回显请求。发起方可以使用从发送的MPLS代理Ping应答中学习到的信息来生成后续代理请求。
0x0002 Request for Downstream Mapping
0x0002下游映射请求
When set, this requests that the Proxy LSR supply a Downstream Mapping TLV (see [RFC4379]) in the MPLS Proxy Ping Reply message. Either this flag may be set or the "Request for Downstream Detailed Mapping" flag may be set, but not both.
设置后，请求代理LSR在MPLS代理Ping回复消息中提供下游映射TLV（请参见[RFC4379]）。可以设置此标志或“请求下游详细映射”标志，但不能同时设置两者。
Setting this flag will cause the Proxy LSR to cancel sending an MPLS Echo Request. Information learned with such a Proxy Reply may be used by the Proxy Initiator to generate subsequent Proxy Requests.
设置此标志将导致代理LSR取消发送MPLS回显请求。代理发起者可以使用通过这种代理回复学习到的信息来生成后续代理请求。
0x0004 Request for Downstream Detailed Mapping
0x0004下游详细映射请求
When set, this requests that the Proxy LSR supply a Downstream Detailed Mapping TLV (see [RFC6424]) in the MPLS Proxy Ping Reply message. It's not valid to have the "Request for Downstream Mapping" flag set when this flag is set. Setting this flag will cause the Proxy LSR to cancel sending an MPLS Echo Request. The initiator may use information learned from the MPLS Proxy Ping Reply that is sent instead to generate subsequent proxy requests.
设置后，请求代理LSR在MPLS代理Ping回复消息中提供下游详细映射TLV（请参见[RFC6424]）。设置此标志时，设置“请求下游映射”标志无效。设置此标志将导致代理LSR取消发送MPLS回显请求。发起方可以使用从发送的MPLS代理Ping应答中学习到的信息来生成后续代理请求。
0x0008 Explicit DSCP Request
0x0008显式DSCP请求
When set, this requests that the Proxy LSR use the supplied "Rqst'd DSCP" byte in the Echo Request message
设置后，请求代理LSR在回显请求消息中使用提供的“Rqst'd DSCP”字节
TTL
TTL
The TTL to be used in the label stack entry corresponding to the topmost FEC in the MPLS Echo Request packet. Valid values are in the range [1,255].
要在标签堆栈条目中使用的TTL，对应于MPLS回送请求数据包中最顶层的FEC。有效值在[1255]范围内。
Requested DSCP
请求的DSCP
This field is valid only if the Explicit DSCP flag is set. If not set, the field MUST be zero on transmission and ignored on receipt. When the flag is set, this field contains the DSCP value to be used in the MPLS Echo Request packet IP header.
仅当设置了显式DSCP标志时，此字段才有效。如果未设置，则该字段在传输时必须为零，在接收时必须忽略。设置标志时，此字段包含要在MPLS回显请求数据包IP报头中使用的DSCP值。
Source UDP Port
源UDP端口
The source UDP port to be sent in the MPLS Echo Request packet
要在MPLS回显请求数据包中发送的源UDP端口
Global Flags
全球旗帜
The Global Flags to be sent in the MPLS Echo Request message
要在MPLS回显请求消息中发送的全局标志
MPLS Payload Size
MPLS有效负载大小
Used to request that the MPLS payload (IP header + UDP header + MPLS Echo Request) be padded using a zero-filled Pad TLV so that the IP header, UDP header, and MPLS Echo Request total the specified size. Having the field set to zero means no size request is being made. If the requested size is less than the minimum size required to form the MPLS Echo Request, the request will be treated as a best-effort request with the Proxy LSR building the smallest possible packet (i.e., not using a Pad TLV). The IP header DF bit MUST be set when this field is non-zero.
用于请求使用零填充的Pad TLV填充MPLS有效负载（IP标头+UDP标头+MPLS回显请求），以便IP标头、UDP标头和MPLS回显请求的总大小达到指定的大小。将字段设置为零意味着没有进行大小请求。如果请求的大小小于形成MPLS回波请求所需的最小大小，则该请求将被视为尽力而为的请求，代理LSR构建最小的可能分组（即，不使用Pad TLV）。当此字段非零时，必须设置IP标头DF位。
Destination IP Address
目的地址
If the Address Type is IPv4, an address from the range 127/8;
if the Address Type is IPv6, an address from the range
::ffff:7f00:0/104
If the Address Type is IPv4, an address from the range 127/8;
if the Address Type is IPv6, an address from the range
::ffff:7f00:0/104
Sub-TLVs
子TLV
List of TLV-encoded sub-TLVs. Currently one is defined.
TLV编码子TLV的列表。目前定义了一个。
Sub-Type Length Sub-TLV Name
-------- ------ ------------
1 8+ Next Hop
Sub-Type Length Sub-TLV Name
-------- ------ ------------
1 8+ Next Hop
This sub-TLV is used to describe a particular next hop towards which the Echo Request packet should be sent. If the topmost FEC in the FEC stack is a multipoint LSP, this sub-TLV may appear multiple times.
此子TLV用于描述应向其发送回声请求数据包的特定下一跳。如果FEC堆栈中最顶层的FEC是多点LSP，则该子TLV可能会出现多次。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Type | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Interface (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Type | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Interface (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type
地址类型
Type Type of Next Hop Addr Length Interface Field (IF) Length 1 IPv4 Numbered 4 4 2 IPv4 Unnumbered 4 4 3 IPv6 Numbered 16 16 4 IPv6 Unnumbered 16 4 5 Reserved 6 IPv4 Protocol Adj 4 0 7 IPv6 Protocol Adj 16 0
类型下一跳地址类型长度接口字段（IF）长度1 IPv4编号4 4 2 IPv4未编号4 4 3 IPv6编号16 16 4 IPv6未编号16 4 5保留6 IPv4协议调整4 0 7 IPv6协议调整16 0
Note: Types 1-4 correspond to the types in the DSMAP TLV. They are expected to be populated with information obtained through a previously returned DSMAP TLV. Types 6 and 7 are intended to be populated from the local address information obtained from a previously returned Downstream Neighbor Address TLV or Upstream Neighbor Address TLV.
注：类型1-4对应于DSMAP TLV中的类型。它们预计将填充通过先前返回的DSMAP TLV获得的信息。类型6和7旨在根据从先前返回的下游邻居地址TLV或上游邻居地址TLV获得的本地地址信息填充。
Next Hop IP Address
下一跳IP地址
A next hop address that the Echo Request message is to be sent towards
回显请求消息要发送到的下一跳地址
Next Hop Interface
下一跳接口
Identifier of the interface through which the Echo Request message is to be sent. For Addr Type 5 and 6, the Next Hop interface field isn't used and MUST be of an associated byte length of zero octets.
发送回显请求消息的接口的标识符。对于Addr类型5和6，不使用下一跳接口字段，该字段的关联字节长度必须为零个八位字节。
Used to specify the MPLS Echo Request IP source address. This address MUST be IP reachable via the Proxy LSR; otherwise, it will be rejected.
用于指定MPLS回显请求IP源地址。该地址必须可以通过代理LSR通过IP访问；否则将被拒绝。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Reply-to Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Reply-to Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type
地址类型
A type code as specified in the table below:
下表中规定的类型代码：
Type Type of Address
地址类型
1 IPv4 3 IPv6
1 IPv4 3 IPv6
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Upst Addr Type |Local Addr Type| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Upstream Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Local Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Upst Addr Type |Local Addr Type| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Upstream Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Local Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upst Addr Type; Local Addr Type
Upst-Addr型；本地地址类型
These two fields determine the type and length of the respective addresses. The codes are specified in the table below:
这两个字段确定各自地址的类型和长度。下表规定了代码：
Type Type of Address Length
地址长度类型
0 No Address Supplied 0 1 IPv4 4 3 IPv6 16
0未提供地址0 1 IPv4 4 3 IPv6 16
Upstream Address
上行地址
The address of the immediate upstream neighbor for the topmost FEC in the FEC stack. If the protocol adjacency exists by which the label for this FEC was exchanged, this address MUST be the address used in that protocol exchange.
FEC堆栈中最顶层FEC的直接上游邻居的地址。如果存在交换此FEC标签的协议邻接，则此地址必须是该协议交换中使用的地址。
Local Address
本地地址
The local address used in the protocol adjacency by which the label for this FEC was exchanged.
协议邻接中使用的本地地址，用于交换此FEC的标签。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Dnst Addr Type |Local Addr Type| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Downstream Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Local Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Dnst Addr Type |Local Addr Type| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Downstream Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Local Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dnst Addr Type; Local Addr Type
Dnst-Addr型；本地地址类型
These two fields determine the type and length of the respective addresses. The codes are specified in the table below:
这两个字段确定各自地址的类型和长度。下表规定了代码：
Type Type of Address Length
地址长度类型
0 No Address Supplied 0 1 IPv4 4 3 IPv6 16
0未提供地址0 1 IPv4 4 3 IPv6 16
Downstream Address
下游地址
The address of an immediate downstream neighbor for the topmost FEC in the FEC stack. If the protocol adjacency exists by which the label for this FEC was exchanged, this address MUST be the address used in that protocol exchange.
FEC堆栈中最顶层FEC的直接下游邻居的地址。如果存在交换此FEC标签的协议邻接，则此地址必须是该协议交换中使用的地址。
Local Address
本地地址
The local address used in the protocol adjacency by which the label for this FEC was exchanged.
协议邻接中使用的本地地址，用于交换此FEC的标签。
The mechanisms described in this document are intended to be used within a service provider network and to be initiated only under the authority of that administration.
本文件中描述的机制旨在在服务提供商网络中使用，并且仅在该管理部门的授权下启动。
If such a network also carries Internet traffic, or permits IP access from other administrations, the MPLS Proxy Ping message SHOULD be discarded at the points where IP packets are received from other administrations. This can be accomplished by filtering on source address or by filtering all MPLS ping messages on UDP port.
如果这样的网络也承载因特网通信量，或者允许来自其他管理的IP访问，那么MPLS代理Ping消息应该在从其他管理接收IP分组的点处被丢弃。这可以通过在源地址上过滤或通过在UDP端口上过滤所有MPLS ping消息来实现。
Any node that acts as a Proxy LSR SHOULD validate requests against a set of valid source addresses. An implementation MUST provide such filtering capabilities.
任何充当代理LSR的节点都应该根据一组有效的源地址验证请求。实现必须提供这种过滤功能。
MPLS Proxy Ping Request messages are IP addressed directly to the Proxy LSR. If a Proxy LSR receives an MPLS Proxy Ping message via expiration of the IP or Label Stack Entry TTL, it MUST NOT be acted upon.
MPLS代理Ping请求消息直接通过IP地址发送到代理LSR。若代理LSR通过IP到期或标签堆栈项TTL收到MPLS代理Ping消息，则不得对其采取行动。
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.
如果代理LSR无法通过IP访问MPLS代理Ping请求IP源地址，则不得对代理请求采取行动。
MPLS Proxy Ping Requests are limited to making their request via the specification of a FEC. This ensures that only valid MPLS Echo Request messages can be created. No label-spoofing attacks are possible.
MPLS代理Ping请求仅限于通过FEC规范发出请求。这确保只能创建有效的MPLS回显请求消息。不可能发生标签欺骗攻击。
Per this document, IANA has made the following assignments.
根据本文件，IANA已完成以下任务。
MPLS LSP Ping Message Types
MPLS LSP Ping消息类型
Value Meaning
----- -------
3 MPLS Proxy Ping Request
4 MPLS Proxy Ping Reply
Value Meaning
----- -------
3 MPLS Proxy Ping Request
4 MPLS Proxy Ping Reply
TLVs
阈限值
Type TLV Name
---- --------
23 Proxy Echo Parameters
24 Reply-to Address
25 Upstream Neighbor Address
26 Downstream Neighbor Address
Type TLV Name
---- --------
23 Proxy Echo Parameters
24 Reply-to Address
25 Upstream Neighbor Address
26 Downstream Neighbor Address
Return Codes
返回码
Value Meaning
----- -------
16 Proxy Ping not authorized
17 Proxy Ping parameters need to be modified
18 MPLS Echo Request could not be sent
19 Replying router has FEC mapping for topmost FEC
Value Meaning
----- -------
16 Proxy Ping not authorized
17 Proxy Ping parameters need to be modified
18 MPLS Echo Request could not be sent
19 Replying router has FEC mapping for topmost FEC
The IANA has created and maintains this new registry for Proxy Echo Parameters Sub-TLVs. Assignments will use the same rules spelled out in Section 7.2 of [RFC4379].
IANA已经为代理回声参数子TLV创建并维护了这个新的注册表。作业将使用[RFC4379]第7.2节中规定的相同规则。
Sub-Type Sub-TLV Name
-------- ------------
0 Reserved
1 Next Hop
Sub-Type Sub-TLV Name
-------- ------------
0 Reserved
1 Next Hop
IANA has created and maintains a new registry for the Proxy Flags that are used with the Proxy Echo Parameters TLV. See Section 5.1 for details. The registry is in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "Multiprotocol Label Switching Architecture (MPLS)" name space. The registration procedure is Standards Action [RFC5226]. The initial values are as follows.
IANA已为代理回显参数TLV使用的代理标志创建并维护了一个新的注册表。详见第5.1节。注册表位于“多协议标签交换体系结构（MPLS）”名称空间中的“多协议标签交换（MPLS）标签交换路径（LSPs）Ping参数”注册表中。注册程序为标准行动[RFC5226]。初始值如下所示。
Bit Number Name
---------- ----
0 Request for FEC Neighbor Address info
1 Request for Downstream Mapping
2 Request for Downstream Detailed Mapping
3 Explicit DSCP Request
4-15 Unassigned
Bit Number Name
---------- ----
0 Request for FEC Neighbor Address info
1 Request for Downstream Mapping
2 Request for Downstream Detailed Mapping
3 Explicit DSCP Request
4-15 Unassigned
This document makes the following assignments in the Downstream Address Mapping Registry. This document updates the registry defined by [RFC6426]. The registration procedure remains Standards Action and a note has been added as follows:
本文档在下游地址映射注册表中进行以下分配。本文档更新了[RFC6426]定义的注册表。注册程序仍然是标准行动，并添加了如下注释：
When a code point is assigned that is not also assigned in the Next Hop Address Type Registry, the code point there must be marked "Reserved".
当分配的代码点未在下一跳地址类型注册表中分配时，该代码点必须标记为“保留”。
Type # Address Type K Octets
------ ------------ --------
6 Reserved N/A RFC 7555
7 Reserved N/A RFC 7555
Type # Address Type K Octets
------ ------------ --------
6 Reserved N/A RFC 7555
7 Reserved N/A RFC 7555
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:
IANA创建了一个名为“下一跳地址类型注册表”的新注册表。此注册表的分配策略是标准操作。此外，增加了如下注释：
When a code point is assigned that is not also assigned in the Downstream Address Mapping Registry, the code point there must be marked "Reserved".
当分配的代码点未在下游地址映射注册表中分配时，该代码点必须标记为“保留”。
The initial allocations are:
初步拨款为：
Type Type of Next Hop Addr Length IF Length Reference
类型下一跳地址长度的类型如果长度引用
1 IPv4 Numbered 4 4 [RFC4379]
2 IPv4 Unnumbered 4 4 [RFC4379]
3 IPv6 Numbered 16 16 [RFC4379]
4 IPv6 Unnumbered 16 4 [RFC4379]
5 Reserved RFC 7555
6 IPv4 Protocol Adj 4 0 RFC 7555
7 IPv6 Protocol Adj 16 0 RFC 7555
8-255 Unassigned
1 IPv4 Numbered 4 4 [RFC4379]
2 IPv4 Unnumbered 4 4 [RFC4379]
3 IPv6 Numbered 16 16 [RFC4379]
4 IPv6 Unnumbered 16 4 [RFC4379]
5 Reserved RFC 7555
6 IPv4 Protocol Adj 4 0 RFC 7555
7 IPv6 Protocol Adj 16 0 RFC 7555
8-255 Unassigned
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，DOI 10.17487/RFC4379，2006年2月<http://www.rfc-editor.org/info/rfc4379>.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, <http://www.rfc-editor.org/info/rfc6424>.
[RFC6424]Bahadur，N.，Kompella，K.，和G.Swallow，“在MPLS隧道上执行标签交换路径Ping（LSP Ping）的机制”，RFC 6424DOI 10.17487/RFC64242011<http://www.rfc-editor.org/info/rfc6424>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <http://www.rfc-editor.org/info/rfc6425>.
[RFC6425]Saxena，S.，Ed.，Swallow，G.，Ali，Z.，Farrel，A.，Yasukawa，S.，和T.Nadeau，“检测点对多点MPLS中的数据平面故障-LSP Ping扩展”，RFC 6425，DOI 10.17487/RFC6425，2011年11月<http://www.rfc-editor.org/info/rfc6425>.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, DOI 10.17487/RFC6426, November 2011, <http://www.rfc-editor.org/info/rfc6426>.
[RFC6426]Gray，E.，Bahadur，N.，Boutros，S.，和R.Aggarwal，“MPLS按需连接验证和路由跟踪”，RFC 6426，DOI 10.17487/RFC6426，2011年11月<http://www.rfc-editor.org/info/rfc6426>.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, DOI 10.17487/RFC7110, January 2014, <http://www.rfc-editor.org/info/rfc7110>.
[RFC7110]Chen，M.，Cao，W.，Ning，S.，Jounay，F.，和S.Delord，“返回路径指定标签交换路径（LSP）Ping”，RFC 7110，DOI 10.17487/RFC7110，2014年1月<http://www.rfc-editor.org/info/rfc7110>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <http://www.rfc-editor.org/info/rfc4875>.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，DOI 10.17487/RFC4875，2007年5月<http://www.rfc-editor.org/info/rfc4875>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<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>.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，DOI 10.17487/RFC6388，2011年11月<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.
作者要感谢Nobo Akiya、Adrian Farrel、Tom Yu、Tom Taylor和Warren Kumari的详细评论和富有洞察力的评论。
Authors' Addresses
作者地址
George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 United States
乔治·斯沃诺思科系统公司美国马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Vanson Lim Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 United States
美国马萨诸塞州Boxborough马萨诸塞大道1414号Vanson Lim Cisco Systems 01719
EMail: vlim@cisco.com
EMail: vlim@cisco.com
Sam Aldrin Huawei Technologies 2330 Central Express Way Santa Clara, CA 95951 United States
Sam Aldrin华为技术公司美国加利福尼亚州圣克拉拉中央高速公路2330号，邮编95951
EMail: aldrin.ietf@gmail.com
EMail: aldrin.ietf@gmail.com