Internet Engineering Task Force (IETF) S. Saxena, Ed.
Request for Comments: 6425 G. Swallow
Updates: 4379 Z. Ali
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 A. Farrel
Juniper Networks
S. Yasukawa
NTT Corporation
T. Nadeau
CA Technologies
November 2011
Internet Engineering Task Force (IETF) S. Saxena, Ed.
Request for Comments: 6425 G. Swallow
Updates: 4379 Z. Ali
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 A. Farrel
Juniper Networks
S. Yasukawa
NTT Corporation
T. Nadeau
CA Technologies
November 2011
Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping
检测点对多点MPLS中的数据平面故障-对LSP Ping的扩展
Abstract
摘要
Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs.
最近的提案扩大了多协议标签交换（MPLS）标签交换路径（LSP）的范围，以涵盖点对多点（P2MP）LSP。
The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".
人们已经认识到，在点对点（P2P）MPLS LSP中，需要一种简单有效的机制来检测数据平面故障，这导致了故障检测和隔离技术（通常称为“LSP ping”）的发展。
The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.
本文档的范围是P2MP MPLS LSP的故障检测和隔离。本文档并不取代LSP ping的任何机制，但澄清了它们对MPLS P2MP LSP的适用性，并将LSP ping的技术和机制扩展到MPLS P2MP环境。
This document updates RFC 4379.
本文件更新了RFC 4379。
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/rfc6425.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6425.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Design Considerations ......................................4
1.2. Terminology ................................................4
2. Notes on Motivation .............................................5
2.1. Basic Motivations for LSP Ping .............................5
2.2. Motivations for LSP Ping for P2MP LSPs .....................6
3. Packet Format ...................................................7
3.1. Identifying the LSP Under Test .............................8
3.1.1. Identifying a P2MP MPLS TE LSP ......................8
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV .............8
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV .............9
3.1.2. Identifying a Multicast LDP LSP .....................9
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs ..........10
3.1.2.2. Applicability to
Multipoint-to-Multipoint LSPs .............11
3.2. Limiting the Scope of Responses ...........................11
3.2.1. Egress Address P2MP Responder Sub-TLVs .............12
3.2.2. Node Address P2MP Responder Sub-TLVs ...............13
3.3. Preventing Congestion of Echo Replies .....................14
1. Introduction ....................................................3
1.1. Design Considerations ......................................4
1.2. Terminology ................................................4
2. Notes on Motivation .............................................5
2.1. Basic Motivations for LSP Ping .............................5
2.2. Motivations for LSP Ping for P2MP LSPs .....................6
3. Packet Format ...................................................7
3.1. Identifying the LSP Under Test .............................8
3.1.1. Identifying a P2MP MPLS TE LSP ......................8
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV .............8
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV .............9
3.1.2. Identifying a Multicast LDP LSP .....................9
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs ..........10
3.1.2.2. Applicability to
Multipoint-to-Multipoint LSPs .............11
3.2. Limiting the Scope of Responses ...........................11
3.2.1. Egress Address P2MP Responder Sub-TLVs .............12
3.2.2. Node Address P2MP Responder Sub-TLVs ...............13
3.3. Preventing Congestion of Echo Replies .....................14
3.4. Respond Only If TTL Expired Flag ..........................14
3.5. Downstream Detailed Mapping TLV ...........................15
4. Operation of LSP Ping for a P2MP LSP ...........................15
4.1. Initiating LSR Operations .................................16
4.1.1. Limiting Responses to Echo Requests ................16
4.1.2. Jittered Responses to Echo Requests ................16
4.2. Responding LSR Operations .................................17
4.2.1. Echo Reply Reporting ...............................18
4.2.1.1. Responses from Transit and Branch Nodes ...19
4.2.1.2. Responses from Egress Nodes ...............19
4.2.1.3. Responses from Bud Nodes ..................19
4.3. Special Considerations for Traceroute .....................21
4.3.1. End of Processing for Traceroutes ..................21
4.3.2. Multiple Responses from Bud and Egress Nodes .......22
4.3.3. Non-Response to Traceroute Echo Requests ...........22
4.3.4. Use of Downstream Detailed Mapping TLV in
Echo Requests ......................................23
4.3.5. Cross-Over Node Processing .........................23
5. Non-Compliant Routers ..........................................24
6. OAM and Management Considerations ..............................24
7. IANA Considerations ............................................25
7.1. New Sub-TLV Types .........................................25
7.2. New TLVs ..................................................25
7.3. New Global Flags Registry .................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................26
10. References ....................................................27
10.1. Normative References .....................................27
10.2. Informative References ...................................27
3.4. Respond Only If TTL Expired Flag ..........................14
3.5. Downstream Detailed Mapping TLV ...........................15
4. Operation of LSP Ping for a P2MP LSP ...........................15
4.1. Initiating LSR Operations .................................16
4.1.1. Limiting Responses to Echo Requests ................16
4.1.2. Jittered Responses to Echo Requests ................16
4.2. Responding LSR Operations .................................17
4.2.1. Echo Reply Reporting ...............................18
4.2.1.1. Responses from Transit and Branch Nodes ...19
4.2.1.2. Responses from Egress Nodes ...............19
4.2.1.3. Responses from Bud Nodes ..................19
4.3. Special Considerations for Traceroute .....................21
4.3.1. End of Processing for Traceroutes ..................21
4.3.2. Multiple Responses from Bud and Egress Nodes .......22
4.3.3. Non-Response to Traceroute Echo Requests ...........22
4.3.4. Use of Downstream Detailed Mapping TLV in
Echo Requests ......................................23
4.3.5. Cross-Over Node Processing .........................23
5. Non-Compliant Routers ..........................................24
6. OAM and Management Considerations ..............................24
7. IANA Considerations ............................................25
7.1. New Sub-TLV Types .........................................25
7.2. New TLVs ..................................................25
7.3. New Global Flags Registry .................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................26
10. References ....................................................27
10.1. Normative References .....................................27
10.2. Informative References ...................................27
Simple and efficient mechanisms that can be used to detect data-plane failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSP) are described in [RFC4379]. The techniques involve information carried in MPLS "echo request" and "echo reply" messages, and mechanisms for transporting them. The echo request and reply messages provide sufficient information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. The use of reliable channels for echo reply messages as described in [RFC4379] enables more robust fault isolation. This collection of mechanisms is commonly referred to as "LSP ping".
[RFC4379]中描述了可用于检测点对点（P2P）多协议标签交换（MPLS）标签交换路径（LSP）中数据平面故障的简单高效机制。这些技术涉及MPLS“echo-request”和“echo-reply”消息中携带的信息，以及用于传输它们的机制。回送请求和回复消息提供足够的信息来检查数据平面的正确操作，以及根据控制平面验证数据平面的机制，从而定位故障。[RFC4379]中所述的回音回复消息使用可靠通道可实现更稳健的故障隔离。这组机制通常被称为“LSP ping”。
The requirements for point-to-multipoint (P2MP) MPLS traffic engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a signaling solution for establishing P2MP MPLS TE LSPs.
[RFC4461]中说明了点对多点（P2MP）MPLS流量工程（TE）LSP的要求。[RFC4875]指定用于建立P2MP MPLS TE LSP的信令解决方案。
The requirements for P2MP extensions to the Label Distribution Protocol (LDP) are stated in [RFC6348]. [RFC6388] specifies extensions to LDP for P2MP MPLS.
标签分发协议（LDP）的P2MP扩展要求见[RFC6348]。[RFC6388]指定P2MP MPLS的LDP扩展。
P2MP MPLS LSPs are at least as vulnerable to data-plane faults or to discrepancies between the control and data planes as their P2P counterparts. Therefore, mechanisms are needed to detect such data plane faults in P2MP MPLS LSPs as described in [RFC4687].
P2MP MPLS LSP至少与P2P对等物一样容易受到数据平面故障或控制平面和数据平面之间差异的影响。因此，需要在P2MP MPLS LSP中检测此类数据平面故障的机制，如[RFC4687]所述。
This document extends the techniques described in [RFC4379] such that they may be applied to P2MP MPLS LSPs. This document stresses the reuse of existing LSP ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify implementation and network operation.
本文件扩展了[RFC4379]中所述的技术，以便将其应用于P2MP MPLS LSP。本文档强调重用用于P2P LSP的现有LSP ping机制，并将其应用于P2MP MPLS LSP，以简化实现和网络操作。
An important consideration for designing LSP ping for P2MP MPLS LSPs is that every attempt is made to use or extend existing mechanisms rather than invent new mechanisms.
为P2MP-MPLS-LSP设计LSP-ping的一个重要考虑因素是，每次尝试都是使用或扩展现有机制，而不是发明新的机制。
As for P2P LSPs, a critical requirement is that the echo request messages follow the same data path that normal MPLS packets traverse. However, as can be seen, this notion needs to be extended for P2MP MPLS LSPs, as in this case an MPLS packet is replicated so that it arrives at each egress (or leaf) of the P2MP tree.
对于P2P lsp，一个关键的要求是echo请求消息遵循与普通MPLS数据包相同的数据路径。然而，可以看出，这个概念需要针对P2MP MPLS lsp进行扩展，因为在这种情况下，MPLS分组被复制，以便它到达P2MP树的每个出口（或叶）。
MPLS echo requests are meant primarily to validate the data plane, and they can then be used to validate data-plane state against the control plane. They may also be used to bootstrap other Operations, Administration, and Maintenance (OAM) procedures such as [RFC5884]. As pointed out in [RFC4379], mechanisms to check the liveness, function, and consistency of the control plane are valuable, but such mechanisms are not a feature of LSP ping and are not covered in this document.
MPLS回送请求主要用于验证数据平面，然后可用于对照控制平面验证数据平面状态。它们还可用于引导其他操作、管理和维护（OAM）过程，如[RFC5884]。正如[RFC4379]中所指出的，检查控制平面的活动性、功能和一致性的机制是有价值的，但此类机制不是LSP ping的一个特性，本文档中不包括。
As is described in [RFC4379], to avoid potential denial-of-service attacks, it is RECOMMENDED to regulate the LSP ping traffic passed to the control plane. A rate limiter should be applied to the incoming LSP ping traffic.
如[RFC4379]所述，为了避免潜在的拒绝服务攻击，建议调节传递到控制平面的LSP ping通信量。速率限制器应用于传入的LSP ping流量。
The terminology used in this document for P2MP MPLS can be found in [RFC4461]. The terminology for MPLS OAM can be found in [RFC4379]. In particular, the notation <RSC> refers to the Return Subcode as defined in Section 3.1. of [RFC4379].
本文件中用于P2MP MPLS的术语可在[RFC4461]中找到。MPLS OAM的术语可在[RFC4379]中找到。特别是，符号<RSC>指第3.1节中定义的返回子码。属于[RFC4379]。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The motivations listed in [RFC4379] are reproduced here for completeness.
为了完整起见，此处复制了[RFC4379]中列出的动机。
When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that enables users to detect such traffic "black holes" or misrouting within a reasonable period of time. A mechanism to isolate faults is also required.
当LSP无法交付用户流量时，MPLS控制平面无法始终检测到该故障。需要提供一种工具，使用户能够在合理的时间内检测此类流量“黑洞”或错误路由。还需要一种隔离故障的机制。
[RFC4379] describes a mechanism that accomplishes these goals. This mechanism is modeled after the ping/traceroute paradigm: ping (ICMP echo request [RFC792]) is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode for testing MPLS LSPs.
[RFC4379]描述了实现这些目标的机制。该机制是按照ping/traceroute范式建模的：ping（ICMP echo request[RFC792]）用于连接检查，traceroute用于逐跳故障定位和路径跟踪。[RFC4379]指定用于测试MPLS LSP的“ping模式”和“traceroute”模式。
The basic idea as expressed in [RFC4379] is to test that the packets that belong to a particular Forwarding Equivalence Class (FEC) actually end their MPLS path on an LSR that is an egress for that FEC. [RFC4379] achieves this test by sending a packet (called an "MPLS echo request") along the same data path as other packets belonging to this FEC. An MPLS echo request also carries information about the FEC whose MPLS path is being verified. This echo request is forwarded just like any other packet belonging to that FEC. In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control plane of the egress LSR, which then verifies that it is indeed an egress for the FEC. In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit LSR, which performs various checks that it is indeed a transit LSR for this path; this LSR also returns further information that helps to check the control plane against the data plane, i.e., that forwarding matches what the routing protocols determined as the path.
[RFC4379]中表达的基本思想是测试属于特定转发等价类（FEC）的数据包是否在作为该FEC出口的LSR上实际结束其MPLS路径。[RFC4379]通过沿着与属于该FEC的其他数据包相同的数据路径发送数据包（称为“MPLS回送请求”）来实现该测试。MPLS回显请求还携带有关正在验证其MPLS路径的FEC的信息。该回显请求与属于该FEC的任何其他数据包一样被转发。在“ping”模式（基本连接性检查）下，分组应该到达路径的末端，在该点它被发送到出口LSR的控制平面，然后该控制平面验证它确实是FEC的出口。在“跟踪路由”模式（故障隔离）下，数据包被发送到每个传输LSR的控制平面，该控制平面执行各种检查，以确定它确实是该路径的传输LSR；此LSR还返回有助于对照数据平面检查控制平面的进一步信息，即转发匹配路由协议确定的路径。
One way these tools can be used is to periodically ping a FEC to ensure connectivity. If the ping fails, one can then initiate a traceroute to determine where the fault lies. One can also
使用这些工具的一种方法是定期ping FEC以确保连接。如果ping失败，则可以启动跟踪路由以确定故障所在。也可以
periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs and should be used with caution.
定期跟踪路由FEC，以验证转发与控制平面匹配；然而，这给过境LSR带来了更大的负担，应谨慎使用。
As stated in [RFC4687], MPLS has been extended to encompass P2MP LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and diagnose control- and data-plane defects is critical. For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects is important because such defects may affect the fundamentals of an MPLS network, but also because they may impact service-level-specification commitments for customers of their network.
如[RFC4687]所述，MPLS已扩展到包含P2MP LSP。与P2P MPLS LSP一样，检测、处理和诊断控制和数据平面缺陷的要求也非常关键。对于部署基于P2MP MPLS LSP的服务的运营商来说，如何处理这些缺陷的检测和规范非常重要，因为这些缺陷可能会影响MPLS网络的基础，但也可能会影响其网络客户的服务级别规范承诺。
P2MP LDP [RFC6388] uses LDP to establish multicast LSPs. These LSPs distribute data from a single source to one or more destinations across the network according to the next hops indicated by the routing protocols. Each LSP is identified by an MPLS multicast FEC.
P2MP LDP[RFC6388]使用LDP建立多播LSP。这些LSP根据路由协议指示的下一个跃点，将数据从单个源分发到网络上的一个或多个目的地。每个LSP由MPLS多播FEC标识。
P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a single ingress and multiple egresses. The tunnels, built on P2MP LSPs, are explicitly routed through the network. There is no concept or applicability of a FEC in the context of a P2MP MPLS TE LSP.
P2MP MPLS TE LSP[RFC4875]可被视为具有单个入口和多个出口的MPLS隧道。建立在P2MP LSP上的隧道通过网络显式路由。在P2MP MPLS TE LSP的上下文中没有FEC的概念或适用性。
MPLS packets inserted at the ingress of a P2MP LSP are delivered equally (barring faults) to all egresses. In consequence, the basic idea of LSP ping for P2MP MPLS LSPs may be expressed as an intention to test that packets that enter (at the ingress) a particular P2MP LSP actually end their MPLS path on the LSRs that are the (intended) egresses for that LSP. The idea may be extended to check selectively that such packets reach specific egresses.
插入P2MP LSP入口的MPLS数据包被平等地传送到所有出口（排除故障）。因此，P2MP-MPLS-LSP的LSP ping的基本思想可以表示为测试进入（入口处）特定P2MP-LSP的分组实际上结束其在lsr上的MPLS路径的意图，该LSP的（预期）出口。该思想可被扩展以选择性地检查这样的分组是否到达特定出口。
The technique in this document makes this test by sending an LSP ping echo request message along the same data path as the MPLS packets. An echo request also carries the identification of the P2MP MPLS LSP (multicast LSP or P2MP TE LSP) that it is testing. The echo request is forwarded just as any other packet using that LSP, and so is replicated at branch points of the LSP and should be delivered to all egresses.
本文档中的技术通过沿着与MPLS数据包相同的数据路径发送LSP ping echo请求消息来进行此测试。回波请求还携带其正在测试的P2MP MPLS LSP（多播LSP或P2MP TE LSP）的标识。回送请求与使用该LSP的任何其他数据包一样被转发，因此在LSP的分支点上被复制，并且应该被传递到所有出口。
In "ping" mode (basic connectivity check), the echo request should reach the end of the path, at which point it is sent to the control plane of the egress LSRs, which verify that they are indeed an egress (leaf) of the P2MP LSP. An echo reply message is sent by an egress to the ingress to confirm the successful receipt (or announce the erroneous arrival) of the echo request.
在“ping”模式（基本连接性检查）下，回波请求应到达路径的末端，在该点它被发送到出口LSR的控制平面，出口LSR验证它们确实是P2MP LSP的出口（叶）。出口向入口发送回显回复消息，以确认成功接收（或宣布错误到达）回显请求。
In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS LSP. The transit LSR returns information about the outgoing paths. This information can be used by ingress LSRs to build topology or by downstream LSRs to do extra label verification.
在“跟踪路由”模式（故障隔离）下，回声请求在每个传输LSR发送到控制平面，控制平面检查它是否确实是此P2MP MPLS LSP的传输LSR。传输LSR返回有关传出路径的信息。该信息可由入口LSR用于构建拓扑，或由下游LSR用于进行额外的标签验证。
P2MP MPLS LSPs may have many egresses, and it is not necessarily the intention of the initiator of the ping or traceroute operation to collect information about the connectivity or path to all egresses. Indeed, in the event of pinging all egresses of a large P2MP MPLS LSP, it might be expected that a large number of echo replies would arrive at the ingress independently but at approximately the same time. Under some circumstances this might cause congestion at or around the ingress LSR. The procedures described in this document provide two mechanisms to control echo replies.
P2MP MPLS lsp可以有许多出口，ping或traceroute操作的发起人不一定打算收集关于所有出口的连接或路径的信息。事实上，在ping大型P2MP MPLS LSP的所有出口的情况下，可以预期大量的回音应答将独立但几乎同时到达入口。在某些情况下，这可能会在入口LSR处或其周围造成拥塞。本文档中描述的过程提供了两种机制来控制回送回复。
The first procedure allows the responders to randomly delay (or jitter) their replies so that the chances of swamping the ingress are reduced. The second procedure allows the initiator to limit the scope of an LSP ping echo request (ping or traceroute mode) to one specific intended egress.
第一个过程允许响应者随机延迟（或抖动）他们的响应，以减少淹没入口的机会。第二个过程允许启动器将LSP ping回显请求（ping或traceroute模式）的范围限制为一个特定的预期出口。
LSP ping can be used to periodically ping a P2MP MPLS LSP to ensure connectivity to any or all of the egresses. If the ping fails, the operator or an automated process can then initiate a traceroute to determine where the fault is located within the network. A traceroute may also be used periodically to verify that data-plane forwarding matches the control-plane state; however, this places an increased burden on transit LSRs and should be used infrequently and with caution.
LSP ping可用于定期ping P2MP MPLS LSP，以确保与任何或所有出口的连接。如果ping失败，操作员或自动过程可以启动跟踪路由，以确定故障在网络中的位置。跟踪路由还可以周期性地用于验证数据平面转发与控制平面状态匹配；然而，这增加了运输LSR的负担，因此应避免频繁使用。
The basic structure of the LSP ping packet remains the same as described in [RFC4379]. Some new TLVs and sub-TLVs are required to support the new functionality. They are described in the following sections.
LSP ping分组的基本结构与[RFC4379]中描述的相同。需要一些新的TLV和子TLV来支持新功能。以下各节将对其进行说明。
[RFC4379] defines how an MPLS TE LSP under test may be identified in an echo request. A Target FEC Stack TLV is used to carry either an RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV.
[RFC4379]定义如何在回送请求中识别被测MPLS TE LSP。目标FEC堆栈TLV用于承载RSVP IPv4会话或RSVP IPv6会话子TLV。
In order to identify the P2MP MPLS TE LSP under test, the echo request message MUST carry a Target FEC Stack TLV, and this MUST carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry fields from the RSVP-TE P2MP SESSION and SENDER_TEMPLATE objects [RFC4875] and so provide sufficient information to uniquely identify the LSP.
为了识别测试中的P2MP MPLS TE LSP，回显请求消息必须携带目标FEC堆栈TLV，并且必须正好携带两个子TLV中的一个：RSVP P2MP IPv4会话子TLV或RSVP P2MP IPv6会话子TLV。这些子TLV携带来自RSVP-TE P2MP会话和发送方模板对象[RFC4875]的字段，因此提供足够的信息来唯一标识LSP。
The new sub-TLVs are assigned Sub-Type identifiers as follows, and are described in the following sections.
新的子TLV被分配子类型标识符，如下所示，并在以下章节中描述。
Sub-Type # Length Value Field
---------- ------ -----------
17 20 RSVP P2MP IPv4 Session
18 56 RSVP P2MP IPv6 Session
Sub-Type # Length Value Field
---------- ------ -----------
17 20 RSVP P2MP IPv4 Session
18 56 RSVP P2MP IPv6 Session
The format of the RSVP P2MP IPv4 Session sub-TLV value field is specified in the following figure. The value fields are taken from the definitions of the P2MP IPv4 LSP SESSION Object and the P2MP IPv4 SENDER_TEMPLATE Object in Sections 19.1.1 and 19.2.1 of [RFC4875]. Note that the Sub-Group ID of the SENDER_TEMPLATE is not required.
下图指定了RSVP P2MP IPv4会话子TLV值字段的格式。值字段取自[RFC4875]第19.1.1节和第19.2.1节中P2MP IPv4 LSP会话对象和P2MP IPv4发送者_模板对象的定义。请注意，发送方\模板的子组ID不是必需的。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the RSVP P2MP IPv6 Session sub-TLV value field is specified in the following figure. The value fields are taken from the definitions of the P2MP IPv6 LSP SESSION Object and the P2MP IPv6 SENDER_TEMPLATE Object in Sections 19.1.2 and 19.2.2 of [RFC4875]. Note that the Sub-Group ID of the SENDER_TEMPLATE is not required.
下图指定了RSVP P2MP IPv6会话子TLV值字段的格式。值字段取自[RFC4875]第19.1.2节和第19.2.2节中P2MP IPv6 LSP会话对象和P2MP IPv6发送者_模板对象的定义。请注意，发送方\模板的子组ID不是必需的。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Extended Tunnel ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Tunnel Sender Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Extended Tunnel ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Tunnel Sender Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[RFC4379] defines how a P2P LDP LSP under test may be identified in an echo request. A Target FEC Stack TLV is used to carry one or more sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the LSP.
[RFC4379]定义了如何在回送请求中识别测试中的P2P LDP LSP。目标FEC堆栈TLV用于承载标识LSP的一个或多个子TLV（例如，IPv4前缀FEC sub TLV）。
In order to identify a multicast LDP LSP under test, the echo request message MUST carry a Target FEC Stack TLV, and this MUST carry exactly one of two new sub-TLVs: either a Multicast P2MP LDP FEC Stack sub-TLV or a Multicast MP2MP LDP FEC Stack sub-TLV. These sub-TLVs use fields from the multicast LDP messages [RFC6388] and so provide sufficient information to uniquely identify the LSP.
为了识别测试中的多播LDP LSP，回送请求消息必须携带目标FEC堆栈TLV，并且必须携带两个新子TLV中的一个：多播P2MP LDP FEC堆栈子TLV或多播MP2MP LDP FEC堆栈子TLV。这些子TLV使用来自多播LDP消息[RFC6388]的字段，因此提供足够的信息来唯一标识LSP。
The new sub-TLVs are assigned sub-type identifiers as follows and are described in the following section.
新的子TLV被分配子类型标识符，如下所示，并在下一节中描述。
Sub-Type # Length Value Field
---------- ------ -----------
19 Variable Multicast P2MP LDP FEC Stack
20 Variable Multicast MP2MP LDP FEC Stack
Sub-Type # Length Value Field
---------- ------ -----------
19 Variable Multicast P2MP LDP FEC Stack
20 Variable Multicast MP2MP LDP FEC Stack
Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as specified in the following figure.
多播P2MP和MP2MP LDP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address Length| Root LSR Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Root LSR Address (Cont.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Family | Address Length| Root LSR Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Root LSR Address (Cont.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family
地址家庭
Two-octet quantity containing a value from ADDRESS FAMILY NUMBERS in [IANA-AF] that encodes the address family for the Root LSR Address.
两个八位组数量，包含[IANA-AF]中地址族编号的值，该值对根LSR地址的地址族进行编码。
Address Length
地址长度
Length of the Root LSR Address in octets.
根LSR地址的长度（以八位字节为单位）。
Root LSR Address
根LSR地址
Address of the LSR at the root of the P2MP LSP encoded according to the Address Family field.
根据地址族字段编码的P2MP LSP根的LSR地址。
Opaque Length
不透明长度
The length of the opaque value, in octets. Depending on the length of the Root LSR Address, this field may not be aligned to a word boundary.
不透明值的长度，以八位字节为单位。根据根LSR地址的长度，此字段可能不与字边界对齐。
Opaque Value
不透明值
An opaque value element that uniquely identifies the P2MP LSP in the context of the Root LSR.
在根LSR的上下文中唯一标识P2MP LSP的不透明值元素。
If the Address Family is IPv4, the Address Length MUST be 4. If the Address Family is IPv6, the Address Length MUST be 16. No other Address Family values are defined at present.
如果地址族为IPv4，则地址长度必须为4。如果地址族为IPv6，则地址长度必须为16。目前未定义其他地址族值。
The mechanisms defined in this document can be extended to include Multipoint-to-Multipoint (MP2MP) Multicast LSPs. In an MP2MP LSP tree, any leaf node can be treated like a head node of a P2MP tree. In other words, for MPLS OAM purposes, the MP2MP tree can be treated like a collection of P2MP trees, with each MP2MP leaf node acting like a P2MP head-end node. When a leaf node is acting like a P2MP head-end node, the remaining leaf nodes act like egress or bud nodes.
本文档中定义的机制可以扩展为包括多点对多点（MP2MP）多播LSP。在MP2MP LSP树中，任何叶节点都可以被视为P2MP树的头节点。换句话说，出于MPLS OAM的目的，可以将MP2MP树视为P2MP树的集合，每个MP2MP叶节点充当P2MP头端节点。当一个叶节点的行为类似于P2MP头端节点时，其余叶节点的行为类似于出口节点或芽节点。
A new TLV is defined for inclusion in the echo request message.
定义了一个新的TLV以包含在回显请求消息中。
The P2MP Responder Identifier TLV is assigned the TLV type value 11 and is encoded as follows.
P2MP响应器标识符TLV被分配TLV类型值11，并且编码如下。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 11 (P2MP Responder ID)| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 11 (P2MP Responder ID)| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-TLVs:
次级TLV：
Zero, one, or more sub-TLVs as defined below.
零、一或多个子TLV，定义如下。
If no sub-TLVs are present, the TLV MUST be processed as if it were absent. If more than one sub-TLV is present, the first TLV MUST be processed as described in this document, and subsequent sub-TLVs SHOULD be ignored. Interpretation of additional sub-TLVs may be defined in future documents.
如果不存在子TLV，则必须像不存在子TLV一样处理TLV。如果存在多个子TLV，则必须按照本文档中的说明处理第一个子TLV，并且应忽略后续子TLV。其他子TLV的解释可能在未来的文件中定义。
The P2MP Responder Identifier TLV only has meaning on an echo request message. If present on an echo reply message, it MUST be ignored.
P2MP响应程序标识符TLV仅在回显请求消息上有意义。如果回显回复消息中存在，则必须忽略该消息。
Four sub-TLVs are defined for inclusion in the P2MP Responder Identifier TLV carried on the echo request message. These are:
定义了四个子TLV，用于包含在回声请求消息中携带的P2MP响应者标识符TLV中。这些是：
Sub-Type # Length Value Field
---------- ------ -----------
1 4 IPv4 Egress Address P2MP Responder
2 16 IPv6 Egress Address P2MP Responder
3 4 IPv4 Node Address P2MP Responder
4 16 IPv6 Node Address P2MP Responder
Sub-Type # Length Value Field
---------- ------ -----------
1 4 IPv4 Egress Address P2MP Responder
2 16 IPv6 Egress Address P2MP Responder
3 4 IPv4 Node Address P2MP Responder
4 16 IPv6 Node Address P2MP Responder
The content of these sub-TLVs are defined in the following sections. Also defined is the intended behavior of the responding node upon receiving any of these sub-TLVs.
这些子TLV的内容在以下章节中定义。还定义了响应节点在接收到这些子TLV时的预期行为。
The encoding of the IPv4 Egress Address P2MP Responder sub-TLV is as follows:
IPv4出口地址P2MP响应器子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 1 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 1 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding of the IPv6 Egress Address P2MP Responder sub-TLV is as follows:
IPv6出口地址P2MP响应器子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit IPv6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A node that receives an echo request with this sub-TLV present MUST respond if the node lies on the path to the address in the sub-TLV and MUST NOT respond if it does not lie on the path to the address in the sub-TLV. For this to be possible, the address in the sub-TLV must be known to the nodes that lie upstream in the LSP. This can be the case if RSVP-TE is used to signal the P2MP LSP, in which case this address will be the address used in the Destination Address
如果节点位于子TLV中地址的路径上，则接收到此子TLV存在的回显请求的节点必须响应，如果节点不位于子TLV中地址的路径上，则不得响应。为了实现这一点，位于LSP上游的节点必须知道子TLV中的地址。如果使用RSVP-TE向P2MP LSP发送信号，则可能出现这种情况，在这种情况下，该地址将是目标地址中使用的地址
field of the S2L_SUB_LSP object, when corresponding egress or bud node is signaled. Thus, the IPv4 or IPv6 Egress Address P2MP Responder sub-TLV MAY be used in an echo request carrying RSVP P2MP Session sub-TLV.
S2L_SUB_LSP对象的字段，当相应的出口或bud节点发出信号时。因此，IPv4或IPv6出口地址P2MP响应器子TLV可用于承载RSVP P2MP会话子TLV的回声请求中。
However, in Multicast LDP, there is no way for upstream LSRs to know the identity of the downstream leaf nodes. Hence, these TLVs cannot be used to perform traceroute to a single node when Multicast LDP FEC is used, and the IPv4 or IPv6 Egress Address P2MP Responder sub-TLV SHOULD NOT be used with an echo request carrying a Multicast LDP FEC Stack sub-TLV. If a node receives these TLVs in an echo request carrying Multicast LDP, then it will not respond since it is unaware of whether it lies on the path to the address in the sub-TLV.
然而，在多播LDP中，上游LSR无法知道下游叶节点的身份。因此，当使用多播LDP FEC时，这些TLV不能用于执行到单个节点的跟踪路由，并且IPv4或IPv6出口地址P2MP响应器子TLV不应与携带多播LDP FEC堆栈子TLV的回送请求一起使用。如果节点在承载多播LDP的回送请求中接收到这些TLV，那么它将不会响应，因为它不知道它是否位于子TLV中地址的路径上。
The encoding of the IPv4 Node Address P2MP Responder sub-TLV is as follows:
IPv4节点地址P2MP响应器子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 3 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 3 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding of the IPv6 Node Address P2MP Responder sub-TLV is as follows:
IPv6节点地址P2MP响应器子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 4 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit IPv6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 4 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 or IPv6 Node Address P2MP Responder sub-TLVs MAY be used in an echo request carrying either RSVP P2MP Session or Multicast LDP FEC Stack sub-TLVs.
IPv4或IPv6节点地址P2MP响应器子TLV可用于承载RSVP P2MP会话或多播LDP FEC堆栈子TLV的回显请求中。
A node that receives an echo request with one of these sub-TLVs present MUST respond if the address in the sub-TLV matches any address that is local to the node and MUST NOT respond if the address
如果子TLV中的地址与节点本地的任何地址匹配，则接收到存在这些子TLV之一的回显请求的节点必须响应，如果该地址匹配，则不得响应
in the sub-TLV does not match any address that is local to the node. The address in the sub-TLV may be of any physical interface or may be the router ID of the node itself.
在子目录中，TLV与节点本地的任何地址都不匹配。子TLV中的地址可以是任何物理接口，或者可以是节点本身的路由器ID。
The address in this sub-TLV SHOULD be of any transit, branch, bud, or egress node for that P2MP LSP. The address of a node that is not on the P2MP LSP MAY be used as a check for that no reply is received.
此子TLV中的地址应为该P2MP LSP的任何传输、分支、bud或出口节点的地址。不在P2MP LSP上的节点的地址可用于检查是否未收到回复。
A new TLV is defined for inclusion in the Echo request message.
定义了一个新的TLV以包含在回显请求消息中。
The Echo Jitter TLV is assigned the TLV type value 12 and is encoded as follows.
回波抖动TLV被分配TLV类型值12，并且按照如下方式编码。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 (Jitter TLV) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jitter Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 (Jitter TLV) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jitter Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jitter Time:
抖动时间：
This field specifies the upper bound of the jitter period that should be applied by a responding node to determine how long to wait before sending an echo reply. A responding node MUST wait a random amount of time between zero milliseconds and the value specified in this field.
此字段指定响应节点应应用的抖动周期的上限，以确定发送回显回复之前等待的时间。响应节点必须在零毫秒和此字段中指定的值之间随机等待一段时间。
Jitter time is specified in milliseconds.
抖动时间以毫秒为单位指定。
The Echo Jitter TLV only has meaning on an echo request message. If present on an echo reply message, it MUST be ignored.
回波抖动TLV仅对回波请求消息有意义。如果回显回复消息中存在，则必须忽略该消息。
A new flag is being introduced in the Global Flags field defined in [RFC4379]. The new format of the Global Flags field is:
[RFC4379]中定义的全局标志字段中引入了一个新标志。全局标志字段的新格式为：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The V flag is described in [RFC4379].
[RFC4379]中描述了V标志。
The T (Respond Only If TTL Expired) flag MUST be set only in the echo request packet by the sender. This flag MUST NOT be set in the echo reply packet. If this flag is set in an echo reply packet, then it MUST be ignored.
发送方必须仅在回显请求数据包中设置T（仅在TTL过期时响应）标志。不得在回送回复数据包中设置此标志。如果在回显回复数据包中设置了此标志，则必须忽略它。
If the T flag is set to 0, then the receiving node MUST process the incoming echo request.
如果T标志设置为0，则接收节点必须处理传入的回显请求。
If the T flag is set to 1 and the TTL of the incoming MPLS label is equal to 1, then the receiving node MUST process the incoming echo request.
如果T标志设置为1，并且传入MPLS标签的TTL等于1，则接收节点必须处理传入的回显请求。
If the T flag is set to 1 and the TTL of the incoming MPLS label is more than 1, then the receiving node MUST drop the incoming echo request and MUST NOT send any echo reply to the sender.
如果T标志设置为1，并且传入MPLS标签的TTL大于1，则接收节点必须丢弃传入的回显请求，并且不得向发送方发送任何回显回复。
If the T flag is set to 1 and there are no incoming MPLS labels in the echo request packet, then a bud node with PHP configured MAY choose to not respond to this echo request. All other nodes MUST ignore this bit and respond as per regular processing.
如果T标志设置为1，并且echo请求数据包中没有传入的MPLS标签，那么配置了PHP的bud节点可以选择不响应此echo请求。所有其他节点必须忽略此位，并按照常规处理进行响应。
The Downstream Detailed Mapping TLV is described in [RFC6424]. A transit, branch or bud node can use the Downstream Detailed Mapping TLV to return multiple Return Codes for different downstream paths. This functionality can not be achieved via the Downstream Mapping TLV. As per Section 3.4 of [RFC6424], the Downstream Mapping TLV as described in [RFC4379] is being deprecated.
[RFC6424]中描述了下游详细映射TLV。transit、branch或bud节点可以使用下游详细映射TLV为不同的下游路径返回多个返回码。此功能无法通过下游映射TLV实现。根据[RFC6424]第3.4节，[RFC4379]中所述的下游映射TLV正在被弃用。
Therefore, for P2MP, a node MUST support the Downstream Detailed Mapping TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP traceroute functionality and MUST NOT be included in an Echo Request message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC type or a Multicast P2MP/MP2MP LDP FEC type, a node MUST ignore any Downstream Mapping TLV it receives in the echo request and MUST continue processing as if the Downstream Mapping TLV is not present.
因此，对于P2MP，节点必须支持下游详细映射TLV。下游映射TLV[RFC4379]不适用于P2MP跟踪路由功能，并且不得包含在回显请求消息中。当响应RSVP IPv4/IPv6 P2MP会话FEC类型或多播P2MP/MP2MP LDP FEC类型时，节点必须忽略其在回显请求中接收到的任何下游映射TLV，并且必须继续处理，就像下游映射TLV不存在一样。
The details of the Return Codes to be used in the Downstream Detailed Mapping TLV are provided in Section 4.
第4节提供了下游详细映射TLV中使用的返回代码的详细信息。
This section describes how LSP ping is applied to P2MP MPLS LSPs. As mentioned previously, an important design consideration has been to extend the existing LSP ping mechanism in [RFC4379] rather than invent new mechanisms.
本节介绍如何将LSP ping应用于P2MP MPLS LSP。如前所述，一个重要的设计考虑是扩展[RFC4379]中现有的LSP ping机制，而不是发明新的机制。
As specified in [RFC4379], MPLS LSPs can be tested via a "ping" mode or a "traceroute" mode. The ping mode is also known as "connectivity verification" and traceroute mode is also known as "fault isolation". Further details can be obtained from [RFC4379].
如[RFC4379]所述，MPLS LSP可通过“ping”模式或“traceroute”模式进行测试。ping模式也称为“连接验证”，traceroute模式也称为“故障隔离”。更多详细信息可从[RFC4379]获取。
This section specifies processing of echo requests for both ping and traceroute mode at various nodes (ingress, transit, etc.) of the P2MP LSP.
本节规定了在P2MP LSP的各个节点（入口、传输等）处理ping和traceroute模式的回波请求。
The LSR initiating the echo request will follow the procedures in [RFC4379]. The echo request will contain a Target FEC Stack TLV. To identify the P2MP LSP under test, this TLV will contain one of the new sub-TLVs defined in Section 3.1. Additionally, there may be other optional TLVs present.
启动回波请求的LSR将遵循[RFC4379]中的程序。回显请求将包含目标FEC堆栈TLV。为了识别测试中的P2MP LSP，该TLV将包含第3.1节中定义的新子TLV之一。此外，可能存在其他可选TLV。
As described in Section 2.2, it may be desirable to restrict the operation of P2MP ping or traceroute to a single egress. Since echo requests are forwarded through the data plane without interception by the control plane, there is no facility to limit the propagation of echo requests, and they will automatically be forwarded to all reachable egresses.
如第2.2节所述，可能需要将P2MP ping或traceroute的操作限制在单个出口。由于回声请求通过数据平面转发，而不被控制平面截获，因此没有任何设施限制回声请求的传播，它们将自动转发到所有可到达的出口。
However, a single egress may be identified by the inclusion of a P2MP Responder Identifier TLV. The details of this TLV and its sub-TLVs are in Section 3.2. There are two main types of sub-TLVs in the P2MP Responder Identifier TLV: Node Address sub-TLV and Egress Address sub-TLV.
然而，可以通过包括P2MP响应器标识符TLV来识别单个出口。本TLV及其子TLV的详细信息见第3.2节。P2MP响应器标识符TLV中有两种主要类型的子TLV：节点地址子TLV和出口地址子TLV。
These sub-TLVs limit the replies either to the specified LSR only or to any LSR on the path to the specified LSR. The former capability is generally useful for ping mode, while the latter is more suited to traceroute mode. An initiating LSR may indicate that it wishes all egresses to respond to an echo request by omitting the P2MP Responder Identifier TLV.
这些子TLV将回复限制为仅回复指定的LSR或回复到指定LSR路径上的任何LSR。前者通常适用于ping模式，而后者更适用于traceroute模式。发起LSR可通过省略P2MP响应者标识符TLV来指示其希望所有出口响应回声请求。
The initiating LSR MAY request that the responding LSRs introduce a random delay (or jitter) before sending the reply. The randomness of the delay allows the replies from multiple egresses to be spread over a time period. Thus, this technique is particularly relevant when the entire P2MP LSP is being pinged or traced since it helps prevent the initiating (or nearby) LSRs from being swamped by replies, or from discarding replies due to rate limits that have been applied.
发起LSR可以请求响应LSR在发送应答之前引入随机延迟（或抖动）。延迟的随机性允许来自多个出口的应答在一段时间内分散。因此，当对整个P2MP LSP进行ping或跟踪时，此技术尤其相关，因为它有助于防止发起（或附近）LSR被回复淹没，或由于已应用的速率限制而丢弃回复。
It is desirable for the initiating LSR to be able to control the bounds of the jitter. If the tree size is small, only a small amount of jitter is required, but if the tree is large, greater jitter is needed.
期望初始LSR能够控制抖动的边界。如果树的大小很小，只需要少量的抖动，但是如果树很大，则需要更大的抖动。
The initiating LSR can supply the desired value of the jitter in the Echo Jitter TLV as defined in Section 3.3. If this TLV is present, the responding LSR MUST delay sending a reply for a random amount of time between zero milliseconds and the value indicated in the TLV. If the TLV is absent, the responding egress SHOULD NOT introduce any additional delay in responding to the echo request, but MAY delay according to local policy.
启动LSR可提供第3.3节中定义的回波抖动TLV中抖动的期望值。如果存在此TLV，则响应LSR必须延迟发送回复，延迟时间为零毫秒与TLV中指示的值之间的随机时间量。如果TLV不存在，响应出口在响应回声请求时不应引入任何额外延迟，但可以根据本地策略进行延迟。
LSP ping MUST NOT be used to attempt to measure the round-trip time for data delivery. This is because the P2MP LSPs are unidirectional, and the echo reply is often sent back through the control plane. The timestamp fields in the echo request and echo reply packets MAY be used to deduce some information about delivery times, for example the variance in delivery times.
LSP ping不得用于尝试测量数据传递的往返时间。这是因为P2MP LSP是单向的，并且回音应答通常通过控制平面发回。回送请求和回送回复分组中的时间戳字段可用于推断关于递送时间的一些信息，例如递送时间的方差。
The use of echo jittering does not change the processes for gaining information, but note that the responding node MUST set the value in the Timestamp Received fields before applying any delay.
回声抖动的使用不会改变获取信息的过程，但请注意，响应节点必须在应用任何延迟之前在Timestamp Received字段中设置值。
Echo reply jittering SHOULD be used for P2MP LSPs, although it MAY be omitted for simple P2MP LSPs or when the Node Address P2MP Responder sub-TLVs are used. If the Echo Jitter TLV is present in an echo request for any other type of LSPs, the responding egress MAY apply the jitter behavior as described here.
回音应答抖动应用于P2MP LSP，但对于简单的P2MP LSP或使用节点地址P2MP响应器子TLV时，可以省略回音应答抖动。如果任何其他类型的lsp的回波请求中存在回波抖动TLV，则响应出口可应用如本文所述的抖动行为。
Usually the echo request packet will reach the egress and bud nodes. In case of TTL Expiry, i.e., traceroute mode, the echo request packet may stop at branch or transit nodes. In both scenarios, the echo request will be passed on to the control plane for reply processing.
通常，echo请求数据包将到达出口和bud节点。在TTL到期的情况下，即，跟踪器路由模式，echo请求分组可以在分支或传输节点处停止。在这两种情况下，回显请求将被传递到控制平面进行应答处理。
The operations at the receiving node are an extension to the existing processing as specified in [RFC4379]. As described in that document, a responding LSR SHOULD rate-limit the receipt of echo request messages. After rate-limiting, the responding LSR must verify the general sanity of the packet. If the packet is malformed or certain TLVs are not understood, the [RFC4379] procedures must be followed for echo reply. Similarly, the Reply Mode field determines if the reply is required or not (and the mechanism to send it back).
接收节点上的操作是[RFC4379]中规定的现有处理的扩展。如该文档中所述，响应LSR应限制回送请求消息的接收速率。在速率限制之后，响应的LSR必须验证数据包的一般健全性。如果数据包格式不正确或某些TLV无法理解，则必须遵循[RFC4379]程序进行回送回复。类似地，Reply Mode字段确定是否需要回复（以及发送回复的机制）。
For P2MP LSP ping and traceroute, i.e., if the echo request is carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding LSR MUST determine whether it is part of the P2MP LSP in question by checking with the control plane.
对于P2MP LSP ping和traceroute，即，如果echo请求携带RSVP P2MP FEC或多播LDP FEC，则响应LSR必须通过与控制平面进行检查来确定它是否是相关P2MP LSP的一部分。
- If the node is not part of the P2MP LSP, it MUST respond according to [RFC4379] processing rules.
- 如果节点不是P2MP LSP的一部分，则必须根据[RFC4379]处理规则进行响应。
- If the node is part of the P2MP LSP, the node must check whether or not the echo request is directed to it.
- 如果该节点是P2MP LSP的一部分，则该节点必须检查回声请求是否指向该节点。
- If a P2MP Responder Identifier TLV is present, then the node must follow the procedures defined in Section 3.2 to determine whether or not it should respond to the request. The presence of a P2MP Responder Identifier TLV or a Downstream Detailed Mapping TLV might affect the Return Code. This is discussed in more detail later.
- 如果存在P2MP响应者标识符TLV，则节点必须遵循第3.2节中定义的程序，以确定是否应响应请求。P2MP响应程序标识符TLV或下游详细映射TLV的存在可能会影响返回代码。这将在后面进行更详细的讨论。
- If the P2MP Responder Identifier TLV is not present (or, in the error case, is present, but does not contain any sub-TLVs), then the node MUST respond according to [RFC4379] processing rules.
- 如果P2MP响应器标识符TLV不存在（或者在错误情况下存在，但不包含任何子TLV），则节点必须根据[RFC4379]处理规则进行响应。
Echo reply messages carry Return Codes and Subcodes to indicate the result of the LSP ping (when the ping mode is being used) as described in [RFC4379].
回声回复消息带有返回码和子码，以指示LSP ping的结果（当使用ping模式时），如[RFC4379]所述。
When the responding node reports that it is an egress, it is clear that the echo reply applies only to that reporting node. Similarly, when a node reports that it does not form part of the LSP described by the FEC, then it is clear that the echo reply applies only to that reporting node. However, an echo reply message that reports an error from a transit node may apply to multiple egress nodes (i.e., leaves) downstream of the reporting node. In the case of the ping mode of operation, it is not possible to correlate the reporting node to the affected egresses unless the topology of the P2MP tree is already known, and it may be necessary to use the traceroute mode of operation to further diagnose the LSP.
当响应节点报告它是出口时，回送回复显然只适用于该报告节点。类似地，当节点报告它不构成由FEC描述的LSP的一部分时，则回送应答显然仅适用于该报告节点。然而，报告来自传输节点的错误的回声应答消息可应用于报告节点下游的多个出口节点（即，叶）。在ping操作模式的情况下，除非已经知道P2MP树的拓扑，否则不可能将报告节点与受影响的出口相关联，并且可能需要使用traceroute操作模式来进一步诊断LSP。
Note that a transit node may discover an error, but it may also determine that while it does lie on the path of the LSP under test, it does not lie on the path to the specific egress being tested. In this case, the node SHOULD NOT generate an echo reply unless there is a specific error condition that needs to be communicated.
注意，传输节点可以发现错误，但它也可以确定，虽然它确实位于被测LSP的路径上，但它不位于被测特定出口的路径上。在这种情况下，节点不应生成回显应答，除非存在需要通信的特定错误条件。
The following sections describe the expected values of Return Codes for various nodes in a P2MP LSP. It is assumed that the sanity and other checks have been performed and an echo reply is being sent back. As mentioned in Section 4.2, the Return Code might change based on the presence of a Responder Identifier TLV or Downstream Detailed Mapping TLV.
以下各节描述了P2MP LSP中各个节点的返回码的预期值。假设已经执行了健全性和其他检查，并且正在发送回回显回复。如第4.2节所述，返回代码可能会根据响应者标识符TLV或下游详细映射TLV的存在而改变。
The presence of a Responder Identifier TLV does not influence the choice of the Return Code. For a success response, the Return Code MAY be set to value 8 ('Label switched at stack-depth <RSC>'). The notation <RSC> refers to the Return Subcode as defined in Section 3.1. of [RFC4379]. For error conditions, use appropriate values defined in [RFC4379].
响应者标识符TLV的存在不会影响返回码的选择。对于成功响应，可将返回代码设置为值8（“标签在堆栈深度处切换<RSC>”）。符号<RSC>指第3.1节中定义的返回子代码。属于[RFC4379]。对于错误情况，请使用[RFC4379]中定义的适当值。
The presence of a Downstream Detailed Mapping TLV will influence the choice of Return Code. As per [RFC6424], the Return Code in the echo reply header MAY be set to 'See DDM TLV for Return Code and Return Subcode' as defined in [RFC6424]. The Return Code for each Downstream Detailed Mapping TLV will depend on the downstream path as described in [RFC6424].
下游详细映射TLV的存在将影响返回代码的选择。根据[RFC6424]，echo回复头中的返回码可设置为[RFC6424]中定义的“返回码和返回子码见DDM TLV”。每个下游详细映射TLV的返回代码将取决于[RFC6424]中所述的下游路径。
There will be a Downstream Detailed Mapping TLV for each downstream path being reported in the echo reply. Hence, for transit nodes, there will be only one such TLV, and for branch nodes, there will be more than one. If there is an Egress Address Responder sub-TLV, then the branch node will include only one Downstream Detailed Mapping TLV corresponding to the downstream path required to reach the address specified in the Egress Address sub-TLV.
回波回复中报告的每个下游路径将有一个下游详细映射TLV。因此，对于传输节点，只有一个这样的TLV，而对于分支节点，将有多个TLV。如果存在出口地址响应器子TLV，则分支节点将仅包括一个下游详细映射TLV，对应于到达出口地址子TLV中指定的地址所需的下游路径。
The presence of a Responder Identifier TLV does not influence the choice of the Return Code. For a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379].
响应者标识符TLV的存在不会影响返回码的选择。对于成功响应，可将返回码设置为值3（'应答路由器是FEC在堆栈深度<RSC>处的出口'）。对于错误情况，请使用[RFC4379]中定义的适当值。
The presence of the Downstream Detailed Mapping TLV does not influence the choice of Return Code. Egress nodes do not put in any Downstream Detailed Mapping TLV in the echo reply [RFC6424].
下游详细映射TLV的存在不会影响返回代码的选择。出口节点不在echo应答[RFC6424]中放入任何下游详细映射TLV。
The case of bud nodes is more complex than other types of nodes. The node might behave as either an egress node or a transit node, or a combination of an egress and branch node. This behavior is
bud节点的情况比其他类型的节点更复杂。该节点可以作为出口节点或中转节点，或者出口节点和分支节点的组合。这种行为是错误的
determined by the presence of any Responder Identifier TLV and the type of sub-TLV in it. Similarly, the Downstream Detailed Mapping TLV can influence the Return Code values.
由任何响应者标识符TLV的存在及其子TLV的类型确定。类似地，下游详细映射TLV会影响返回代码值。
To determine the behavior of the bud node, use the following rules. The intent of these rules is to figure out if the echo request is meant for all nodes, or just this node, or for another node reachable through this node or for a different section of the tree. In the first case, the node will behave like a combination of egress and branch node; in the second case, the node will behave like pure egress node; in the third case, the node will behave like a transit node; and in the last case, no reply will be sent back.
要确定bud节点的行为，请使用以下规则。这些规则的目的是确定echo请求是针对所有节点，还是仅针对此节点，还是针对可通过此节点访问的另一个节点，或者针对树的不同部分。在第一种情况下，节点的行为类似于出口和分支节点的组合；在第二种情况下，节点将表现为纯出口节点；在第三种情况下，节点的行为类似于传输节点；在最后一种情况下，不会返回回复。
Node behavior rules:
节点行为规则：
- If the Responder Identifier TLV is not present, then the node will behave as a combination of egress and branch node.
- 如果响应器标识符TLV不存在，则节点将作为出口和分支节点的组合。
- If the Responder Identifier TLV containing a Node Address sub-TLV is present, and:
- 如果存在包含节点地址子TLV的响应者标识符TLV，并且：
- If the address specified in the sub-TLV matches to an address in the node, then the node will behave like a combination of egress and branch node.
- 如果子TLV中指定的地址与节点中的地址匹配，则节点的行为将类似于出口和分支节点的组合。
- If the address specified in the sub-TLV does not match any address in the node, then no reply will be sent.
- 如果子TLV中指定的地址与节点中的任何地址不匹配，则不会发送回复。
- If the Responder Identifier TLV containing an Egress Address sub-TLV is present, and:
- 如果存在包含出口地址子TLV的响应者标识符TLV，并且：
- If the address specified in the sub-TLV matches to an address in the node, then the node will behave like an egress node only.
- 如果子TLV中指定的地址与节点中的地址匹配，则该节点的行为将仅类似于出口节点。
- If the node lies on the path to the address specified in the sub-TLV, then the node will behave like a transit node.
- 如果节点位于子TLV中指定地址的路径上，则该节点的行为将类似于传输节点。
- If the node does not lie on the path to the address specified in the sub-TLV, then no reply will be sent.
- 如果节点不位于子TLV中指定地址的路径上，则不会发送回复。
Once the node behavior has been determined, the possible values for Return Codes are as follows:
一旦确定了节点行为，返回代码的可能值如下所示：
- If the node is behaving as an egress node only, then for a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined
- 如果该节点仅作为出口节点，则对于成功响应，返回码可设置为值3（“应答路由器是堆栈深度处FEC的出口<RSC>”。对于错误情况，请使用定义的适当值
in [RFC4379]. The echo reply MUST NOT contain any Downstream Detailed Mapping TLV, even if one is present in the echo request.
在[RFC4379]中。回送回复不得包含任何下游详细映射TLV，即使回送请求中存在。
- If the node is behaving as a transit node, and:
- 如果该节点作为运输节点运行，并且：
- If a Downstream Detailed Mapping TLV is not present, then for a success response, the Return Code MAY be set to value 8 ('Label switched at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379].
- 如果下游详细映射TLV不存在，则对于成功响应，可将返回代码设置为值8（“在堆栈深度处切换标签<RSC>）。对于错误情况，请使用[RFC4379]中定义的适当值。
- If a Downstream Detailed Mapping TLV is present, then the Return Code MAY be set to 'See DDM TLV for Return Code and Return Subcode' as defined in [RFC6424]. The Return Code for the Downstream Detailed Mapping TLV will depend on the downstream path as described in [RFC6424]. There will be only one Downstream Detailed Mapping corresponding to the downstream path to the address specified in the Egress Address sub-TLV.
- 如果存在下游详细映射TLV，则返回代码可设置为[RFC6424]中定义的“返回代码和返回子代码见DDM TLV”。下游详细映射TLV的返回代码将取决于[RFC6424]中所述的下游路径。只有一个下游详细映射对应于出口地址子TLV中指定的地址的下游路径。
- If the node is behaving as a combination of egress and branch node, and:
- 如果节点表现为出口和分支节点的组合，并且：
- If a Downstream Detailed Mapping TLV is not present, then for a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379].
- 如果下游详细映射TLV不存在，则对于成功响应，可将返回代码设置为值3（“应答路由器是堆栈深度处FEC的出口<RSC>”。对于错误情况，请使用[RFC4379]中定义的适当值。
- If a Downstream Detailed Mapping TLV is present, then for a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379]. The Return Code for the each Downstream Detailed Mapping TLV will depend on the downstream path as described in [RFC6424]. There will be a Downstream Detailed Mapping for each downstream path from the node.
- 如果存在下游详细映射TLV，则对于成功响应，可将返回码设置为值3（“应答路由器是堆栈深度处FEC的出口<RSC>”。对于错误情况，请使用[RFC4379]中定义的适当值。每个下游详细映射TLV的返回代码将取决于[RFC6424]中所述的下游路径。节点的每个下游路径都有一个下游详细映射。
As specified in [RFC4379], the traceroute mode operates by sending a series of echo requests with sequentially increasing TTL values. For regular P2P targets, this processing stops when a valid reply is received from the intended egress or when some errored return code is received.
如[RFC4379]中所述，跟踪路由模式通过发送一系列按顺序递增TTL值的回声请求来运行。对于常规P2P目标，当从预期出口收到有效回复或收到错误返回码时，此处理停止。
For P2MP targets, there may not be an easy way to figure out the end of the traceroute processing, as there are multiple egress nodes. Receiving a valid reply from an egress will not signal the end of processing.
对于P2MP目标，可能没有一种简单的方法来确定跟踪路由处理的结束，因为存在多个出口节点。从出口接收到有效回复并不表示处理结束。
For P2MP TE LSP, the initiating LSR has a priori knowledge about the number of egress nodes and their addresses. Hence, it is possible to continue processing until a valid reply has been received from each end point, provided that the replies can be matched correctly to the egress nodes.
对于P2MP-TE-LSP，发起LSR具有关于出口节点数量及其地址的先验知识。因此，可以继续处理，直到从每个端点接收到有效应答为止，前提是应答可以与出口节点正确匹配。
However, for Multicast LDP LSP, the initiating LSR might not always know about all of the egress nodes. Hence, there might not be a definitive way to estimate the end of processing for traceroute.
然而，对于多播LDP LSP，发起LSR可能并不总是知道所有出口节点。因此，可能没有确定的方法来估计跟踪路由的处理结束时间。
Therefore, it is RECOMMENDED that traceroute operations provide for a configurable upper limit on TTL values. Hence, the user can choose the depth to which the tree will be probed.
因此，建议跟踪路由操作提供TTL值的可配置上限。因此，用户可以选择探测树的深度。
The P2MP traceroute may continue even after it has received a valid reply from a bud or egress node, as there may be more nodes at deeper levels. Hence, for subsequent TTL values, a bud or egress node that has previously replied would continue to get new echo requests. Since each echo request is handled independently from previous requests, these bud and egress nodes will keep on responding to the traceroute echo requests. This can cause an extra processing burden for the initiating LSR and these bud or egress LSRs.
P2MP跟踪路由即使在从bud或出口节点接收到有效回复后也可以继续，因为在更深的层次上可能有更多的节点。因此，对于后续的TTL值，先前已应答的bud或出口节点将继续获得新的回显请求。由于每个回显请求都独立于以前的请求进行处理，因此这些bud和出口节点将继续响应跟踪路由回显请求。这可能会导致启动LSR和这些萌芽或出口LSR的额外处理负担。
To prevent a bud or egress node from sending multiple replies in the same traceroute operation, a new "Respond Only If TTL Expired" flag is being introduced. This flag is described in Section 3.4.
为了防止bud或出口节点在同一跟踪路由操作中发送多个回复，引入了一个新的“仅在TTL过期时响应”标志。第3.4节描述了该标志。
It is RECOMMENDED that this flag be used for P2MP traceroute mode only. By using this flag, extraneous replies from bud and egress nodes can be reduced. If PHP is being used in the P2MP tree, then bud and egress nodes will not get any labels with the echo request packet. Hence, this mechanism will not be effective for PHP scenarios.
建议此标志仅用于P2MP跟踪路由模式。通过使用此标志，可以减少来自bud和出口节点的无关回复。如果在P2MP树中使用PHP，则bud和出口节点将不会获得任何带有echo请求数据包的标签。因此，此机制对于PHP场景将无效。
There are multiple reasons for which an ingress node may not receive a reply to its echo request. For example, the transit node has failed or the transit node does not support LSP ping.
入口节点可能由于多种原因无法收到对其回显请求的回复。例如，传输节点出现故障或传输节点不支持LSP ping。
When no reply to an echo request is received by the ingress, then (as per [RFC4379]) the subsequent echo request with a larger TTL SHOULD be sent in order to trace further toward the egress, although the ingress MAY halt the procedure at this point. The time that an ingress waits before sending the subsequent echo request is an implementation choice.
当入口未收到回音请求的回复时，则（根据[RFC4379]）应发送具有较大TTL的后续回音请求，以便进一步跟踪出口，尽管入口此时可能会停止该过程。入口在发送后续回显请求之前等待的时间是一个实现选择。
As described in Section 4.6 of [RFC4379], an initiating LSR, during traceroute, SHOULD copy the Downstream Mapping(s) into its next echo request(s). However, for P2MP LSPs, the initiating LSR will receive multiple sets of Downstream Detailed Mapping TLVs from different nodes. It is not practical to copy all of them into the next echo request. Hence, this behavior is being modified for P2MP LSPs. If the echo request is destined for more than one node, then the Downstream IP Address field of the Downstream Detailed Mapping TLV MUST be set to the ALLROUTERS multicast address, and the Address Type field MUST be set to either IPv4 Unnumbered or IPv6 Unnumbered depending on the Target FEC Stack TLV.
如[RFC4379]第4.6节所述，在跟踪路由期间，发起LSR应将下游映射复制到其下一个回波请求中。然而，对于P2MP lsp，发起LSR将从不同节点接收多组下游详细映射tlv。将它们全部复制到下一个echo请求中是不切实际的。因此，正在针对P2MP LSP修改此行为。如果回送请求的目的地为多个节点，则下游详细映射TLV的下游IP地址字段必须设置为ALLROUTERS多播地址，地址类型字段必须设置为IPv4未编号或IPv6未编号，具体取决于目标FEC堆栈TLV。
If an Egress Address Responder sub-TLV is being used, then the traceroute is limited to only one egress. Therefore this traceroute is effectively behaving like a P2P traceroute. In this scenario, as per Section 4.2, the echo replies from intermediate nodes will contain only one Downstream Detailed Mapping TLV corresponding to the downstream path required to reach the address specified in the Egress Address sub-TLV. For this case, the echo request packet MAY reuse a received Downstream Detailed Mapping TLV. This will allow interface validation to be performed as per [RFC4379].
如果正在使用出口地址响应器子TLV，则跟踪路由仅限于一个出口。因此，此跟踪路由的行为实际上类似于P2P跟踪路由。在这种情况下，根据第4.2节，来自中间节点的回声应答将只包含一个下游详细映射TLV，对应于到达出口地址子TLV中指定地址所需的下游路径。对于这种情况，echo请求分组可以重用接收到的下游详细映射TLV。这将允许按照[RFC4379]执行接口验证。
A cross-over node will require slightly different processing for traceroute mode. The following definition of cross-over is taken from [RFC4875].
交叉节点需要对跟踪路由模式进行稍微不同的处理。以下交叉定义取自[RFC4875]。
The term "cross-over" refers to the case of an ingress or transit node that creates a branch of a P2MP LSP, a cross-over branch, that intersects the P2MP LSP at another node farther down the tree. It is unlike re-merge in that, at the intersecting node, the cross-over branch has a different outgoing interface as well as a different incoming interface.
术语“交叉”指的是入口或中转节点创建P2MP LSP分支的情况，即交叉分支，该分支在树下更远的另一个节点处与P2MP LSP相交。与重新合并不同的是，在相交节点处，交叉分支具有不同的传出接口和不同的传入接口。
During traceroute, a cross-over node will receive the echo requests via each of its input interfaces. Therefore, the Downstream Detailed Mapping TLV in the echo reply MUST carry information only about the outgoing interface corresponding to the input interface.
在跟踪路由期间，交叉节点将通过其每个输入接口接收回显请求。因此，echo应答中的下游详细映射TLV必须仅携带与输入接口对应的传出接口的信息。
If this restriction is applied, the cross-over node will not duplicate the outgoing interface information in each of the echo request it receives via the different input interfaces. This will reflect the actual packet replication in the data plane.
如果应用此限制，则交叉节点将不会在通过不同输入接口接收的每个回显请求中复制传出接口信息。这将反映数据平面中的实际数据包复制。
If a node for a P2MP LSP does not support MPLS LSP ping, then no reply will be sent, causing an incorrect result on the initiating LSR. There is no protection for this situation, and operators may wish to ensure that all nodes for P2MP LSPs are all equally capable of supporting this function.
如果P2MP LSP的节点不支持MPLS LSP ping，则不会发送回复，从而导致启动LSR的结果不正确。这种情况没有保护措施，运营商可能希望确保P2MP LSP的所有节点都具有同等能力支持此功能。
If the non-compliant node is an egress, then the traceroute mode can be used to verify the LSP nearly all the way to the egress, leaving the final hop to be verified manually.
如果不兼容节点是出口，则跟踪路由模式可用于验证几乎一直到出口的LSP，将最后一跳留给手动验证。
If the non-compliant node is a branch or transit node, then it should not impact ping mode. However the node will not respond during traceroute mode.
如果不兼容节点是分支或传输节点，则不应影响ping模式。但是，节点在跟踪路由模式下不会响应。
The procedures in this document provide OAM functions for P2MP MPLS LSPs and may be used to enable bootstrapping of other OAM procedures.
本文档中的过程为P2MP MPLS LSP提供OAM功能，并可用于启用其他OAM过程的引导。
In order to be fully operational, several considerations apply.
为了全面运行，需要考虑以下几点。
- Scaling concerns dictate that only cautious use of LSP ping should be made. In particular, sending an LSP ping to all egresses of a P2MP MPLS LSP could result in congestion at or near the ingress when the replies arrive.
- 考虑到扩展性，只需谨慎使用LSP ping。特别地，当应答到达时，向P2MP MPLS LSP的所有出口发送LSP ping可能导致入口处或入口附近的拥塞。
Further, incautious use of timers to generate LSP ping echo requests either in ping mode or especially in traceroute may lead to significant degradation of network performance.
此外，在ping模式下或特别是在traceroute中不小心使用定时器来生成LSP ping echo请求可能会导致网络性能的显著降低。
- Management interfaces should allow an operator full control over the operation of LSP ping. In particular, such interfaces should provide the ability to limit the scope of an LSP ping echo request for a P2MP MPLS LSP to a single egress.
- 管理界面应允许操作员完全控制LSP ping的操作。特别是，此类接口应提供将P2MP MPLS LSP的LSP ping echo请求的范围限制为单个出口的能力。
Such interfaces should also provide the ability to disable all active LSP ping operations, to provide a quick escape if the network becomes congested.
此类接口还应提供禁用所有活动LSP ping操作的能力，以便在网络拥塞时提供快速转义。
- A MIB module is required for the control and management of LSP ping operations, and to enable the reported information to be inspected.
- 需要一个MIB模块来控制和管理LSP ping操作，并能够检查报告的信息。
There is no reason to believe this should not be a simple extension of the LSP ping MIB module used for P2P LSPs.
没有理由相信这不应该是用于P2P LSP的LSP ping MIB模块的简单扩展。
Four new sub-TLV types are defined for inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV type 1).
定义了四种新的子TLV类型，以包含在LSP ping[RFC4379]目标FEC堆栈TLV（TLV类型1）中。
IANA has assigned sub-type values to the following sub-TLVs under TLV type 1 (Target FEC Stack) from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry.
IANA已从“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表、“TLV和子TLV”子注册表将子类型值分配给TLV类型1（目标FEC堆栈）下的以下子TLV。
17 RSVP P2MP IPv4 Session (Section 3.1.1) 18 RSVP P2MP IPv6 Session (Section 3.1.1) 19 Multicast P2MP LDP FEC Stack (Section 3.1.2) 20 Multicast MP2MP LDP FEC Stack (Section 3.1.2)
17 RSVP P2MP IPv4会话（第3.1.1节）18 RSVP P2MP IPv6会话（第3.1.1节）19多播P2MP LDP FEC堆栈（第3.1.2节）20多播MP2MP LDP FEC堆栈（第3.1.2节）
Two new LSP ping TLV types are defined for inclusion in LSP ping messages.
定义了两种新的LSP ping TLV类型，以包含在LSP ping消息中。
IANA has assigned a new value from the "Multi-Protocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry as follows using a Standards Action value.
IANA使用标准操作值从“多协议标签交换体系结构（MPLS）标签交换路径（LSP）Ping参数”注册表、“TLV和子TLV”子注册表中分配了一个新值，如下所示。
11 P2MP Responder Identifier TLV (see Section 3.2) is a mandatory TLV.
11 P2MP应答器标识符TLV（见第3.2节）为强制性TLV。
Four sub-TLVs are defined. - Sub-Type 1: IPv4 Egress Address P2MP Responder - Sub-Type 2: IPv6 Egress Address P2MP Responder - Sub-Type 3: IPv4 Node Address P2MP Responder - Sub-Type 4: IPv6 Node Address P2MP Responder
定义了四个子TLV。-子类型1:IPv4出口地址P2MP响应器-子类型2:IPv6出口地址P2MP响应器-子类型3:IPv4节点地址P2MP响应器-子类型4:IPv6节点地址P2MP响应器
12 Echo Jitter TLV (see Section 3.3) is a mandatory TLV.
12回波抖动TLV（见第3.3节）是强制性TLV。
IANA has created a new sub-registry of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. The sub-registry is called the "Global Flags" registry.
IANA创建了“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表的新子注册表。子注册表称为“全局标志”注册表。
This registry tracks the assignment of 16 flags in the Global Flags field of the MPLS LSP ping echo request message. The flags are numbered from 0 (most significant bit, transmitted first) to 15.
此注册表跟踪MPLS LSP ping回显请求消息的全局标志字段中16个标志的分配。标志的编号从0（最高有效位，首先传输）到15。
New entries are assigned by Standards Action.
新条目由标准操作分配。
Initial entries in the registry are as follows:
登记处的初始条目如下：
Bit number | Name | Reference
------------+----------------------------+--------------
15 | V Flag | [RFC4379]
14 | T Flag | [RFC6425]
13-0 | Unassigned |
Bit number | Name | Reference
------------+----------------------------+--------------
15 | V Flag | [RFC4379]
14 | T Flag | [RFC6425]
13-0 | Unassigned |
This document does not introduce security concerns over and above those described in [RFC4379]. Note that because of the scalability implications of many egresses to P2MP MPLS LSPs, there is a stronger concern about regulating the LSP ping traffic passed to the control plane by the use of a rate limiter applied to the LSP ping well-known UDP port. This rate limiting might lead to false indications of LSP failure.
除[RFC4379]中所述的安全问题外，本文件并未引入安全问题。注意，由于许多出口对P2MP MPLS LSP的可伸缩性影响，因此更关注通过使用应用于LSP ping众所周知的UDP端口的速率限制器来调节传递到控制平面的LSP ping流量。此速率限制可能导致LSP故障的错误指示。
The authors would like to acknowledge the authors of [RFC4379] for their work, which is substantially re-used in this document. Also, thanks to the members of the MBONED working group for their review of this material, to Daniel King and Mustapha Aissaoui for their reviews, and to Yakov Rekhter for useful discussions.
作者要感谢[RFC4379]的作者所做的工作，这些工作在本文件中大量重复使用。此外，感谢MBONED工作组成员对本材料的审查，感谢Daniel King和Mustapha Aissaoui的审查，感谢Yakov Rekhter的有益讨论。
The authors would like to thank Bill Fenner, Vanson Lim, Danny Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar, Sam Aldrin, and IJsbrand Wijnands for their comments and suggestions.
作者要感谢Bill Fenner、Vanson Lim、Danny Prairie、Reshad Rahman、Ben Niven Jenkins、Hannes Gredler、Nitin Bahadur、Tetsuya Murakami、Michael Hua、Michael Wildt、Dipa Thakkar、Sam Aldrin和IJsbrand Wijnands的评论和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing LSP-Ping over MPLS Tunnels", RFC 6424, November 2011.
[RFC6424]Bahadur，N.，Kompella，K.，和G.Swallow，“在MPLS隧道上执行LSP Ping的机制”，RFC 64242011年11月。
[IANA-AF] IANA Assigned Port Numbers, <http://www.iana.org/assignments/address-family-numbers>.
[IANA-AF]IANA分配的端口号<http://www.iana.org/assignments/address-family-numbers>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]Yasukawa，S.，Ed.“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006.
[RFC4687]Yasukawa，S.，Farrel，A.，King，D.，和T.Nadeau，“点对多点MPLS网络的运营和管理（OAM）要求”，RFC 4687，2006年9月。
[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, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[RFC6348] Le Roux, JL., Ed., and T. Morin, Ed., "Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol", RFC 6348, September 2011.
[RFC6348]Le Roux，JL.，Ed.，和T.Morin，Ed.，“标签分发协议的点对多点扩展要求”，RFC 6348，2011年9月。
[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, November 2011.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月。
Authors' Addresses
作者地址
Shaleen Saxena Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 EMail: ssaxena@cisco.com
Shaleen Saxena Cisco Systems，Inc.马萨诸塞州Boxborough大道1414号，邮编01719电子邮件：ssaxena@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 EMail: swallow@cisco.com
George Swallow Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号邮编01719电子邮件：swallow@cisco.com
Zafar Ali Cisco Systems Inc. 2000 Innovation Drive Kanata, ON, K2K 3E8, Canada. Phone: 613-889-6158 EMail: zali@cisco.com
Zafar Ali Cisco Systems Inc.位于加拿大卡纳塔创新大道2000号，邮编：K2K 3E8。电话：613-889-6158电子邮件：zali@cisco.com
Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk
Adrian Farrel Juniper Networks电子邮件：adrian@olddog.co.uk
Seisho Yasukawa NTT Corporation 3-9-11, Midori-Cho Musashino-Shi Tokyo 180-8585 Japan Phone: +81 422 59 2684 EMail: yasukawa.seisho@lab.ntt.co.jp
靖川正雄NTT公司3-9-11，中藤町武藏市东京180-8585日本电话：+81 422 59 2684电子邮件：靖川。seisho@lab.ntt.co.jp
Thomas D. Nadeau CA Technologies, Inc. 273 Corporate Drive Portsmouth, NH 03801
Thomas D.Nadeau CA Technologies，Inc.地址：新罕布什尔州朴茨茅斯市企业大道273号，邮编：03801
EMail: thomas.nadeau@ca.com
EMail: thomas.nadeau@ca.com