Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 8029 Juniper Networks, Inc.
Obsoletes: 4379, 6424, 6829, 7537 G. Swallow
Updates: 1122 C. Pignataro, Ed.
Category: Standards Track N. Kumar
ISSN: 2070-1721 Cisco
S. Aldrin
Google
M. Chen
Huawei
March 2017
Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 8029 Juniper Networks, Inc.
Obsoletes: 4379, 6424, 6829, 7537 G. Swallow
Updates: 1122 C. Pignataro, Ed.
Category: Standards Track N. Kumar
ISSN: 2070-1721 Cisco
S. Aldrin
Google
M. Chen
Huawei
March 2017
Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures
检测多协议标签交换（MPLS）数据平面故障
Abstract
摘要
This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.
本文档描述了一种简单有效的机制，用于检测多协议标签交换（MPLS）标签交换路径（LSP）中的数据平面故障。它定义了一个称为“MPLS回显请求”的探测消息和一个称为“MPLS回显回复”的响应消息，用于返回探测结果。MPLS回波请求旨在包含足够的信息，以检查数据平面的正确操作，并对照控制平面验证数据平面，从而定位故障。
This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.
本文件淘汰了RFC 4379、6424、6829和7537，并更新了RFC 1122。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8029.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8029.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Structure of This Document . . . . . . . . . . . . . . . 6
1.3. Scope of This Specification . . . . . . . . . . . . . . . 6
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Use of Address Range 127/8 . . . . . . . . . . . . . . . 8
2.2. Router Alert Option . . . . . . . . . . . . . . . . . . . 10
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 17
3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . . 19
3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . . 19
3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . . 20
3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . . 20
3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . . 21
3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . . 22
3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . . 23
3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 23
3.2.9. FEC 128 Pseudowire - IPv4 (Current) . . . . . . . . . 24
3.2.10. FEC 129 Pseudowire - IPv4 . . . . . . . . . . . . . . 25
3.2.11. FEC 128 Pseudowire - IPv6 . . . . . . . . . . . . . . 26
3.2.12. FEC 129 Pseudowire - IPv6 . . . . . . . . . . . . . . 27
3.2.13. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . . 28
3.2.14. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . . 28
3.2.15. Generic IPv4 Prefix . . . . . . . . . . . . . . . . . 29
3.2.16. Generic IPv6 Prefix . . . . . . . . . . . . . . . . . 29
3.2.17. Nil FEC . . . . . . . . . . . . . . . . . . . . . . . 29
3.3. Downstream Mapping (Deprecated) . . . . . . . . . . . . . 30
3.4. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 30
3.4.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 34
3.4.2. Downstream Router and Interface . . . . . . . . . . . 40
3.5. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6. Vendor Enterprise Number . . . . . . . . . . . . . . . . 41
3.7. Interface and Label Stack . . . . . . . . . . . . . . . . 42
3.8. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 43
3.9. Reply TOS Octet TLV . . . . . . . . . . . . . . . . . . . 44
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 44
4.1. Dealing with Equal-Cost Multipath (ECMP) . . . . . . . . 44
4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . . 45
4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 46
4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 47
4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 53
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Structure of This Document . . . . . . . . . . . . . . . 6
1.3. Scope of This Specification . . . . . . . . . . . . . . . 6
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Use of Address Range 127/8 . . . . . . . . . . . . . . . 8
2.2. Router Alert Option . . . . . . . . . . . . . . . . . . . 10
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 17
3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . . 19
3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . . 19
3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . . 20
3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . . 20
3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . . 21
3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . . 22
3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . . 23
3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 23
3.2.9. FEC 128 Pseudowire - IPv4 (Current) . . . . . . . . . 24
3.2.10. FEC 129 Pseudowire - IPv4 . . . . . . . . . . . . . . 25
3.2.11. FEC 128 Pseudowire - IPv6 . . . . . . . . . . . . . . 26
3.2.12. FEC 129 Pseudowire - IPv6 . . . . . . . . . . . . . . 27
3.2.13. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . . 28
3.2.14. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . . 28
3.2.15. Generic IPv4 Prefix . . . . . . . . . . . . . . . . . 29
3.2.16. Generic IPv6 Prefix . . . . . . . . . . . . . . . . . 29
3.2.17. Nil FEC . . . . . . . . . . . . . . . . . . . . . . . 29
3.3. Downstream Mapping (Deprecated) . . . . . . . . . . . . . 30
3.4. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 30
3.4.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 34
3.4.2. Downstream Router and Interface . . . . . . . . . . . 40
3.5. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6. Vendor Enterprise Number . . . . . . . . . . . . . . . . 41
3.7. Interface and Label Stack . . . . . . . . . . . . . . . . 42
3.8. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 43
3.9. Reply TOS Octet TLV . . . . . . . . . . . . . . . . . . . 44
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 44
4.1. Dealing with Equal-Cost Multipath (ECMP) . . . . . . . . 44
4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . . 45
4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 46
4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 47
4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 53
4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 54
4.5.1. Addition of a New Tunnel . . . . . . . . . . . . . . 55
4.5.2. Transition between Tunnels . . . . . . . . . . . . . 56
4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 56
4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . . 58
4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . . 59
5. Security Considerations . . . . . . . . . . . . . . . . . . . 59
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
6.1. TCP and UDP Port Number . . . . . . . . . . . . . . . . . 61
6.2. MPLS LSP Ping Parameters . . . . . . . . . . . . . . . . 61
6.2.1. Message Types, Reply Modes, Return Codes . . . . . . 61
6.2.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.3. Global Flags . . . . . . . . . . . . . . . . . . . . 64
6.2.4. Downstream Detailed Mapping Address Type . . . . . . 64
6.2.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . 65
6.2.6. Multipath Types . . . . . . . . . . . . . . . 66
6.2.7. Pad Type . . . . . . . . . . . . . . . . . . . . . . 66
6.2.8. Interface and Label Stack Address Type . . . . . . . 67
6.3. IPv4 Special-Purpose Address Registry . . . . . . . . . . 67
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1. Normative References . . . . . . . . . . . . . . . . . . 67
7.2. Informative References . . . . . . . . . . . . . . . . . 68
Appendix A. Deprecated TLVs and Sub-TLVs (Non-normative) . . . . 72
A.1. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 72
A.1.1. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 72
A.2. Downstream Mapping (Deprecated) . . . . . . . . . . . . . 72
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 77
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 54
4.5.1. Addition of a New Tunnel . . . . . . . . . . . . . . 55
4.5.2. Transition between Tunnels . . . . . . . . . . . . . 56
4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 56
4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . . 58
4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . . 59
5. Security Considerations . . . . . . . . . . . . . . . . . . . 59
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
6.1. TCP and UDP Port Number . . . . . . . . . . . . . . . . . 61
6.2. MPLS LSP Ping Parameters . . . . . . . . . . . . . . . . 61
6.2.1. Message Types, Reply Modes, Return Codes . . . . . . 61
6.2.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.3. Global Flags . . . . . . . . . . . . . . . . . . . . 64
6.2.4. Downstream Detailed Mapping Address Type . . . . . . 64
6.2.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . 65
6.2.6. Multipath Types . . . . . . . . . . . . . . . 66
6.2.7. Pad Type . . . . . . . . . . . . . . . . . . . . . . 66
6.2.8. Interface and Label Stack Address Type . . . . . . . 67
6.3. IPv4 Special-Purpose Address Registry . . . . . . . . . . 67
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1. Normative References . . . . . . . . . . . . . . . . . . 67
7.2. Informative References . . . . . . . . . . . . . . . . . 68
Appendix A. Deprecated TLVs and Sub-TLVs (Non-normative) . . . . 72
A.1. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 72
A.1.1. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 72
A.2. Downstream Mapping (Deprecated) . . . . . . . . . . . . . 72
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 77
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
This document describes a simple and efficient mechanism to detect data-plane failures in MPLS Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, thereby localizing faults.
本文档描述了一种简单有效的机制，用于检测MPLS标签交换路径（LSP）中的数据平面故障。它定义了一个称为“MPLS回显请求”的探测消息和一个称为“MPLS回显回复”的响应消息，用于返回探测结果。MPLS回波请求旨在包含足够的信息来检查数据平面的正确操作，以及根据控制平面验证数据平面的机制，从而定位故障。
An important consideration in this design is that MPLS echo requests follow the same data path that normal MPLS packets would traverse. MPLS echo requests are meant primarily to validate the data plane and secondarily to verify the data plane against the control plane. Mechanisms to check the control plane are valuable but are not covered in this document.
在这种设计中，一个重要的考虑因素是MPLS回送请求遵循与普通MPLS数据包相同的数据路径。MPLS回送请求主要用于验证数据平面，其次用于对照控制平面验证数据平面。检查控制平面的机构很有价值，但本文件未涉及。
This document makes special use of the address range 127/8. This is an exception to the behavior defined in RFC 1122 [RFC1122], and this specification updates that RFC. The motivation for this change and the details of this exceptional use are discussed in Section 2.1 below.
本文档特别使用地址范围127/8。这是RFC 1122[RFC1122]中定义的行为的一个例外，本规范更新了该RFC。下文第2.1节讨论了这一变化的动机和这一特殊用途的细节。
This document obsoletes RFC 4379 [RFC4379], RFC 6424 [RFC6424], RFC 6829 [RFC6829], and RFC 7537 [RFC7537].
本文件淘汰了RFC 4379[RFC4379]、RFC 6424[RFC6424]、RFC 6829[RFC6829]和RFC 7537[RFC7537]。
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 term "Must Be Zero" (MBZ) is used in object descriptions for reserved fields. These fields MUST be set to zero when sent and ignored on receipt.
术语“必须为零”（MBZ）用于保留字段的对象描述中。这些字段在发送时必须设置为零，在接收时忽略。
Terminology pertaining to L2 and L3 Virtual Private Networks (VPNs) is defined in [RFC4026].
[RFC4026]中定义了与二级和三级虚拟专用网络（VPN）相关的术语。
Since this document refers to the MPLS Time to Live (TTL) far more frequently than the IP TTL, the authors have chosen the convention of using the unqualified "TTL" to mean "MPLS TTL" and using "IP TTL" for the TTL value in the IP header.
由于本文档提及MPLS生存时间（TTL）的频率远高于IP TTL，因此作者选择了使用不合格的“TTL”表示“MPLS TTL”，并在IP报头中使用“IP TTL”表示TTL值的约定。
The body of this memo contains four main parts: motivation, MPLS echo request/reply packet format, LSP ping operation, and a reliable return path. It is suggested that first-time readers skip the actual packet formats and read the "Theory of Operation" (Section 4) first; the document is structured the way it is to avoid forward references.
本备忘录正文包含四个主要部分：动机、MPLS回送请求/回复数据包格式、LSP ping操作和可靠的返回路径。建议初次阅读的读者跳过实际的数据包格式，先阅读“操作原理”（第4节）；文档的结构是避免转发引用的。
The primary goal of this document is to provide a clean and updated LSP ping specification.
本文档的主要目标是提供一个干净且更新的LSP ping规范。
[RFC4379] defines the basic mechanism for MPLS LSP validation that can be used for fault detection and isolation. The scope of this document also includes various updates to MPLS LSP ping, including:
[RFC4379]定义了可用于故障检测和隔离的MPLS LSP验证的基本机制。本文档的范围还包括对MPLS LSP ping的各种更新，包括：
o Update all references and citations.
o 更新所有参考文献和引文。
* Obsoleted RFCs 2434, 2030, and 3036 are respectively replaced with RFCs 5226, 5905, and 5036.
* 废弃的RFC 2434、2030和3036分别由RFC 5226、5905和5036替代。
* Additionally, some informative references were published as RFCs: RFCs 4761, 5085, 5885, and 8077.
* 此外，一些资料性参考文献作为RFCs发布：RFCs 4761、5085、5885和8077。
o Incorporate all outstanding RFC errata.
o 合并所有未完成的RFC勘误表。
* See [Err108], [Err742], [Err1418], [Err1714], [Err1786], [Err2978], [Err3399].
* 参见[Err108]、[Err742]、[Err1418]、[Err1714]、[Err1786]、[Err2978]、[Err3399]。
o Replace EXP with Traffic Class (TC), based on the update from RFC 5462.
o 根据RFC 5462的更新，将EXP替换为流量等级（TC）。
o Incorporate the updates from RFC 6829, by adding the pseudowire (PW) Forwarding Equivalence Classes (FECs) advertised over IPv6 and obsoleting RFC 6829.
o 通过添加通过IPv6发布的伪线（PW）转发等价类（FEC）并淘汰RFC 6829，合并来自RFC 6829的更新。
o Incorporate the updates from RFC 7506, by adding the IPv6 Router Alert Option (RAO) for MPLS Operations, Administration, and Maintenance (OAM).
o 通过添加用于MPLS操作、管理和维护（OAM）的IPv6路由器警报选项（RAO），合并来自RFC 7506的更新。
o Incorporate newly defined bits on the Global Flags field from RFCs 6425 and 6426.
o 在RFCs 6425和6426的全局标志字段中合并新定义的位。
o Update the IPv4 addresses used in examples to utilize the documentation prefix. Add examples with IPv6 addresses.
o 更新示例中使用的IPv4地址以利用文档前缀。添加具有IPv6地址的示例。
o Incorporate the updates from RFC 6424, by deprecating the Downstream Mapping TLV (DSMAP) and adding the Downstream Detailed Mapping TLV (DDMAP); updating two new Return Codes; adding the motivations of tunneled or stitched LSPs; updating the procedures, IANA considerations, and security considerations; and obsoleting RFC 6424.
o 通过弃用下游映射TLV（DSMAP）并添加下游详细映射TLV（DDMAP），合并来自RFC 6424的更新；更新两个新的返回代码；添加隧道或缝合LSP的动机；更新程序、IANA注意事项和安全注意事项；以及淘汰RFC6424。
o Incorporate the updates from RFC 7537, by updating the IANA Considerations section and obsoleting RFC 7537.
o 通过更新IANA注意事项部分并淘汰RFC 7537，合并RFC 7537的更新。
o Finally, obsolete RFC 4379.
o 最后，过时的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 would enable users to detect such traffic "black holes" or misrouting within a reasonable period of time and a mechanism to isolate faults.
当LSP无法交付用户流量时，MPLS控制平面无法始终检测到该故障。需要提供一种工具，使用户能够在合理的时间内检测此类流量“黑洞”或错误路由，并提供一种隔离故障的机制。
In this document, we describe a mechanism that accomplishes these goals. This mechanism is modeled after the ping/traceroute paradigm: ping (ICMP echo request [RFC0792]) is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing. This document specifies a "ping" mode and a "traceroute" mode for testing MPLS LSPs.
在本文档中，我们描述了实现这些目标的机制。该机制是按照ping/traceroute范式建模的：ping（ICMP echo request[RFC0792]）用于连接检查，traceroute用于逐跳故障定位和路径跟踪。本文档指定了用于测试MPLS LSP的“ping”模式和“traceroute”模式。
The basic idea is to verify that packets that belong to a particular FEC actually end their MPLS path on a Label Switching Router (LSR) that is an egress for that FEC. This document proposes that this test be carried out 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 whether 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 to confirm that it is indeed a transit LSR for this path; this LSR also returns further information that helps check the control plane against the data plane, i.e., that forwarding matches what the routing protocols determined as the path.
其基本思想是验证属于特定FEC的数据包是否在作为该FEC出口的标签交换路由器（LSR）上实际结束其MPLS路径。本文件建议通过沿着与属于该FEC的其他数据包相同的数据路径发送数据包（称为“MPLS回送请求”）来执行该测试。MPLS回显请求还携带有关正在验证其MPLS路径的FEC的信息。该回显请求与属于该FEC的任何其他数据包一样被转发。在“ping”模式（基本连接性检查）下，分组应该到达路径的末端，在该点它被发送到出口LSR的控制平面，然后该控制平面验证它是否确实是FEC的出口。在“跟踪路由”模式（故障隔离）下，数据包被发送到每个传输LSR的控制平面，该控制平面执行各种检查以确认它确实是该路径的传输LSR；此LSR还返回有助于对照数据平面检查控制平面的进一步信息，即转发匹配路由协议确定的路径。
An LSP traceroute may cross a tunneled or stitched LSP en route to the destination. While performing end-to-end LSP validation in such scenarios, the FEC information included in the packet by the Initiator may be different from the one assigned by the transit node in a different segment of a stitched LSP or tunnel. Let us consider a simple case.
LSP追踪路由可在通往目的地的途中穿过隧道或缝合LSP。当在这样的场景中执行端到端LSP验证时，由发起方包括在分组中的FEC信息可能不同于由缝合LSP或隧道的不同段中的传输节点分配的FEC信息。让我们考虑一个简单的例子。
A B C D E
o -------- o -------- o --------- o --------- o
\_____/ | \______/ \______/ | \______/
LDP | RSVP RSVP | LDP
| |
\____________________/
LDP
A B C D E
o -------- o -------- o --------- o --------- o
\_____/ | \______/ \______/ | \______/
LDP | RSVP RSVP | LDP
| |
\____________________/
LDP
When an LSP traceroute is initiated from Router A to Router E, the FEC information included in the packet will be LDP while Router C along the path is a pure RSVP node and does not run LDP. Consequently, node C will be unable to perform FEC validation. The MPLS echo request should contain sufficient information to allow any transit node within a stitched or tunneled LSP to perform FEC validations to detect any misrouted echo requests.
当从路由器A到路由器E发起LSP跟踪路由时，包中包含的FEC信息将是LDP，而路径上的路由器C是纯RSVP节点，不运行LDP。因此，节点C将无法执行FEC验证。MPLS回送请求应包含足够的信息，以允许缝合或隧道LSP内的任何传输节点执行FEC验证，以检测任何错误路由的回送请求。
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 periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs and thus should be used with caution.
使用这些工具的一种方法是定期ping FEC以确保连接。如果ping失败，则可以启动跟踪路由以确定故障所在。还可以周期性地跟踪路由fec以验证转发与控制平面匹配；然而，这给过境LSR带来了更大的负担，因此应谨慎使用。
As described above, LSP ping is intended as a diagnostic tool. It is intended to enable providers of an MPLS-based service to isolate network faults. In particular, LSP ping needs to diagnose situations where the control and data planes are out of sync. It performs this by routing an MPLS echo request packet based solely on its label stack. That is, the IP destination address is never used in a forwarding decision. In fact, the sender of an MPLS echo request packet may not know, a priori, the address of the router at the end of the LSP.
如上所述，LSP ping旨在作为一种诊断工具。它旨在使基于MPLS的服务提供商能够隔离网络故障。特别是，LSP ping需要诊断控制平面和数据平面不同步的情况。它通过仅基于其标签堆栈路由MPLS回显请求数据包来执行此操作。也就是说，在转发决策中从不使用IP目标地址。事实上，MPLS echo请求包的发送方可能事先不知道LSP末端路由器的地址。
Providers of MPLS-based services also need the ability to trace all of the possible paths that an LSP may take. Since most MPLS services are based on IP unicast forwarding, these paths are subject to Equal-Cost Multipath (ECMP) load sharing.
基于MPLS的服务提供商还需要能够跟踪LSP可能采用的所有可能路径。由于大多数MPLS服务基于IP单播转发，因此这些路径受等成本多路径（ECMP）负载共享的影响。
This leads to the following requirements:
这导致了以下要求：
1. Although the LSP in question may be broken in unknown ways, the likelihood of a diagnostic packet being delivered to a user of an MPLS service MUST be held to an absolute minimum.
1. 尽管所讨论的LSP可能以未知的方式被破坏，但是诊断分组被交付给MPLS服务的用户的可能性必须保持在绝对最小。
2. If an LSP is broken in such a way that it prematurely terminates, the diagnostic packet MUST NOT be IP forwarded.
2. 如果LSP以提前终止的方式断开，则诊断数据包不得IP转发。
3. A means of varying the diagnostic packets such that they exercise all ECMP paths is thus REQUIRED.
3. 因此，需要一种改变诊断数据包的方法，以便它们执行所有ECMP路径。
Clearly, using general unicast addresses satisfies neither of the first two requirements. A number of other options for addresses were considered, including a portion of the private address space (as determined by the network operator) and the IPv4 link-local addresses. Use of the private address space was deemed ineffective since the leading MPLS-based service is an IPv4 VPN. VPNs often use private addresses.
显然，使用通用单播地址不能满足前两个要求。考虑了许多其他地址选项，包括一部分专用地址空间（由网络运营商确定）和IPv4链路本地地址。使用专用地址空间被认为是无效的，因为主要的基于MPLS的服务是IPv4 VPN。VPN通常使用专用地址。
The IPv4 link-local addresses are more attractive in that the scope over which they can be forwarded is limited. However, if one were to use an address from this range, it would still be possible for the first recipient of a diagnostic packet that "escaped" from a broken LSP to have that address assigned to the interface on which it arrived and thus could mistakenly receive such a packet. Older deployed routers may not (correctly) implement IPv4 link-local addresses and would forward a packet with an address from that range toward the default route.
IPv4链路本地地址更具吸引力，因为它们可以转发的范围有限。然而，如果要使用此范围内的地址，则从损坏的LSP“逃逸”的诊断数据包的第一个接收者仍有可能将该地址分配给其到达的接口，因此可能会错误地接收此类数据包。较旧的已部署路由器可能无法（正确）实现IPv4链路本地地址，并且会将包含该范围内地址的数据包转发到默认路由。
The 127/8 range for IPv4 and that same range embedded in an IPv4-mapped IPv6 address for IPv6 was chosen for a number of reasons.
选择IPv4的127/8范围以及嵌入IPv6的IPv4映射IPv6地址中的相同范围有许多原因。
RFC 1122 allocates the 127/8 as the "Internal host loopback address" and states: "Addresses of this form MUST NOT appear outside a host." Thus, the default behavior of hosts is to discard such packets. This helps to ensure that if a diagnostic packet is misdirected to a host, it will be silently discarded.
RFC1122将127/8分配为“内部主机环回地址”，并声明：“此形式的地址不得出现在主机外部。”因此，主机的默认行为是丢弃此类数据包。这有助于确保如果诊断数据包被错误地定向到主机，它将被悄悄地丢弃。
RFC 1812 [RFC1812] states:
RFC 1812[RFC1812]规定：
A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks.
除非通过环回接口，否则路由器不应转发在网络127上具有目的地地址的任何数据包。路由器可能有一个交换机，允许网络管理器禁用这些检查。如果提供了此类开关，则必须默认执行检查。
This helps to ensure that diagnostic packets are never IP forwarded.
这有助于确保诊断数据包永远不会被IP转发。
The 127/8 address range provides 16M addresses allowing wide flexibility in varying addresses to exercise ECMP paths. Finally, as an implementation optimization, the 127/8 range provides an easy means of identifying possible LSP packets.
127/8地址范围提供16M地址，允许在不同的地址中灵活地使用ECMP路径。最后，作为实现优化，127/8范围提供了识别可能的LSP分组的简单方法。
This document requires the use of the RAO set in an IP header in order to have the transit node process the MPLS OAM payload.
本文档要求使用IP报头中的RAO集，以便让传输节点处理MPLS OAM有效负载。
[RFC2113] defines a generic Option Value 0x0 for IPv4 RAO that alerts the transit router to examine the IPv4 packet. [RFC7506] defines MPLS OAM Option Value 69 for IPv6 RAO to alert transit routers to examine the IPv6 packet more closely for MPLS OAM purposes.
[RFC2113]为IPv4 RAO定义一个通用选项值0x0，用于提醒传输路由器检查IPv4数据包。[RFC7506]为IPv6 RAO定义MPLS OAM选项值69，以提醒传输路由器为了MPLS OAM目的更仔细地检查IPv6数据包。
The use of the Router Alert IP Option in this document is as follows:
本文档中路由器警报IP选项的使用如下：
In case of an IPv4 header, the generic IPv4 RAO value 0x0 [RFC2113] SHOULD be used. In case of an IPv6 header, the IPv6 RAO value (69) for MPLS OAM [RFC7506] MUST be used.
对于IPv4报头，应使用通用IPv4 RAO值0x0[RFC2113]。对于IPv6报头，必须使用MPLS OAM[RFC7506]的IPv6 RAO值（69）。
An MPLS echo request/reply is a (possibly labeled) IPv4 or IPv6 UDP packet; the contents of the UDP packet have the following format:
MPLS回送请求/应答是（可能标记为）IPv4或IPv6 UDP数据包；UDP数据包的内容具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply Mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply Mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Version Number is currently 1. (Note: the version number is to be incremented whenever a change is made that affects the ability of an implementation to correctly parse or process an MPLS echo request/ reply. These changes include any syntactic or semantic changes made to any of the fixed fields, or to any Type-Length-Value (TLV) or sub-TLV assignment or format that is defined at a certain version number. The version number may not need to be changed if an optional TLV or sub-TLV is added.)
版本号当前为1。（注意：每当发生影响实现正确解析或处理MPLS回送请求/回复的能力的更改时，版本号将增加。这些更改包括对任何固定字段或任何类型长度值（TLV）进行的任何语法或语义更改或在特定版本号上定义的子TLV分配或格式。如果添加可选TLV或子TLV，则可能不需要更改版本号。）
The Global Flags field is a bit vector with the following format:
全局标志字段是具有以下格式的位向量：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |R|T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |R|T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
At the time of writing, three flags are defined: the R, T, and V bits; the rest MUST be set to zero when sending and ignored on receipt.
在写入时，定义了三个标志：R、T和V位；发送时，其余部分必须设置为零，接收时忽略。
The V (Validate FEC Stack) flag is set to 1 if the sender wants the receiver to perform FEC Stack validation; if V is 0, the choice is left to the receiver.
如果发送方希望接收方执行FEC堆栈验证，则V（验证FEC堆栈）标志设置为1；如果V为0，则由接收器选择。
The T (Respond Only If TTL Expired) flag MUST be set only in the echo request packet by the sender. If the T flag is set to 1 in an incoming echo request, 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. 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. The T flag is defined in Section 3.4 of [RFC6425].
发送方必须仅在回显请求数据包中设置T（仅在TTL过期时响应）标志。如果传入回显请求中的T标志设置为1，并且传入MPLS标签的TTL大于1，则接收节点必须丢弃传入回显请求，并且不得向发送方发送任何回显回复。不得在回送回复数据包中设置此标志。如果在回显回复数据包中设置了此标志，则必须忽略它。[RFC6425]第3.4节定义了T标志。
The R (Validate Reverse Path) flag is defined in [RFC6426]. When this flag is set in the echo request, the Responder SHOULD return reverse-path FEC information, as described in Section 3.4.2 of [RFC6426].
[RFC6426]中定义了R（验证反向路径）标志。当回声请求中设置此标志时，响应者应返回反向路径FEC信息，如[RFC6426]第3.4.2节所述。
The Message Type is one of the following:
消息类型为以下类型之一：
Value Meaning
----- -------
1 MPLS Echo Request
2 MPLS Echo Reply
Value Meaning
----- -------
1 MPLS Echo Request
2 MPLS Echo Reply
The Reply Mode can take one of the following values:
回复模式可以采用以下值之一：
Value Meaning
----- -------
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application-level control channel
Value Meaning
----- -------
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application-level control channel
An MPLS echo request with 1 (Do not reply) in the Reply Mode field may be used for one-way connectivity tests; the receiving router may log gaps in the Sequence Numbers and/or maintain delay/jitter statistics. An MPLS echo request would normally have 2 (Reply via an IPv4/IPv6 UDP packet) in the Reply Mode field. If the normal IP return path is deemed unreliable, one may use 3 (Reply via an IPv4/ IPv6 UDP packet with Router Alert). Note that this requires that all intermediate routers understand and know how to forward MPLS echo replies. The echo reply uses the same IP version number as the received echo request, i.e., an IPv4 encapsulated echo reply is sent in response to an IPv4 encapsulated echo request.
回复模式字段中有1（不回复）的MPLS回送请求可用于单向连接测试；接收路由器可以记录序列号中的间隔和/或保持延迟/抖动统计。MPLS回送请求的回复模式字段中通常有2个（通过IPv4/IPv6 UDP数据包进行回复）。如果认为正常的IP返回路径不可靠，可以使用3（通过带有路由器警报的IPv4/IPv6 UDP数据包进行回复）。注意，这要求所有中间路由器理解并知道如何转发MPLS回送回复。回送回复使用与接收到的回送请求相同的IP版本号，即，发送IPv4封装的回送回复以响应IPv4封装的回送请求。
Some applications support an IP control channel. One such example is the associated control channel defined in Virtual Circuit Connectivity Verification (VCCV) [RFC5085][RFC5885]. Any application that supports an IP control channel between its control entities may set the Reply Mode to 4 (Reply via application-level control channel) to ensure that replies use that same channel. Further definition of this code point is application specific and thus beyond the scope of this document.
一些应用程序支持IP控制通道。其中一个示例是在虚拟电路连接验证（VCCV）[RFC5085][RFC5885]中定义的相关控制信道。任何支持其控制实体之间的IP控制通道的应用程序都可以将应答模式设置为4（通过应用程序级控制通道进行应答），以确保应答使用相同的通道。此代码点的进一步定义是特定于应用程序的，因此超出了本文档的范围。
Return Codes and Subcodes are described in Section 3.1.
第3.1节描述了返回代码和子代码。
The Sender's Handle is filled in by the sender and returned unchanged by the receiver in the echo reply (if any). There are no semantics associated with this handle, although a sender may find this useful for matching up requests with replies.
发送方的句柄由发送方填写，接收方在回显回复（如果有）中原封不动地返回。没有与此句柄相关的语义，尽管发送者可能会发现这对于匹配请求和回复很有用。
The Sequence Number is assigned by the sender of the MPLS echo request and can be (for example) used to detect missed replies.
序列号由MPLS回送请求的发送方分配，并可（例如）用于检测错过的回复。
The TimeStamp Sent is the time of day (according to the sender's clock) in 64-bit NTP timestamp format [RFC5905] when the MPLS echo request is sent. The TimeStamp Received in an echo reply is the time of day (according to the receiver's clock) in 64-bit NTP timestamp format in which the corresponding echo request was received.
发送的时间戳是发送MPLS回显请求时采用64位NTP时间戳格式[RFC5905]的时间（根据发送方的时钟）。回送回复中接收的时间戳是接收到相应回送请求的64位NTP时间戳格式的时间（根据接收器的时钟）。
TLVs (Type-Length-Value tuples) have the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Types are defined below; Length is the length of the Value field in octets. The Value field depends on the Type; it is zero padded to align to a 4-octet boundary. TLVs may be nested within other TLVs, in which case the nested TLVs are called sub-TLVs. Sub-TLVs have independent types and MUST also be 4-octet aligned.
类型定义如下；Length是值字段的长度（以八位字节为单位）。值字段取决于类型；它是零填充的，以与4个八位组的边界对齐。TLV可以嵌套在其他TLV中，在这种情况下，嵌套的TLV称为子TLV。子TLV具有独立类型，并且还必须是4-八位组对齐。
Two examples of how TLV and sub-TLV lengths are computed, and how sub-TLVs are padded to be 4-octet aligned, are as follows:
关于如何计算TLV和sub TLV长度，以及如何将sub TLV填充为4八位组对齐的两个示例如下：
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 = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this TLV is 5. A Target FEC Stack TLV that contains an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has the following format:
该TLV的长度为5。包含LDP IPv4 FEC子TLV和VPN IPv4前缀子TLV的目标FEC堆栈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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (FEC TLV) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 1 (FEC TLV) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of the Types and Values of the top-level TLVs for LSP ping are given below:
LSP ping的顶级TLV的类型和值说明如下：
Type # Value Field
------ -----------
1 Target FEC Stack
2 Downstream Mapping (Deprecated)
3 Pad
4 Unassigned
5 Vendor Enterprise Number
6 Unassigned
7 Interface and Label Stack
8 Unassigned
9 Errored TLVs
10 Reply TOS Byte
20 Downstream Detailed Mapping
Type # Value Field
------ -----------
1 Target FEC Stack
2 Downstream Mapping (Deprecated)
3 Pad
4 Unassigned
5 Vendor Enterprise Number
6 Unassigned
7 Interface and Label Stack
8 Unassigned
9 Errored TLVs
10 Reply TOS Byte
20 Downstream Detailed Mapping
Types less than 32768 (i.e., with the high-order bit equal to 0) are mandatory TLVs that MUST either be supported by an implementation or result in the Return Code of 2 ("One or more of the TLVs was not understood") being sent in the echo response.
小于32768的类型（即，高阶位等于0）是必须的TLV，必须由实现支持，或导致在回声响应中发送返回码2（“一个或多个TLV未被理解”）。
Types greater than or equal to 32768 (i.e., with the high-order bit equal to 1) are optional TLVs that SHOULD be ignored if the implementation does not understand or support them.
大于或等于32768的类型（即，高阶位等于1）是可选的TLV，如果实现不理解或不支持它们，则应忽略它们。
In Sections 3.2 through 3.9 and their various subsections, only the Value field of the TLV is included.
在第3.2节至第3.9节及其各小节中，仅包括TLV的值字段。
The Return Code is set to zero by the sender of an echo request. The receiver of said echo request can set it to one of the values listed below in the corresponding echo reply that it generates. The notation <RSC> refers to the Return Subcode. This field is filled in with the stack-depth for those codes that specify that. For all other codes, the Return Subcode MUST be set to zero.
回显请求的发送方将返回代码设置为零。所述回显请求的接收者可以将其设置为其生成的相应回显回复中下面列出的值之一。符号<RSC>表示返回子代码。此字段由指定该值的代码的堆栈深度填充。对于所有其他代码，返回子代码必须设置为零。
Value Meaning
----- -------
0 No Return Code
1 Malformed echo request received
2 One or more of the TLVs was not understood
3 Replying router is an egress for the FEC at
stack-depth <RSC>
4 Replying router has no mapping for the FEC at
stack-depth <RSC>
5 Downstream Mapping Mismatch (See Note 1)
6 Upstream Interface Index Unknown (See Note 1)
7 Reserved
8 Label switched at stack-depth <RSC>
9 Label switched but no MPLS forwarding at stack-depth <RSC>
10 Mapping for this FEC is not the given label at
stack-depth <RSC>
11 No label entry at stack-depth <RSC>
12 Protocol not associated with interface at FEC
stack-depth <RSC>
13 Premature termination of ping due to label stack
shrinking to a single label
14 See DDMAP TLV for meaning of Return Code and Return
Subcode (See Note 2)
15 Label switched with FEC change
Value Meaning
----- -------
0 No Return Code
1 Malformed echo request received
2 One or more of the TLVs was not understood
3 Replying router is an egress for the FEC at
stack-depth <RSC>
4 Replying router has no mapping for the FEC at
stack-depth <RSC>
5 Downstream Mapping Mismatch (See Note 1)
6 Upstream Interface Index Unknown (See Note 1)
7 Reserved
8 Label switched at stack-depth <RSC>
9 Label switched but no MPLS forwarding at stack-depth <RSC>
10 Mapping for this FEC is not the given label at
stack-depth <RSC>
11 No label entry at stack-depth <RSC>
12 Protocol not associated with interface at FEC
stack-depth <RSC>
13 Premature termination of ping due to label stack
shrinking to a single label
14 See DDMAP TLV for meaning of Return Code and Return
Subcode (See Note 2)
15 Label switched with FEC change
Note 1
附注1
The Return Subcode (RSC) contains the point in the label stack where processing was terminated. If the RSC is 0, no labels were processed. Otherwise, the packet was label switched at depth RSC.
返回子代码（RSC）包含标签堆栈中终止处理的点。如果RSC为0，则未处理任何标签。否则，分组在深度RSC处进行标签交换。
Note 2
附注2
The Return Code is per "Downstream Detailed Mapping TLV" (Section 3.4). This Return Code MUST be used only in the message header and MUST be set only in the MPLS echo reply message. If the Return Code is set in the MPLS echo request message, then it MUST be ignored. When this Return Code is set, each Downstream Detailed Mapping TLV MUST have an appropriate Return Code and Return Subcode. This Return Code MUST be used when there are multiple downstreams for a given node (such as Point-to-Multipoint (P2MP) or ECMP), and the node needs to return a Return Code/Return Subcode for each downstream. This Return Code MAY be used even when there is only one downstream for a given node.
返回代码符合“下游详细映射TLV”（第3.4节）。此返回码只能在消息头中使用，并且只能在MPLS回送回复消息中设置。如果在MPLS回显请求消息中设置了返回码，则必须忽略它。设置此返回代码时，每个下游详细映射TLV必须具有适当的返回代码和返回子代码。当给定节点（如点对多点（P2MP）或ECMP）存在多个下游时，必须使用此返回码，并且节点需要为每个下游返回一个返回码/返回子码。即使给定节点只有一个下游，也可以使用此返回码。
A Target FEC Stack is a list of sub-TLVs. The number of elements is determined by looking at the sub-TLV length fields.
目标FEC堆栈是子TLV的列表。元素的数量通过查看子TLV长度字段来确定。
Sub-Type Length Value Field
-------- ------ -----------
1 5 LDP IPv4 prefix
2 17 LDP IPv6 prefix
3 20 RSVP IPv4 LSP
4 56 RSVP IPv6 LSP
5 Unassigned
6 13 VPN IPv4 prefix
7 25 VPN IPv6 prefix
8 14 L2 VPN endpoint
9 10 "FEC 128" Pseudowire - IPv4 (deprecated)
10 14 "FEC 128" Pseudowire - IPv4
11 16+ "FEC 129" Pseudowire - IPv4
12 5 BGP labeled IPv4 prefix
13 17 BGP labeled IPv6 prefix
14 5 Generic IPv4 prefix
15 17 Generic IPv6 prefix
16 4 Nil FEC
24 38 "FEC 128" Pseudowire - IPv6
25 40+ "FEC 129" Pseudowire - IPv6
Sub-Type Length Value Field
-------- ------ -----------
1 5 LDP IPv4 prefix
2 17 LDP IPv6 prefix
3 20 RSVP IPv4 LSP
4 56 RSVP IPv6 LSP
5 Unassigned
6 13 VPN IPv4 prefix
7 25 VPN IPv6 prefix
8 14 L2 VPN endpoint
9 10 "FEC 128" Pseudowire - IPv4 (deprecated)
10 14 "FEC 128" Pseudowire - IPv4
11 16+ "FEC 129" Pseudowire - IPv4
12 5 BGP labeled IPv4 prefix
13 17 BGP labeled IPv6 prefix
14 5 Generic IPv4 prefix
15 17 Generic IPv6 prefix
16 4 Nil FEC
24 38 "FEC 128" Pseudowire - IPv6
25 40+ "FEC 129" Pseudowire - IPv6
Other FEC types have been defined and will be defined as needed.
已定义并将根据需要定义其他FEC类型。
Note that this TLV defines a stack of FECs, the first FEC element corresponding to the top of the label stack, etc.
注意，这个TLV定义了一个FEC堆栈，第一个FEC元素对应于标签堆栈的顶部，等等。
An MPLS echo request MUST have a Target FEC Stack that describes the FEC Stack being tested. For example, if an LSR X has an LDP mapping [RFC5036] for 192.0.2.1 (say, label 1001), then to verify that label 1001 does indeed reach an egress LSR that announced this prefix via LDP, X can send an MPLS echo request with a FEC Stack TLV with one FEC in it, namely, of type LDP IPv4 prefix, with prefix 192.0.2.1/32, and send the echo request with a label of 1001.
MPLS回送请求必须有一个描述正在测试的FEC堆栈的目标FEC堆栈。例如，如果LSR X具有用于192.0.2.1（例如，标签1001）的LDP映射[RFC5036]，则为了验证标签1001确实到达通过LDP宣布该前缀的出口LSR，X可以发送带有FEC堆栈TLV的MPLS回显请求，其中包含一个FEC，即LDP IPv4前缀类型，前缀为192.0.2.1/32，并发送标签为1001的回显请求。
Say LSR X wanted to verify that a label stack of <1001, 23456> is the right label stack to use to reach a VPN IPv4 prefix (see Section 3.2.5) of 203.0.113.0/24 in VPN foo. Say further that LSR Y with loopback address 192.0.2.1 announced prefix 203.0.113.0/24 with Route Distinguisher (RD) RD-foo-Y (which may in general be different from the RD that LSR X uses in its own advertisements for VPN foo), label 23456, and BGP next hop 192.0.2.1 [RFC4271]. Finally, suppose that LSR X receives a label binding of 1001 for 192.0.2.1 via LDP. X has two choices in sending an MPLS echo request: X can send an MPLS echo request with a FEC Stack TLV with a single FEC of type VPN IPv4 prefix with a prefix of 203.0.113.0/24 and an RD of RD-foo-Y. Alternatively, X can send a FEC Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 192.0.2.1/32 and the second of type of IP VPN with a prefix 203.0.113.0/24 with an RD of RD-foo-Y. In either case, the MPLS echo request would have a label stack of <1001, 23456>. (Note: in this example, 1001 is the "outer" label and 23456 is the "inner" label.)
Say LSR X wanted to verify that a label stack of <1001, 23456> is the right label stack to use to reach a VPN IPv4 prefix (see Section 3.2.5) of 203.0.113.0/24 in VPN foo. Say further that LSR Y with loopback address 192.0.2.1 announced prefix 203.0.113.0/24 with Route Distinguisher (RD) RD-foo-Y (which may in general be different from the RD that LSR X uses in its own advertisements for VPN foo), label 23456, and BGP next hop 192.0.2.1 [RFC4271]. Finally, suppose that LSR X receives a label binding of 1001 for 192.0.2.1 via LDP. X has two choices in sending an MPLS echo request: X can send an MPLS echo request with a FEC Stack TLV with a single FEC of type VPN IPv4 prefix with a prefix of 203.0.113.0/24 and an RD of RD-foo-Y. Alternatively, X can send a FEC Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 192.0.2.1/32 and the second of type of IP VPN with a prefix 203.0.113.0/24 with an RD of RD-foo-Y. In either case, the MPLS echo request would have a label stack of <1001, 23456>. (Note: in this example, 1001 is the "outer" label and 23456 is the "inner" label.)translate error, please retry
If, for example, an LSR Y has an LDP mapping for the IPv6 address 2001:db8::1 (say, label 2001), then to verify that label 2001 does reach an egress LSR that announced this prefix via LDP, LSR Y can send an MPLS echo request with a FEC Stack TLV with one LDP IPv6 prefix FEC, with prefix 2001:db8::1/128, and with a label of 2001.
例如，如果LSR Y具有IPv6地址2001:db8:：1（例如，标签2001）的LDP映射，则为了验证标签2001确实到达通过LDP宣布该前缀的出口LSR，LSR Y可以发送带有FEC堆栈TLV的MPLS回显请求，该FEC堆栈TLV具有一个LDP IPv6前缀FEC，前缀2001:db8:：1/128，标签为2001。
If an end-to-end path comprises of one or more tunneled or stitched LSPs, each transit node that is the originating point of a new tunnel or segment SHOULD reply back notifying the FEC stack change along with the new FEC details, for example, if LSR X has an LDP mapping for IPv4 prefix 192.0.2.10 on LSR Z (say, label 3001). Say further that LSR A and LSR B are transit nodes along the path, which also have an RSVP tunnel over which LDP is enabled. While replying back, A SHOULD notify that the FEC changes from LDP to <RSVP, LDP>. If the new tunnel is a transparent pipe, i.e., the data-plane trace will not expire in the middle of the tunnel, then the transit node SHOULD NOT reply back notifying the FEC stack change or the new FEC details. If the transit node wishes to hide the nature of the tunnel from the ingress of the echo request, then the transit node MAY notify the FEC stack change and include Nil FEC as the new FEC.
如果端到端路径包括一个或多个隧道或缝合的LSP，则作为新隧道或段的起始点的每个传输节点应回复通知FEC堆栈更改以及新FEC详细信息，例如，如果LSR X在LSR Z上具有IPv4前缀192.0.2.10的LDP映射（例如，标签3001）。进一步说，LSR A和LSR B是路径上的传输节点，它们也有一个RSVP隧道，在该隧道上启用LDP。回复时，A应通知FEC从LDP更改为<RSVP，LDP>。如果新隧道是透明管道，即数据平面迹线不会在隧道中间过期，则过境节点不应回复通知FEC堆栈变化或新FEC细节。如果传输节点希望对回波请求的进入隐藏隧道的性质，则传输节点可以通知FEC堆栈更改，并包括Nil FEC作为新FEC。
The IPv4 Prefix FEC is defined in [RFC5036]. When an LDP IPv4 prefix is encoded in a label stack, the following format is used. The value consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv4 prefix is in network byte order; if the prefix is shorter than 32 bits, trailing bits SHOULD be set to zero. See [RFC5036] for an example of a Mapping for an IPv4 FEC.
IPv4前缀FEC在[RFC5036]中定义。在标签堆栈中对LDP IPv4前缀进行编码时，将使用以下格式。该值由IPv4前缀的4个八位字节和前缀长度的1个八位字节（以位为单位）组成；格式如下所示。IPv4前缀按网络字节顺序排列；如果前缀短于32位，则尾随位应设置为零。有关IPv4 FEC的映射示例，请参见[RFC5036]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Prefix FEC is defined in [RFC5036]. When an LDP IPv6 prefix is encoded in a label stack, the following format is used. The value consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv6 prefix is in network byte order; if the prefix is shorter than 128 bits, the trailing bits SHOULD be set to zero. See [RFC5036] for an example of a Mapping for an IPv6 FEC.
IPv6前缀FEC在[RFC5036]中定义。在标签堆栈中对LDP IPv6前缀进行编码时，将使用以下格式。该值由IPv6前缀的16个八位字节和前缀长度的1个八位字节（以位为单位）组成；格式如下所示。IPv6前缀按网络字节顺序排列；如果前缀短于128位，则尾随位应设置为零。有关IPv6 FEC的映射示例，请参见[RFC5036]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value has the format below. The Value fields are taken from RFC 3209 [RFC3209], Sections 4.6.1.1 and 4.6.2.1.
该值的格式如下所示。值字段取自RFC 3209[RFC3209]，第4.6.1.1节和第4.6.2.1节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value has the format below. The Value fields are taken from RFC 3209 [RFC3209], Sections 4.6.1.2 and 4.6.2.2.
该值的格式如下所示。值字段取自RFC 3209[RFC3209]，第4.6.1.2节和第4.6.2.2节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Endpoint Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Tunnel Sender Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPN-IPv4 Network Layer Routing Information (NLRI) is defined in [RFC4365]. This document uses the term VPN IPv4 prefix for a VPN-IPv4 NLRI that has been advertised with an MPLS label in BGP. See [RFC3107].
VPN-IPv4网络层路由信息（NLRI）在[RFC4365]中定义。本文档使用术语VPN IPv4前缀表示已在BGP中以MPLS标签发布的VPN-IPv4 NLRI。见[RFC3107]。
When a VPN IPv4 prefix is encoded in a label stack, the following format is used. The Value field consists of the RD advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 bits to make 32 bits in all), and a prefix length, as follows:
在标签堆栈中对VPN IPv4前缀进行编码时，将使用以下格式。值字段包括使用VPN IPv4前缀播发的RD、IPv4前缀（尾随0位表示总共32位）和前缀长度，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RD is an 8-octet identifier; it does not contain any inherent information. The purpose of the RD is solely to allow one to create distinct routes to a common IPv4 address prefix. The encoding of the RD is not important here. When matching this field to the local FEC information, it is treated as an opaque value.
RD是8个八位字节的标识符；它不包含任何固有信息。RD的目的仅仅是允许创建到公共IPv4地址前缀的不同路由。RD的编码在这里并不重要。将此字段与本地FEC信息匹配时，将其视为不透明值。
VPN-IPv6 NLRI is defined in [RFC4365]. This document uses the term VPN IPv6 prefix for a VPN-IPv6 NLRI that has been advertised with an MPLS label in BGP. See [RFC3107].
[RFC4365]中定义了VPN-IPv6 NLRI。本文档使用术语VPN IPv6前缀表示已在BGP中以MPLS标签发布的VPN-IPv6 NLRI。见[RFC3107]。
When a VPN IPv6 prefix is encoded in a label stack, the following format is used. The Value field consists of the RD advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 bits to make 128 bits in all), and a prefix length, as follows:
在标签堆栈中对VPN IPv6前缀进行编码时，将使用以下格式。值字段包括使用VPN IPv6前缀播发的RD、IPv6前缀（尾随0位表示总共128位）和前缀长度，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RD is identical to the VPN IPv4 Prefix RD, except that it functions here to allow the creation of distinct routes to IPv6 prefixes. See Section 3.2.5. When matching this field to local FEC information, it is treated as an opaque value.
RD与VPN IPv4前缀RD相同，只是它在此处的功能是允许创建到IPv6前缀的不同路由。见第3.2.5节。将此字段与本地FEC信息匹配时，它被视为不透明值。
VPLS stands for Virtual Private LAN Service. The terms VPLS BGP NLRI and VPLS Edge Identifier (VE ID) are defined in [RFC4761]. This document uses the simpler term L2 VPN endpoint when referring to a VPLS BGP NLRI. The RD is an 8-octet identifier used to distinguish information about various L2 VPNs advertised by a node. The VE ID is a 2-octet identifier used to identify a particular node that serves as the service attachment point within a VPLS. The structure of these two identifiers is unimportant here; when matching these fields to local FEC information, they are treated as opaque values. The encapsulation type is identical to the Pseudowire (PW) Type in Section 3.2.9.
VPLS代表虚拟专用LAN服务。术语VPLS BGP NLRI和VPLS边缘标识符（VE ID）在[RFC4761]中定义。本文档在提及VPLS BGP NLRI时使用了更简单的术语L2 VPN端点。RD是一个8个八位字节的标识符，用于区分节点播发的各种L2 VPN的信息。VE ID是一个2-octet标识符，用于标识作为VPLS内服务连接点的特定节点。这两个标识符的结构在这里并不重要；将这些字段与本地FEC信息匹配时，它们被视为不透明值。封装类型与第3.2.9节中的伪线（PW）类型相同。
When an L2 VPN endpoint is encoded in a label stack, the following format is used. The Value field consists of an RD (8 octets), the sender's (of the ping) VE ID (2 octets), the receiver's VE ID (2 octets), and an encapsulation type (2 octets), formatted as follows:
在标签堆栈中对L2 VPN端点进行编码时，将使用以下格式。值字段由RD（8个八位字节）、发送方（ping的）VE ID（2个八位字节）、接收方VE ID（2个八位字节）和封装类型（2个八位字节）组成，格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See Appendix A.1.1 for details.
详见附录A.1.1。
FEC 128 (0x80) is defined in [RFC8077], as are the terms PW ID (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 32-bit connection ID. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below termed "encapsulation type" with the high-order bit set to zero.
[RFC8077]中定义了FEC 128（0x80），术语PW ID（伪线ID）和PW类型（伪线类型）也是如此。PW ID是一个非零的32位连接ID。PW类型是一个指示封装类型的15位数字。它在下面名为“封装类型”的字段中右对齐，高阶位设置为零。
Both of these fields are treated in this protocol as opaque values. When matching these fields to the local FEC information, the match MUST be exact.
在本协议中，这两个字段都被视为不透明值。将这些字段与本地FEC信息匹配时，匹配必须精确。
When a FEC 128 is encoded in a label stack, the following format is used. The Value field consists of the Sender's Provider Edge (PE) IPv4 Address (the source address of the targeted LDP session), the Remote PE IPv4 Address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows:
当FEC 128在标签堆栈中编码时，使用以下格式。值字段由发送方的提供者边缘（PE）IPv4地址（目标LDP会话的源地址）、远程PE IPv4地址（目标LDP会话的目标地址）、PW 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier (AGI), Attachment Group Identifier Type (AGI Type), Attachment Individual Identifier Type (AII Type), Source Attachment Individual Identifier (SAII), and Target Attachment Individual Identifier (TAII) are defined in [RFC8077]. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below PW Type with the high-order bit set to zero. All the other fields are treated as opaque values and copied directly from the FEC 129 format. All of these values together uniquely define the FEC within the scope of the LDP session identified by the source and remote PE IPv4 addresses.
FEC 129（0x81）和术语PW类型、附件组标识符（AGI）、附件组标识符类型（AGI类型）、附件个体标识符类型（AII类型）、源附件个体标识符（SAII）和目标附件个体标识符（TAII）在[RFC8077]中定义。PW类型是一个15位的数字，指示封装类型。它在PW Type下面的字段中右对齐，高阶位设置为零。所有其他字段被视为不透明值，并直接从FEC 129格式复制。所有这些值一起唯一地定义由源和远程PE IPv4地址标识的LDP会话范围内的FEC。
When a FEC 129 is encoded in a label stack, the following format is used. The Length of this TLV is 16 + AGI length + SAII length + TAII length. Padding is used to make the total length a multiple of 4; the length of the padding is not included in the Length field.
当在标签堆栈中编码FEC 129时，使用以下格式。该TLV的长度为16+AGI长度+SAII长度+TAII长度。填充用于使总长度为4的倍数；长度字段中不包括填充的长度。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FEC 128 Pseudowire IPv6 sub-TLV has a structure consistent with the FEC 128 Pseudowire IPv4 sub-TLV as described in Section 3.2.9. The Value field consists of the Sender's PE IPv6 Address (the source address of the targeted LDP session), the Remote PE IPv6 Address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows:
如第3.2.9节所述，FEC 128伪线IPv6子TLV的结构与FEC 128伪线IPv4子TLV一致。值字段由发送方的PE IPv6地址（目标LDP会话的源地址）、远程PE IPv6地址（目标LDP会话的目标地址）、PW 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sender's PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Remote PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sender's PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Remote PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender's PE IPv6 Address: The source IP address of the target IPv6 LDP session. 16 octets.
发送方的PE IPv6地址：目标IPv6 LDP会话的源IP地址。16个八位组。
Remote PE IPv6 Address: The destination IP address of the target IPv6 LDP session. 16 octets.
远程PE IPv6地址：目标IPv6 LDP会话的目标IP地址。16个八位组。
PW ID: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9.
PW ID：与第3.2.9节中的FEC 128伪线IPv4相同。
PW Type: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9.
PW类型：与第3.2.9节中的FEC 128伪线IPv4相同。
The FEC 129 Pseudowire IPv6 sub-TLV has a structure consistent with the FEC 129 Pseudowire IPv4 sub-TLV as described in Section 3.2.10. When a FEC 129 is encoded in a label stack, the following format is used. The length of this TLV is 40 + AGI (Attachment Group Identifier) length + SAII (Source Attachment Individual Identifier) length + TAII (Target Attachment Individual Identifier) length. Padding is used to make the total length a multiple of 4; the length of the padding is not included in the Length field.
如第3.2.10节所述，FEC 129伪线IPv6子TLV的结构与FEC 129伪线IPv4子TLV一致。当在标签堆栈中编码FEC 129时，使用以下格式。该TLV的长度为40+AGI（附件组标识符）长度+SAII（源附件个人标识符）长度+TAII（目标附件个人标识符）长度。填充用于使总长度为4的倍数；长度字段中不包括填充的长度。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sender's PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Remote PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sender's PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Remote PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender's PE IPv6 Address: The source IP address of the target IPv6 LDP session. 16 octets.
发送方的PE IPv6地址：目标IPv6 LDP会话的源IP地址。16个八位组。
Remote PE IPv6 Address: The destination IP address of the target IPv6 LDP session. 16 octets.
远程PE IPv6地址：目标IPv6 LDP会话的目标IP地址。16个八位组。
The other fields are the same as FEC 129 Pseudowire IPv4 in Section 3.2.10.
其他字段与第3.2.10节中的FEC 129伪线IPv4相同。
BGP labeled IPv4 prefixes are defined in [RFC3107]. When a BGP labeled IPv4 prefix is encoded in a label stack, the following format is used. The Value field consists of the IPv4 prefix (with trailing 0 bits to make 32 bits in all) and the prefix length, as follows:
BGP标记的IPv4前缀在[RFC3107]中定义。在标签堆栈中对标记为IPv4前缀的BGP进行编码时，将使用以下格式。值字段由IPv4前缀（尾随0位表示总共32位）和前缀长度组成，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BGP labeled IPv6 prefixes are defined in [RFC3107]. When a BGP labeled IPv6 prefix is encoded in a label stack, the following format is used. The value consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv6 prefix is in network byte order; if the prefix is shorter than 128 bits, the trailing bits SHOULD be set to zero.
BGP标记的IPv6前缀在[RFC3107]中定义。在标签堆栈中对标记为IPv6前缀的BGP进行编码时，将使用以下格式。该值由IPv6前缀的16个八位字节和前缀长度的1个八位字节（以位为单位）组成；格式如下所示。IPv6前缀按网络字节顺序排列；如果前缀短于128位，则尾随位应设置为零。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv4 prefix is in network byte order; if the prefix is shorter than 32 bits, the trailing bits SHOULD be set to zero. This FEC is used if the protocol advertising the label is unknown or may change during the course of the LSP. An example is an inter-AS LSP that may be signaled by LDP in one Autonomous System (AS), by RSVP-TE [RFC3209] in another AS, and by BGP between the ASes, such as is common for inter-AS VPNs.
该值由IPv4前缀的4个八位字节和前缀长度的1个八位字节（以位为单位）组成；格式如下所示。IPv4前缀按网络字节顺序排列；如果前缀短于32位，则尾随位应设置为零。如果公布标签的协议未知或在LSP过程中可能发生变化，则使用该FEC。一个示例是可以由一个自治系统（AS）中的LDP、另一个AS中的RSVP-TE[RFC3209]以及AS之间的BGP发信号的AS间LSP，例如对于AS间vpn是常见的。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix length in bits; the format is given below. The IPv6 prefix is in network byte order; if the prefix is shorter than 128 bits, the trailing bits SHOULD be set to zero.
该值由IPv6前缀的16个八位字节和前缀长度的1个八位字节（以位为单位）组成；格式如下所示。IPv6前缀按网络字节顺序排列；如果前缀短于128位，则尾随位应设置为零。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
At times, labels from the reserved range, e.g., Router Alert and Explicit-null, may be added to the label stack for various diagnostic purposes such as influencing load-balancing. These labels may have no explicit FEC associated with them. The Nil FEC Stack is defined to allow a Target FEC Stack sub-TLV to be added to the Target FEC Stack to account for such labels so that proper validation can still be performed.
有时，保留范围内的标签（例如路由器警报和显式null）可能会添加到标签堆栈中，用于各种诊断目的，例如影响负载平衡。这些标签可能没有与之关联的显式FEC。Nil FEC堆栈被定义为允许将目标FEC堆栈子TLV添加到目标FEC堆栈，以说明此类标签，以便仍然可以执行适当的验证。
The Length is 4. Labels are 20-bit values treated as numbers.
长度是4。标签是作为数字处理的20位值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label is the actual label value inserted in the label stack; the MBZ fields MUST be zero when sent and ignored on receipt.
Label是插入到标签堆栈中的实际标签值；MBZ字段在发送时必须为零，在接收时被忽略。
See Appendix A.2 for more details.
详见附录A.2。
The Downstream Detailed Mapping object is a TLV that MAY be included in an MPLS echo request message. Only one Downstream Detailed Mapping object may appear in an echo request. The presence of a Downstream Detailed Mapping object is a request that Downstream Detailed Mapping objects be included in the MPLS echo reply. If the replying router is the destination (Label Edge Router) of the FEC, then a Downstream Detailed Mapping TLV SHOULD NOT be included in the MPLS echo reply. Otherwise, the replying router SHOULD include a Downstream Detailed Mapping object for each interface over which this FEC could be forwarded. For a more precise definition of the notion of "downstream", see Section 3.4.2, "Downstream Router and Interface".
下游详细映射对象是可能包括在MPLS回送请求消息中的TLV。回送请求中只能出现一个下游详细映射对象。下游详细映射对象的存在是在MPLS回送应答中包括下游详细映射对象的请求。如果应答路由器是FEC的目的地（标签边缘路由器），则MPLS回送应答中不应包括下游详细映射TLV。否则，应答路由器应包括每个接口的下游详细映射对象，该FEC可通过该接口转发。有关“下游”概念的更精确定义，请参见第3.4.2节“下游路由器和接口”。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Downstream Detailed Mapping TLV format is derived from the deprecated Downstream Mapping TLV format (see Appendix A.2.) The key change is that variable length and optional fields have been converted into sub-TLVs.
下游详细映射TLV格式源自不推荐的下游映射TLV格式（见附录A.2）。关键变化是可变长度和可选字段已转换为子TLV。
Maximum Transmission Unit (MTU)
最大传输单位（MTU）
The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the interface to the downstream LSR.
MTU是适合下游LSR接口的最大MPLS帧（包括标签堆栈）的大小（以八位字节为单位）。
Address Type
地址类型
The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the Downstream IP Address and Downstream Interface fields. The Address Type is set to one of the following values:
地址类型指示接口是否已编号。它还确定下游IP地址和下游接口字段的长度。地址类型设置为以下值之一：
Type # Address Type
------ ------------
1 IPv4 Numbered
2 IPv4 Unnumbered
3 IPv6 Numbered
4 IPv6 Unnumbered
Type # Address Type
------ ------------
1 IPv4 Numbered
2 IPv4 Unnumbered
3 IPv6 Numbered
4 IPv6 Unnumbered
DS Flags
DS标志
The DS Flags field is a bit vector of various flags with the following format:
DS Flags字段是具有以下格式的各种标志的位向量：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
Two flags are defined currently, I and N. The remaining flags MUST be set to zero when sending and ignored on receipt.
当前定义了两个标志：I和N。发送时必须将其余标志设置为零，并在接收时忽略。
Flag Name and Meaning
---- ----------------
I Interface and Label Stack Object Request
Flag Name and Meaning
---- ----------------
I Interface and Label Stack Object Request
When this flag is set, it indicates that the replying router SHOULD include an Interface and Label Stack Object in the echo reply message.
设置此标志时，表示应答路由器应在回送应答消息中包含接口和标签堆栈对象。
N Treat as a Non-IP Packet
N将其视为非IP数据包
Echo request messages will be used to diagnose non-IP flows. However, these messages are carried in IP packets. For a router that alters its ECMP algorithm based on the FEC or deep packet examination, this flag requests that the router treat this as it would if the determination of an IP payload had failed.
回显请求消息将用于诊断非IP流。但是，这些消息是在IP数据包中传输的。对于根据FEC或深度数据包检查改变其ECMP算法的路由器，该标志请求路由器将其视为IP有效负载确定失败时的处理方式。
Downstream Address and Downstream Interface Address
下游地址和下游接口地址
IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets.
IPv4地址和接口索引以4个八位字节编码；IPv6地址编码为16个八位字节。
If the interface to the downstream LSR is numbered, then the Address Type MUST be set to IPv4 or IPv6, the Downstream Address MUST be set to either the downstream LSR's Router ID or the interface address of the downstream LSR, and the Downstream Interface Address MUST be set to the downstream LSR's interface address.
如果下游LSR的接口已编号，则地址类型必须设置为IPv4或IPv6，下游地址必须设置为下游LSR的路由器ID或下游LSR的接口地址，并且下游接口地址必须设置为下游LSR的接口地址。
If the interface to the downstream LSR is unnumbered, the Address Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream Address MUST be the downstream LSR's Router ID, and the Downstream Interface Address MUST be set to the index assigned by the upstream LSR to the interface.
如果与下游LSR的接口未编号，则地址类型必须为IPv4未编号或IPv6未编号，下游地址必须是下游LSR的路由器ID，并且下游接口地址必须设置为上游LSR分配给接口的索引。
If an LSR does not know the IP address of its neighbor, then it MUST set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it must set the Downstream Address to 127.0.0.1; for IPv6, the address is set to 0::1. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with either of these addresses in the Downstream Address field, this indicates that it MUST bypass interface verification but continue with label validation.
如果LSR不知道其邻居的IP地址，则必须将地址类型设置为IPv4未编号或IPv6未编号。对于IPv4，必须将下行地址设置为127.0.0.1；对于IPv6，地址设置为0:：1。在这两种情况下，接口索引都必须设置为0。如果LSR在下游地址字段中接收到带有这些地址之一的回显请求数据包，这表明它必须绕过接口验证，但继续标签验证。
If the originator of an echo request packet wishes to obtain Downstream Detailed Mapping information but does not know the expected label stack, then it SHOULD set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the Downstream Address to 224.0.0.2; for IPv6, the address MUST be set to FF02::2. In both cases, the interface index MUST be set to 0. If an LSR receives an echo request packet with the all-routers multicast address, then this indicates that it MUST bypass both interface and label stack validation but return Downstream Mapping TLVs using the information provided.
如果echo请求数据包的发起人希望获得下游详细映射信息，但不知道预期的标签堆栈，则应将地址类型设置为IPv4未编号或IPv6未编号。对于IPv4，必须将下行地址设置为224.0.0.2；对于IPv6，地址必须设置为FF02:：2。在这两种情况下，接口索引都必须设置为0。若LSR接收到一个带有所有路由器多播地址的echo请求包，那个么这表明它必须绕过接口和标签堆栈验证，但使用提供的信息返回下游映射TLV。
Return Code
返回码
The Return Code is set to zero by the sender of an echo request. The receiver of said echo request can set it in the corresponding echo reply that it generates to one of the values specified in Section 3.1 other than 14.
回显请求的发送方将返回代码设置为零。所述回送请求的接收者可在其生成的相应回送回复中将其设置为第3.1节规定的值之一，而非第14节。
If the receiver sets a non-zero value of the Return Code field in the Downstream Detailed Mapping TLV, then the receiver MUST also set the Return Code field in the echo reply header to "See DDMAP TLV for Return Code and Return Subcode" (Section 3.1). An exception to this is if the receiver is a bud node [RFC4461] and is replying as both an egress and a transit node with a Return Code of 3 ("Replying router is an egress for the FEC at stack-depth <RSC>") in the echo reply header.
如果接收机在下游详细映射TLV中设置了非零值的返回码字段，则接收机还必须将回波应答报头中的返回码字段设置为“返回码和返回子码见DDMAP TLV”（第3.1节）。例外情况是，如果接收器是bud节点[RFC4461]，并且在回音应答报头中以出口和传输节点的身份应答，返回代码为3（“应答路由器是堆栈深度处FEC的出口<RSC>）。
If the Return Code of the echo reply message is not set to either "See DDMAP TLV for Return Code and Return Subcode" (Section 3.1) or "Replying router is an egress for the FEC at stack-depth <RSC>", then the Return Code specified in the Downstream Detailed Mapping TLV MUST be ignored.
如果回送回复消息的返回码未设置为“请参阅DDMAP TLV以了解返回码和返回子码”（第3.1节）或“回复路由器是堆栈深度<RSC>处FEC的出口”，则必须忽略下游详细映射TLV中指定的返回码。
Return Subcode
返回子码
The Return Subcode is set to zero by the sender. The receiver can set this field to an appropriate value as specified in Section 3.1: The Return Subcode is filled in with the stack-depth for those codes that specify the stack-depth. For all other codes, the Return Subcode MUST be set to zero.
发送方将返回子代码设置为零。接收器可以将该字段设置为第3.1节中指定的适当值：返回子代码中填充指定堆栈深度的代码的堆栈深度。对于所有其他代码，返回子代码必须设置为零。
If the Return Code of the echo reply message is not set to either "See DDMAP TLV for Return Code and Return Subcode" (Section 3.1) or "Replying router is an egress for the FEC at stack-depth <RSC>", then the Return Subcode specified in the Downstream Detailed Mapping TLV MUST be ignored.
如果回送回复消息的返回码未设置为“请参阅DDMAP TLV了解返回码和返回子码”（第3.1节）或“回复路由器是堆栈深度<RSC>处FEC的出口”，则必须忽略下游详细映射TLV中指定的返回子码。
Sub-TLV Length
子TLV长度
Total length in octets of the sub-TLVs associated with this TLV.
与此TLV关联的子TLV的总长度（以八位字节为单位）。
This section defines the sub-TLVs that MAY be included as part of the Downstream Detailed Mapping TLV.
本节定义了子TLV，该子TLV可作为下游详细映射TLV的一部分。
Sub-Type Value Field
--------- ------------
1 Multipath data
2 Label stack
3 FEC stack change
Sub-Type Value Field
--------- ------------
1 Multipath data
2 Label stack
3 FEC stack change
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multipath Type | Multipath Length |Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (Multipath Information) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multipath Type | Multipath Length |Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (Multipath Information) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The multipath data sub-TLV includes Multipath Information.
多路径数据子TLV包括多路径信息。
Multipath Type
多路径类型
The type of the encoding for the Multipath Information.
多路径信息的编码类型。
The following Multipath Types are defined in this document:
本文档中定义了以下多路径类型：
Key Type Multipath Information
--- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0)
2 IP address IP addresses
4 IP address range low/high address pairs
8 Bit-masked IP IP address prefix and bit mask
address set
9 Bit-masked label set Label prefix and bit mask
Key Type Multipath Information
--- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0)
2 IP address IP addresses
4 IP address range low/high address pairs
8 Bit-masked IP IP address prefix and bit mask
address set
9 Bit-masked label set Label prefix and bit mask
Type 0 indicates that all packets will be forwarded out this one interface.
类型0表示所有数据包都将转发到此接口。
Types 2, 4, 8, and 9 specify that the supplied Multipath Information will serve to exercise this path.
类型2、4、8和9指定提供的多路径信息将用于执行此路径。
Multipath Length
多径长度
The length in octets of the Multipath Information.
多路径信息的长度（以八位字节为单位）。
MBZ
MBZ
MUST be set to zero when sending; MUST be ignored on receipt.
发送时必须设置为零；必须在收到时忽略。
Multipath Information
多路径信息
Encoded multipath data (e.g., encoded address or label values), according to the Multipath Type. See Section 3.4.1.1.1 for encoding details.
根据多路径类型编码的多路径数据（例如，编码地址或标签值）。编码详情见第3.4.1.1.1节。
The Multipath Information encodes labels or addresses that will exercise this path. The Multipath Information depends on the Multipath Type. The contents of the field are shown in the table above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses are drawn from the range 0:0:0:0:0:FFFF:7F00:0/104. Labels are treated as numbers, i.e., they are right justified in the field. For Type 4, ranges indicated by address pairs MUST NOT overlap and MUST be in ascending sequence.
多路径信息对将执行此路径的标签或地址进行编码。多路径信息取决于多路径类型。该字段的内容如上表所示。IPv4地址取自127/8范围；IPv6地址从范围0:0:0:0:0:FFFF:7F00:0/104中提取。标签被视为数字，即它们在字段中右对齐。对于类型4，地址对指示的范围不得重叠，且必须以升序排列。
Type 8 allows a more dense encoding of IP addresses. The IP prefix is formatted as a base IP address with the non-prefix low-order bits set to zero. The maximum prefix length is 27. Following the prefix is a mask of length 2^(32 - prefix length) bits for IPv4 and 2^(128 - prefix length) bits for IPv6. Each bit set to 1 represents a valid address. The address is the base IPv4 address plus the position of the bit in the mask where the bits are numbered left to right beginning with zero. For example, the IPv4 addresses 127.2.1.0, 127.2.1.5-127.2.1.15, and 127.2.1.20-127.2.1.29 would be encoded as follows:
类型8允许对IP地址进行更密集的编码。IP前缀被格式化为基本IP地址，非前缀低位设置为零。最大前缀长度为27。前缀后面是IPv4的长度为2^（32-前缀长度）位的掩码，IPv6的长度为2^（128-前缀长度）位的掩码。设置为1的每个位表示一个有效地址。地址是基本IPv4地址加上位在掩码中的位置，其中位从左到右从零开始编号。例如，IPv4地址127.2.1.0、127.2.1.5-127.2.1.15和127.2.1.20-127.2.1.29的编码如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Those same addresses embedded in IPv6 would be encoded as follows:
嵌入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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 9 allows a more dense encoding of labels. The label prefix is formatted as a base label value with the non-prefix low-order bits set to zero. The maximum prefix (including leading zeros due to encoding) length is 27. Following the prefix is a mask of length 2^(32 - prefix length) bits. Each bit set to one represents a valid label. The label is the base label plus the position of the bit in the mask where the bits are numbered left to right beginning with zero. Label values of all the odd numbers between 1152 and 1279 would be encoded as follows:
类型9允许对标签进行更密集的编码。标签前缀被格式化为基本标签值，非前缀低位设置为零。最大前缀（包括编码导致的前导零）长度为27。前缀后面是长度为2^（32-前缀长度）位的掩码。设置为1的每个位表示一个有效标签。标签是基本标签加上位在掩码中的位置，位从左到右从零开始编号。1152和1279之间的所有奇数的标签值编码如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the received Multipath Information is non-null, the labels and IP addresses MUST be picked from the set provided. If none of these labels or addresses map to a particular downstream interface, then for that interface, the type MUST be set to 0. If the received Multipath Information is null (i.e., Multipath Length = 0, or for Types 8 and 9, a mask of all zeros), the type MUST be set to 0.
如果收到的多路径信息为非空，则必须从提供的集合中选取标签和IP地址。如果这些标签或地址都没有映射到特定的下游接口，那么对于该接口，类型必须设置为0。如果接收到的多路径信息为空（即，多路径长度=0，或者对于类型8和9，掩码为全零），则必须将类型设置为0。
For example, suppose LSR X at hop 10 has two downstream LSRs, Y and Z, for the FEC in question. The received X could return Multipath Type 4, with low/high IP addresses of 127.1.1.1->127.1.1.255 for downstream LSR Y and 127.2.1.1->127.2.1.255 for downstream LSR Z. The head end reflects this information to LSR Y. Y, which has three downstream LSRs, U, V, and W, computes that 127.1.1.1->127.1.1.127 would go to U and 127.1.1.128-> 127.1.1.255 would go to V. Y would then respond with 3 Downstream Detailed Mapping TLVs: to U, with Multipath Type 4 (127.1.1.1->127.1.1.127); to V, with Multipath Type 4 (127.1.1.127->127.1.1.255); and to W, with Multipath Type 0.
例如，假设跃点10处的LSR X对于所讨论的FEC具有两个下游LSR，Y和Z。接收到的X可能返回多路径类型4，下游LSR Y的低/高IP地址为127.1.1->127.1.1.255，下游LSR Z的低/高IP地址为127.2.1.1->127.2.1.255。前端将此信息反映给LSR Y.Y，它有三个下游LSR，U、V和W，计算127.1.1.1->127.1.1.127将转到U和127.1.1.128->127.1.1.255将转到V。Y随后将使用3个下游详细映射TLV:到U，多路径类型4（127.1.1.1->127.1.1.127）；到V，多路径类型为4（127.1.1.127->127.1.1.255）；和到W，多路径类型为0。
Note that computing Multipath Information may impose a significant processing burden on the receiver. A receiver MAY thus choose to process a subset of the received prefixes. The sender, on receiving a reply to a Downstream Detailed Mapping with partial information, SHOULD assume that the prefixes missing in the reply were skipped by the receiver and MAY re-request information about them in a new echo request.
注意，计算多路径信息可能对接收机施加重大的处理负担。因此，接收机可以选择处理所接收前缀的子集。发送方在收到带有部分信息的下游详细映射的答复时，应假定答复中缺少的前缀已被接收方跳过，并可在新的回显请求中重新请求有关这些前缀的信息。
The encoding of Multipath Information in scenarios where a few LSRs apply Entropy-label-based load-balancing while other LSRs are non-EL (IP-based) load balanced will be defined in a different document.
在一些LSR采用基于熵标签的负载平衡，而其他LSR采用非EL（基于IP）负载平衡的情况下，多路径信息的编码将在不同的文档中定义。
The encoding of Multipath Information in scenarios where LSRs have Layer 2 ECMP over Link Aggregation Group (LAG) interfaces will be defined in a different document.
LSR具有第2层ECMP over Link Aggregation Group（LAG）接口的场景中的多路径信息编码将在不同的文档中定义。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label Stack sub-TLV contains the set of labels in the label stack as it would have appeared if this router were forwarding the packet through this interface. Any Implicit Null labels are explicitly included. The number of label/protocol pairs present in the sub-TLV is determined based on the sub-TLV data length. When the Downstream Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be included.
标签堆栈子TLV包含标签堆栈中的标签集，如果此路由器通过此接口转发数据包，则会出现标签集。任何隐式空标签都会显式包含。子TLV中存在的标签/协议对的数量根据子TLV数据长度确定。在回送回复中发送下游详细映射TLV时，必须包括该子TLV。
Downstream Label
下游标签
A downstream label is 24 bits, in the same format as an MPLS label minus the TTL field, i.e., the MSBit of the label is bit 0, the LSBit is bit 19, the TC field [RFC5462] is bits 20-22, and S is bit 23. The replying router SHOULD fill in the TC field and S bit; the LSR receiving the echo reply MAY choose to ignore these.
下游标签为24位，格式与MPLS标签减去TTL字段相同，即标签的MSBit为位0，LSBit为位19，TC字段[RFC5462]为位20-22，S为位23。应答路由器应填写TC字段和S位；接收回音应答的LSR可以选择忽略这些。
Protocol
协议
This specifies the label distribution protocol for the Downstream label. Protocol values are taken from the following table:
这指定下游标签的标签分发协议。协议值取自下表：
Protocol # Signaling Protocol
---------- ------------------
0 Unknown
1 Static
2 BGP
3 LDP
4 RSVP-TE
Protocol # Signaling Protocol
---------- ------------------
0 Unknown
1 Static
2 BGP
3 LDP
4 RSVP-TE
A router MUST include the FEC stack change sub-TLV when the downstream node in the echo reply has a different FEC Stack than the FEC Stack received in the echo request. One or more FEC stack change sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The format is as below.
当echo应答中的下游节点具有与echo请求中接收的FEC堆栈不同的FEC堆栈时，路由器必须包括FEC堆栈更改子TLV。一个或多个FEC堆栈改变子TLV可存在于下游详细映射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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address Type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. FEC 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address Type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4, or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. FEC TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Operation Type
操作类型
The operation type specifies the action associated with the FEC stack change. The following operation types are defined:
操作类型指定与FEC堆栈更改关联的操作。定义了以下操作类型：
Type # Operation
------ ---------
1 Push
2 Pop
Type # Operation
------ ---------
1 Push
2 Pop
Address Type
地址类型
The Address Type indicates the remote peer's address type. The Address Type is set to one of the following values. The length of the peer address is determined based on the address type. The address type MAY be different from the address type included in the Downstream Detailed Mapping TLV. This can happen when the LSP goes over a tunnel of a different address family. The address type MAY be set to Unspecified if the peer address is either unavailable or the transit router does not wish to provide it for security or administrative reasons.
地址类型指示远程对等方的地址类型。地址类型设置为以下值之一。对等地址的长度根据地址类型确定。地址类型可能不同于下游详细映射TLV中包含的地址类型。当LSP通过不同地址族的隧道时，可能会发生这种情况。如果对等地址不可用或传输路由器出于安全或管理原因不希望提供，则可以将地址类型设置为“未指定”。
Type # Address Type Address length
------ ------------ --------------
0 Unspecified 0
1 IPv4 4
2 IPv6 16
Type # Address Type Address length
------ ------------ --------------
0 Unspecified 0
1 IPv4 4
2 IPv6 16
FEC TLV Length
TLV长度
Length in octets of the FEC TLV.
FEC TLV的长度（以八位字节为单位）。
Reserved
含蓄的
This field is reserved for future use and MUST be set to zero.
此字段保留供将来使用，必须设置为零。
Remote Peer Address
远程对等地址
The remote peer address specifies the remote peer that is the next hop for the FEC being currently traced. If the operation type is PUSH, the remote peer address is the address of the peer from which the FEC being pushed was learned. If the operation type is pop, the remote peer address MAY be set to Unspecified.
远程对等地址指定当前跟踪的FEC的下一跳的远程对等。如果操作类型为推送，则远程对等地址是从中学习被推送的FEC的对等地址。如果操作类型为pop，则远程对等地址可能设置为未指定。
For upstream-assigned labels [RFC5331], an operation type of pop will have a remote peer address (the upstream node that assigned the label), and this SHOULD be included in the FEC stack change
对于上游分配的标签[RFC5331]，pop的操作类型将具有远程对等地址（分配标签的上游节点），这应包括在FEC堆栈更改中
sub-TLV. The remote peer address MAY be set to Unspecified if the address needs to be hidden.
次级TLV。如果需要隐藏远程对等地址，则可以将该地址设置为“未指定”。
FEC TLV
FEC-TLV
The FEC TLV is present only when the FEC-tlv length field is non-zero. The FEC TLV specifies the FEC associated with the FEC stack change operation. This TLV MAY be included when the operation type is pop. It MUST be included when the operation type is PUSH. The FEC TLV contains exactly one FEC from the list of FECs specified in Section 3.2. A Nil FEC MAY be associated with a PUSH operation if the responding router wishes to hide the details of the FEC being pushed.
仅当FEC TLV长度字段为非零时，FEC TLV才存在。FEC TLV指定与FEC堆栈更改操作关联的FEC。当操作类型为pop时，可包括该TLV。当操作类型为“推送”时，必须包含该选项。FEC TLV仅包含第3.2节规定的FEC列表中的一个FEC。如果响应路由器希望隐藏被推送的FEC的细节，则Nil FEC可与推送操作相关联。
FEC stack change sub-TLV operation rules are as follows:
FEC堆栈更改子TLV操作规则如下：
a. A FEC stack change sub-TLV containing a PUSH operation MUST NOT be followed by a FEC stack change sub-TLV containing a pop operation.
a. 包含推送操作的FEC堆栈更改子TLV后面不得紧跟包含pop操作的FEC堆栈更改子TLV。
b. One or more pop operations MAY be followed by one or more PUSH operations.
b. 一个或多个pop操作之后可能会有一个或多个推送操作。
c. One FEC stack change sub-TLV MUST be included per FEC stack change. For example, if 2 labels are going to be pushed, then one FEC stack change sub-TLV MUST be included for each FEC.
c. 每次FEC堆栈更改必须包括一个FEC堆栈更改子TLV。例如，如果要推送2个标签，则必须为每个FEC包含一个FEC堆栈更改子TLV。
d. A FEC splice operation (an operation where one FEC ends and another FEC starts, MUST be performed by including a pop type FEC stack change sub-TLV followed by a PUSH type FEC stack change sub-TLV.
d. FEC拼接操作（一个FEC结束而另一个FEC开始的操作）必须通过包括pop型FEC堆栈更改子TLV，然后是PUSH型FEC堆栈更改子TLV来执行。
e. A Downstream Detailed Mapping TLV containing only one FEC stack change sub-TLV with pop operation is equivalent to IS_EGRESS (Return Code 3, Section 3.1) for the outermost FEC in the FEC stack. The ingress router performing the LSP traceroute MUST treat such a case as an IS_EGRESS for the outermost FEC.
e. 仅包含一个具有pop操作的FEC堆栈更改子TLV的下游详细映射TLV相当于FEC堆栈中最外层FEC的is_出口（返回代码3，第3.1节）。执行LSP跟踪路由的入口路由器必须将这种情况视为最外层FEC的IS_出口。
The notion of "downstream router" and "downstream interface" should be explained. Consider an LSR X. If a packet that was originated with TTL n>1 arrived with outermost label L and TTL=1 at LSR X, X must be able to compute which LSRs could receive the packet if it was originated with TTL=n+1, over which interface the request would arrive and what label stack those LSRs would see. (It is outside the scope of this document to specify how this computation is done.) The set of these LSRs/interfaces consists of the downstream routers/
应该解释“下游路由器”和“下游接口”的概念。考虑一个LSR X。如果一个源于TTL n＞1的包在LSR x上到达最外层标签L和TTL＝1，则X必须能够计算哪些LSR可以接收到包，如果它是源于TTL= N+ 1，在哪个接口上请求将到达，哪些LSR会看到LSR。（指定如何进行计算超出了本文件的范围。）这些LSR/接口集由下游路由器组成/
interfaces (and their corresponding labels) for X with respect to L. Each pair of downstream router and interface requires a separate Downstream Detailed Mapping to be added to the reply.
X相对于L的接口（及其相应标签）。每对下游路由器和接口都需要在应答中添加单独的下游详细映射。
The case where X is the LSR originating the echo request is a special case. X needs to figure out what LSRs would receive the MPLS echo request for a given FEC Stack that X originates with TTL=1.
X是发起echo请求的LSR的情况是一种特殊情况。X需要确定哪些LSR将接收给定FEC堆栈的MPLS回显请求，该FEC堆栈由TTL=1发起。
The set of downstream routers at X may be alternative paths (see the discussion below on ECMP) or simultaneous paths (e.g., for MPLS multicast). In the former case, the Multipath Information is used as a hint to the sender as to how it may influence the choice of these alternatives.
X处的下游路由器集可以是替代路径（参见下面关于ECMP的讨论）或同时路径（例如，对于MPLS多播）。在前一种情况下，多路径信息被用作提示发送方它可能如何影响这些备选方案的选择。
The value part of the Pad TLV contains a variable number (>= 1) of octets. The first octet takes values from the following table; all the other octets (if any) are ignored. The receiver SHOULD verify that the TLV is received in its entirety, but otherwise ignores the contents of this TLV, apart from the first octet.
Pad TLV的值部分包含可变数量（>=1）的八位字节。第一个八位组取下表中的值；忽略所有其他八位字节（如果有）。接收器应验证TLV是否完整接收，但除第一个八位组外，应忽略该TLV的内容。
Value Meaning
----- -------
0 Reserved
1 Drop Pad TLV from reply
2 Copy Pad TLV to reply
3-250 Unassigned
251-254 Reserved for Experimental Use
255 Reserved
Value Meaning
----- -------
0 Reserved
1 Drop Pad TLV from reply
2 Copy Pad TLV to reply
3-250 Unassigned
251-254 Reserved for Experimental Use
255 Reserved
The Pad TLV can be added to an echo request to create a message of a specific length in cases where messages of various sizes are needed for troubleshooting. The first octet allows for controlling the inclusion of this additional padding in the respective echo reply.
在需要各种大小的消息进行故障排除的情况下，可以将Pad TLV添加到回显请求中，以创建特定长度的消息。第一个八位组允许控制在相应的回音应答中包含此附加填充。
"Private Enterprise Numbers" [IANA-ENT] are maintained by IANA. The Length of this TLV is always 4; the value is the Structure of Management Information (SMI) Private Enterprise Code, in network octet order, of the vendor with a Vendor Private extension to any of the fields in the fixed part of the message, in which case this TLV MUST be present. If none of the fields in the fixed part of the message have Vendor Private extensions, inclusion of this TLV is OPTIONAL. Vendor Private ranges for Message Types, Reply Modes, and Return Codes have been defined. When any of these are used, the Vendor Enterprise Number TLV MUST be included in the message.
“私营企业编号”[IANA-ENT]由IANA维护。该TLV的长度始终为4；该值是供应商的管理信息（SMI）私有企业代码的结构，以网络八位字节顺序排列，并具有消息固定部分中任何字段的供应商私有扩展，在这种情况下，必须存在此TLV。如果消息的固定部分中没有任何字段具有供应商专用扩展名，则包含此TLV是可选的。已定义消息类型、回复模式和返回代码的供应商专用范围。当使用其中任何一项时，消息中必须包含供应商企业编号TLV。
The Interface and Label Stack TLV MAY be included in a reply message to report the interface on which the request message was received and the label stack that was on the packet when it was received. Only one such object may appear. The purpose of the object is to allow the upstream router to obtain the exact interface and label stack information as it appears at the replying LSR.
接口和标签栈TLV可以包括在应答消息中，以报告接收请求消息的接口以及接收请求消息时在分组上的标签栈。只能出现一个这样的对象。该对象的目的是允许上游路由器获得应答LSR上显示的确切接口和标签堆栈信息。
The Length is K + 4*N octets; N is the number of labels in the label stack. Values for K are found in the description of Address Type below. The Value field of this TLV has the following format:
长度为K+4*N个八位组；N是标签堆栈中的标签数。在下面的地址类型描述中可以找到K的值。此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 | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Label Stack .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Label Stack .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type
地址类型
The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the IP Address and Interface fields. The resulting total for the initial part of the TLV is listed in the table below as "K Octets". The Address Type is set to one of the following values:
地址类型指示接口是否已编号。它还确定IP地址和接口字段的长度。下表中列出了TLV初始部分的总结果，即“K八位字节”。地址类型设置为以下值之一：
Type # Address Type K Octets
------ ------------ --------
0 Reserved 4
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
5-250 Unassigned
251-254 Reserved for Experimental Use
255 Reserved
Type # Address Type K Octets
------ ------------ --------
0 Reserved 4
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
5-250 Unassigned
251-254 Reserved for Experimental Use
255 Reserved
IP Address and Interface
IP地址和接口
IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets.
IPv4地址和接口索引以4个八位字节编码；IPv6地址编码为16个八位字节。
If the interface upon which the echo request message was received is numbered, then the Address Type MUST be set to IPv4 or IPv6, the IP Address MUST be set to either the LSR's Router ID or the interface address, and the Interface MUST be set to the interface address.
如果接收回显请求消息的接口已编号，则地址类型必须设置为IPv4或IPv6，IP地址必须设置为LSR的路由器ID或接口地址，并且接口必须设置为接口地址。
If the interface is unnumbered, the Address Type MUST be either IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the LSR's Router ID, and the Interface MUST be set to the index assigned to the interface.
如果接口未编号，则地址类型必须是IPv4未编号或IPv6未编号，IP地址必须是LSR的路由器ID，并且接口必须设置为分配给接口的索引。
Label Stack
标签栈
The label stack of the received echo request message. If any TTL values have been changed by this router, they SHOULD be restored.
接收到的回显请求消息的标签堆栈。如果此路由器更改了任何TTL值，则应恢复这些值。
The following TLV is a TLV that MAY be included in an echo reply to inform the sender of an echo request of mandatory TLVs either not supported by an implementation or parsed and found to be in error.
以下TLV是一种TLV，可包含在回送回复中，用于通知发送方强制TLV的回送请求，该强制TLV要么不受实现支持，要么已解析并发现存在错误。
The Value field contains the TLVs that were not understood, encoded as sub-TLVs.
值字段包含未理解的TLV，编码为子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV MAY be used by the originator of the echo request to request that an echo reply be sent with the IP header Type of Service (TOS) octet set to the value specified in the TLV. This TLV has a length of 4 with the following Value field.
回送请求的发起人可使用该TLV请求发送回送回复，并将IP报头服务类型（TOS）八位组设置为TLV中指定的值。此TLV的长度为4，值字段如下。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An MPLS echo request is used to test a particular LSP. The LSP to be tested is identified by the "FEC Stack"; for example, if the LSP was set up via LDP, and a label is mapped to an egress IP address of 198.51.100.1, the FEC Stack contains a single element, namely, an LDP IPv4 prefix sub-TLV with value 198.51.100.1/32. If the LSP being tested is an RSVP LSP, the FEC Stack consists of a single element that captures the RSVP Session and Sender Template that uniquely identifies the LSP.
MPLS回显请求用于测试特定LSP。要测试的LSP由“FEC堆栈”标识；例如，如果LSP是通过LDP设置的，并且标签映射到出口IP地址198.51.100.1，则FEC堆栈包含单个元素，即值为198.51.100.1/32的LDP IPv4前缀子TLV。如果正在测试的LSP是RSVP LSP，则FEC堆栈由捕获RSVP会话的单个元素和唯一标识LSP的发送方模板组成。
FEC Stacks can be more complex. For example, one may wish to test a VPN IPv4 prefix of 203.0.113.0/24 that is tunneled over an LDP LSP with egress 192.0.2.1. The FEC Stack would then contain two sub-TLVs, the bottom being a VPN IPv4 prefix, and the top being an LDP IPv4 prefix. If the underlying (LDP) tunnel were not known, or was considered irrelevant, the FEC Stack could be a single element with just the VPN IPv4 sub-TLV.
FEC堆栈可能更复杂。例如，您可能希望测试203.0.113.0/24的VPN IPv4前缀，该前缀通过出口192.0.2.1的LDP LSP进行隧道传输。然后，FEC堆栈将包含两个子TLV，底部是VPN IPv4前缀，顶部是LDP IPv4前缀。如果底层（LDP）隧道未知，或被认为不相关，则FEC堆栈可以是仅具有VPN IPv4子TLV的单个元素。
When an MPLS echo request is received, the receiver is expected to verify that the control plane and data plane are both healthy (for the FEC Stack being pinged), and that the two planes are in sync. The procedures for this are in Section 4.4.
当接收到MPLS回波请求时，接收机应验证控制平面和数据平面是否都正常（对于正在ping的FEC堆栈），以及这两个平面是否同步。相关程序见第4.4节。
LSPs need not be simple point-to-point tunnels. Frequently, a single LSP may originate at several ingresses and terminate at several egresses; this is very common with LDP LSPs. LSPs for a given FEC may also have multiple "next hops" at transit LSRs. At an ingress, there may also be several different LSPs to choose from to get to the desired endpoint. Finally, LSPs may have backup paths, detour paths, and other alternative paths to take should the primary LSP go down.
LSP不需要是简单的点对点隧道。通常，单个LSP可能起源于多个入口，终止于多个出口；这在LDP LSP中非常常见。给定FEC的lsp也可以在传输lsr处具有多个“下一跳”。在入口，也可能有几个不同的LSP可供选择，以到达所需的端点。最后，如果主LSP发生故障，LSP可能会有备份路径、迂回路径和其他可选路径。
Regarding the last two points stated above: it is assumed that the LSR sourcing MPLS echo requests can force the echo request into any desired LSP, so choosing among multiple LSPs at the ingress is not an issue. The problem of probing the various flavors of backup paths that will typically not be used for forwarding data unless the primary LSP is down will not be addressed here.
关于上面提到的最后两点：假设LSR源MPLS echo请求可以强制echo请求进入任何期望的LSP，因此在入口的多个LSP中选择不是问题。这里不讨论在主LSP关闭之前通常不用于转发数据的各种备份路径的探测问题。
Since the actual LSP and path that a given packet may take may not be known a priori, it is useful if MPLS echo requests can exercise all possible paths. This, although desirable, may not be practical because the algorithms that a given LSR uses to distribute packets over alternative paths may be proprietary.
由于给定数据包可能采用的实际LSP和路径可能是未知的，因此如果MPLS回送请求可以使用所有可能的路径，这是有用的。这虽然是可取的，但可能不实用，因为给定LSR用于在备选路径上分发数据包的算法可能是专有的。
To achieve some degree of coverage of alternate paths, there is a certain latitude in choosing the destination IP address and source UDP port for an MPLS echo request. This is clearly not sufficient; in the case of traceroute, more latitude is offered by means of the Multipath Information of the Downstream Detailed Mapping TLV. This is used as follows. An ingress LSR periodically sends an LSP traceroute message to determine whether there are multipaths for a given LSP. If so, each hop will provide some information as to how each of its downstream paths can be exercised. The ingress can then send MPLS echo requests that exercise these paths. If several transit LSRs have ECMP, the ingress may attempt to compose these to exercise all possible paths. However, full coverage may not be possible.
为了实现备用路径的某种程度的覆盖，在为MPLS回送请求选择目标IP地址和源UDP端口时有一定的自由度。这显然是不够的；在跟踪路由的情况下，通过下游详细映射TLV的多路径信息提供更多的纬度。其用途如下。入口LSR定期发送LSP跟踪路由消息，以确定给定LSP是否存在多路径。如果是这样，每个跃点将提供一些关于如何使用其每个下游路径的信息。然后，入口可以发送执行这些路径的MPLS回显请求。如果多个运输LSR具有ECMP，入口可能会尝试组合这些以使用所有可能的路径。然而，全面覆盖可能是不可能的。
To detect certain LSP breakages, it may be necessary to encapsulate an MPLS echo request packet with at least one additional label when testing LSPs that are used to carry MPLS payloads (such as LSPs used to carry L2VPN and L3VPN traffic. For example, when testing LDP or RSVP-TE LSPs, just sending an MPLS echo request packet may not detect instances where the router immediately upstream of the destination of the LSP ping may forward the MPLS echo request successfully over an interface not configured to carry MPLS payloads because of the use of penultimate hop popping. Since the receiving router has no means to ascertain whether the IP packet was sent unlabeled or implicitly labeled, the addition of labels shimmed above the MPLS echo request (using the Nil FEC) will prevent a router from forwarding such a packet out to unlabeled interfaces.
为了检测某些LSP中断，在测试用于承载MPLS有效负载的LSP时，可能需要用至少一个附加标签封装MPLS回送请求包（例如，用于承载L2VPN和L3VPN流量的LSP。例如，在测试LDP或RSVP-TE LSP时，仅发送MPLS回送请求数据包可能无法检测到LSP ping目的地上游的路由器可通过未配置为承载MPLS有效负载的接口成功转发MPLS回送请求的情况，因为使用倒数第二跳弹出。由于接收路由器无法确定IP数据包是未标记发送的还是隐式标记发送的，因此在MPLS回送请求上方添加加垫片的标签（使用Nil FEC）将阻止路由器将此类数据包转发到未标记的接口。
An MPLS echo request is a UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or an IPv6 address from the range 0:0:0:0:0:FFFF:7F00:0/104. The IP TTL is set to 1. The source UDP port is chosen by the sender; the destination UDP port is set to 3503 (assigned by IANA for MPLS echo requests). The Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or value 69 [RFC7506] for IPv6 MUST be set in the IP header.
MPLS回显请求是UDP数据包。IP报头设置如下：源IP地址是发送方的可路由地址；目标IP地址是127/8范围内的（随机选择的）IPv4地址或0:0:0:0:FFFF:7F00:0/104范围内的IPv6地址。IP TTL设置为1。源UDP端口由发送方选择；目标UDP端口设置为3503（由IANA为MPLS回显请求分配）。必须在IP标头中设置IPv4的值0x0[RFC2113]或IPv6的值69[RFC7506]的路由器警报IP选项。
An MPLS echo request is sent with a label stack corresponding to the FEC Stack being tested. Note that further labels could be applied if, for example, the normal route to the topmost FEC in the stack is via a Traffic Engineered Tunnel [RFC3209]. If all of the FECs in the stack correspond to Implicit Null labels, the MPLS echo request is considered unlabeled even if further labels will be applied in sending the packet.
发送MPLS回送请求时，标签堆栈与正在测试的FEC堆栈相对应。请注意，如果（例如）到堆栈中最顶部FEC的正常路线是通过交通工程隧道[RFC3209]，则可以应用进一步的标签。如果堆栈中的所有FEC对应于隐式空标签，则MPLS回送请求被视为未标记，即使在发送数据包时将应用更多标签。
If the echo request is labeled, one MAY (depending on what is being pinged) set the TTL of the innermost label to 1, to prevent the ping request going farther than it should. Examples of where this SHOULD be done include pinging a VPN IPv4 or IPv6 prefix, an L2 VPN endpoint, or a pseudowire. Preventing the ping request from going too far can also be accomplished by inserting a Router Alert label above this label; however, this may lead to the undesired side effect that MPLS echo requests take a different data path than actual data. For more information on how these mechanisms can be used for pseudowire connectivity verification, see [RFC5085][RFC5885].
如果回显请求已标记，则可以（取决于正在ping的内容）将最内层标签的TTL设置为1，以防止ping请求超出其应有的范围。应执行此操作的示例包括ping VPN IPv4或IPv6前缀、L2 VPN端点或伪线。防止ping请求走得太远也可以通过在该标签上方插入路由器警报标签来实现；然而，这可能导致不希望的副作用，即MPLS回送请求采用与实际数据不同的数据路径。有关如何将这些机制用于伪线连接验证的更多信息，请参阅[RFC5085][RFC5885]。
In "ping" mode (end-to-end connectivity check), the TTL in the outermost label is set to 255. In "traceroute" mode (fault isolation mode), the TTL is set successively to 1, 2, and so on.
在“ping”模式（端到端连接检查）下，最外层标签中的TTL设置为255。在“跟踪路由”模式（故障隔离模式）下，TTL依次设置为1、2等。
The sender chooses a Sender's Handle and a Sequence Number. When sending subsequent MPLS echo requests, the sender SHOULD increment the Sequence Number by 1. However, a sender MAY choose to send a group of echo requests with the same Sequence Number to improve the chance of arrival of at least one packet with that Sequence Number.
发送方选择发送方的句柄和序列号。发送后续MPLS回显请求时，发送方应将序列号增加1。然而，发送方可以选择发送具有相同序列号的一组echo请求，以提高具有该序列号的至少一个分组到达的机会。
The TimeStamp Sent is set to the time of day in NTP format that the echo request is sent. The TimeStamp Received is set to zero.
发送的时间戳设置为发送回显请求的NTP格式的时间。接收的时间戳设置为零。
An MPLS echo request MUST have a FEC Stack TLV. Also, the Reply Mode must be set to the desired Reply Mode; the Return Code and Subcode are set to zero. In the "traceroute" mode, the echo request SHOULD include a Downstream Detailed Mapping TLV.
MPLS回显请求必须具有FEC堆栈TLV。此外，应答模式必须设置为所需的应答模式；返回代码和子代码设置为零。在“跟踪路由”模式下，回波请求应包括下游详细映射TLV。
Sending an MPLS echo request to the control plane is triggered by one of the following packet processing exceptions: Router Alert option, IP TTL expiration, MPLS TTL expiration, MPLS Router Alert label, or the destination address in the 127/8 address range. The control plane further identifies it by UDP destination port 3503.
向控制平面发送MPLS回显请求由以下数据包处理异常之一触发：路由器警报选项、IP TTL过期、MPLS TTL过期、MPLS路由器警报标签或127/8地址范围内的目标地址。控制平面通过UDP目标端口3503进一步识别它。
For reporting purposes, the bottom of the stack is considered to be a stack-depth of 1. This is to establish an absolute reference for the case where the actual stack may have more labels than there are FECs in the Target FEC Stack.
出于报告目的，堆栈底部被视为堆栈深度为1。这是为了在实际堆栈中的标签可能比目标FEC堆栈中的FEC多的情况下建立绝对参考。
Furthermore, in all the Return Codes listed in this document, a stack-depth of 0 means "no value specified". This allows compatibility with existing implementations that do not use the Return Subcode field.
此外，在本文档中列出的所有返回代码中，堆栈深度为0表示“未指定值”。这允许与不使用返回子代码字段的现有实现兼容。
An LSR X that receives an MPLS echo request then processes it as follows.
接收MPLS回送请求的LSR X然后按如下方式处理该请求。
1. General packet sanity is verified. 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 Subcode set to zero. If there are any TLVs not marked as "Ignore" (i.e., if the TLV type is less than 32768, see Section 3) that LSR X does not understand, LSR X SHOULD send an MPLS "TLV not understood" (as appropriate), and set the Subcode to zero. In the latter case, the misunderstood TLVs (only) are included as sub-TLVs in an Errored TLVs TLV in the reply. The header field's Sender's Handle, Sequence Number, and Timestamp Sent are not examined but are included in the MPLS echo reply message.
1. 验证了数据包的一般健全性。如果数据包格式不正确，LSR X应发送MPLS回显回复，返回码设置为“收到格式错误的回显请求”，子码设置为零。如果LSR X不理解任何未标记为“忽略”（即，如果TLV类型小于32768，请参见第3节）的TLV，则LSR X应发送MPLS“TLV未理解”（视情况而定），并将子代码设置为零。在后一种情况下，被误解的TLV（仅）作为子TLV包含在回复中的错误TLV TLV中。未检查发送的报头字段的发送方句柄、序列号和时间戳，但它们包含在MPLS回送回复消息中。
The algorithm uses the following variables and identifiers:
该算法使用以下变量和标识符：
Interface-I: the interface on which the MPLS echo request was received.
Interface-I：接收MPLS回显请求的接口。
Stack-R: the label stack on the packet as it was received.
Stack-R：数据包接收时的标签堆栈。
Stack-D: the label stack carried in the "Label stack sub-TLV" in the Downstream Detailed Mapping TLV (not always present).
Stack-D：下游详细映射TLV中“标签堆栈子TLV”中携带的标签堆栈（不总是存在）。
Label-L: the label from the actual stack currently being examined. Requires no initialization.
Label-L：当前正在检查的实际堆栈中的标签。不需要初始化。
Label-stack-depth: the depth of the label being verified. Initialized to the number of labels in the received label stack S.
标签堆栈深度：正在验证的标签的深度。初始化为接收到的标签堆栈中的标签数。
FEC-stack-depth: depth of the FEC in the Target FEC Stack that should be used to verify the current actual label. Requires no initialization.
FEC堆栈深度：应用于验证当前实际标签的目标FEC堆栈中FEC的深度。不需要初始化。
Best-return-code: contains the Return Code for the echo reply packet as currently best known. As the algorithm progresses, this code may change depending on the results of further checks that it performs.
最佳返回码：包含当前已知的回显回复数据包的返回码。随着算法的发展，此代码可能会根据其执行的进一步检查的结果而改变。
Best-rtn-subcode: similar to Best-return-code, but for the echo reply Subcode.
最佳rtn子代码：类似于最佳返回代码，但用于回显回复子代码。
FEC-status: result value returned by the FEC Checking algorithm described in Section 4.4.1.
FEC状态：第4.4.1节所述的FEC检查算法返回的结果值。
/* Save receive context information */
/* Save receive context information */
2. If the echo request is good, LSR X stores the interface over which the echo was received in Interface-I, and the label stack with which it came in Stack-R.
2. 如果echo请求良好，lsrx将在接口I中接收echo的接口以及在stack-R中接收echo的标签堆栈存储起来。
/* The rest of the algorithm iterates over the labels in Stack-R,
verifies validity of label values, reports associated label switching
operations (for traceroute), verifies correspondence between the
Stack-R and the Target FEC Stack description in the body of the echo
request, and reports any errors. */
/* The rest of the algorithm iterates over the labels in Stack-R,
verifies validity of label values, reports associated label switching
operations (for traceroute), verifies correspondence between the
Stack-R and the Target FEC Stack description in the body of the echo
request, and reports any errors. */
/* The algorithm iterates as follows. */
/* The algorithm iterates as follows. */
3. Label Validation:
3. 标签验证：
If Label-stack-depth is 0 {
如果标签堆栈深度为0{
/* The LSR needs to report that it is a tail end for the LSP */
/* The LSR needs to report that it is a tail end for the LSP */
Set FEC-stack-depth to 1, set Label-L to 3 (Implicit Null). Set Best-return-code to 3 ("Replying router is an egress for the FEC at stack-depth"), set Best-rtn-subcode to the value of FEC-stack-depth (1), and go to step 5 (Egress Processing).
将FEC堆栈深度设置为1，将Label-L设置为3（隐式Null）。将最佳返回码设置为3（“应答路由器是堆栈深度处FEC的出口”），将最佳rtn子码设置为FEC堆栈深度（1）的值，并转至步骤5（出口处理）。
}
}
/* This step assumes there is always an entry for well-known label
values */
/* This step assumes there is always an entry for well-known label
values */
Set Label-L to the value extracted from Stack-R at depth Label-stack-depth. Look up Label-L in the Incoming Label Map (ILM) to determine if the label has been allocated and an operation is associated with it.
将Label-L设置为从深度标签堆栈深度处的堆栈-R提取的值。在传入标签映射（ILM）中查找Label-L，以确定标签是否已分配，以及是否与操作关联。
If there is no entry for Label-L {
如果没有标签-L的条目{
/* Indicates a temporary or permanent label synchronization
problem, and the LSR needs to report an error */
/* Indicates a temporary or permanent label synchronization
problem, and the LSR needs to report an error */
Set Best-return-code to 11 ("No label entry at stack-depth") and Best-rtn-subcode to Label-stack-depth. Go to step 7 (Send Reply Packet).
将最佳返回码设置为11（“堆栈深度处无标签项”），并将最佳rtn子码设置为标签堆栈深度。转至步骤7（发送回复数据包）。
}
}
Else {
否则{
Retrieve the associated label operation from the corresponding Next Hop Label Forwarding Entry (NHLFE), and proceed to step 4 (Label Operation Check).
从相应的下一跳标签转发条目（NHLFE）中检索相关标签操作，并继续执行步骤4（标签操作检查）。
}
}
4. Label Operation Check
4. 标签操作检查
If the label operation is "Pop and Continue Processing" {
如果标签操作为“弹出并继续处理”{
/* Includes Explicit Null and Router Alert label cases */
/* Includes Explicit Null and Router Alert label cases */
Iterate to the next label by decrementing Label-stack-depth, and loop back to step 3 (Label Validation).
通过递减标签堆栈深度，迭代到下一个标签，并返回到步骤3（标签验证）。
}
}
If the label operation is "Swap or Pop and Switch based on Popped Label" {
如果标签操作为“交换或弹出，并根据弹出的标签进行切换”{
Set Best-return-code to 8 ("Label switched at stack-depth") and Best-rtn-subcode to Label-stack-depth to report transit switching.
将最佳返回代码设置为8（“标签在堆栈深度处切换”），将最佳rtn子代码设置为标签堆栈深度以报告传输切换。
If a Downstream Detailed Mapping TLV is present in the received echo request {
如果接收到的回显请求中存在下游详细映射TLV{
If the IP address in the TLV is 127.0.0.1 or 0::1 {
If the IP address in the TLV is 127.0.0.1 or 0::1 {
Set Best-return-code to 6 ("Upstream Interface Index Unknown"). An Interface and Label Stack TLV SHOULD be included in the reply and filled with Interface-I and Stack-R.
将最佳返回代码设置为6（“上游接口索引未知”）。回复中应包括接口和标签堆栈TLV，并填写接口I和堆栈R。
}
}
Else {
否则{
Verify that the IP address, interface address, and label stack in the Downstream Detailed Mapping TLV match Interface-I and Stack-R. If there is a mismatch, set Best-return-code to 5, "Downstream Mapping Mismatch". An Interface and Label Stack TLV SHOULD be included in the reply and filled in based on Interface-I and Stack-R. Go to step 7 (Send Reply Packet).
验证下游详细映射TLV中的IP地址、接口地址和标签堆栈是否与interface-I和stack-R匹配。如果存在不匹配，请将最佳返回代码设置为5，“下游映射不匹配”。应答中应包括接口和标签堆栈TLV，并根据接口I和堆栈R填写。转至步骤7（发送应答包）。
}
}
}
}
For each available downstream ECMP path {
对于每个可用的下游ECMP路径{
Retrieve output interface from the NHLFE entry.
从NHLFE条目检索输出接口。
/* Note: this Return Code is set even if Label-stack-depth
is one */
/* Note: this Return Code is set even if Label-stack-depth
is one */
If the output interface is not MPLS enabled {
如果输出接口未启用MPLS{
Set Best-return-code to Return Code 9, "Label switched but no MPLS forwarding at stack-depth" and set Best-rtn-subcode to Label-stack-depth and go to step 7 (Send Reply Packet).
将最佳返回码设置为返回码9，“标签交换但在堆栈深度没有MPLS转发”，并将最佳rtn子码设置为标签堆栈深度，然后转到步骤7（发送回复数据包）。
}
}
If a Downstream Detailed Mapping TLV is present {
如果存在下游详细映射TLV{
A Downstream Detailed Mapping TLV SHOULD be included in the echo reply (see Section 3.4) filled in with information about the current ECMP path.
回波回复（见第3.4节）中应包含下游详细映射TLV，并填写有关当前ECMP路径的信息。
}
}
}
}
If no Downstream Detailed Mapping TLV is present, or the Downstream IP Address is set to the ALLROUTERS multicast address, go to step 7 (Send Reply Packet).
如果不存在下游详细映射TLV，或者下游IP地址设置为ALLROUTERS多播地址，请转至步骤7（发送回复数据包）。
If the "Validate FEC Stack" flag is not set and the LSR is not configured to perform FEC checking by default, go to step 7 (Send Reply Packet).
如果未设置“验证FEC堆栈”标志，并且默认情况下LSR未配置为执行FEC检查，请转至步骤7（发送回复数据包）。
/* Validate the Target FEC Stack in the received echo request.
/* Validate the Target FEC Stack in the received echo request.
First determine FEC-stack-depth from the Downstream Detailed Mapping TLV. This is done by walking through Stack-D (the Downstream labels) from the bottom, decrementing the number of labels for each non-Implicit Null label, while incrementing FEC-stack-depth for each label. If the Downstream Detailed Mapping TLV contains one or more Implicit Null labels, FEC-stack-depth may be greater than Label-stack-depth. To be consistent with the above stack-depths, the bottom is considered to be entry 1. */
首先根据下游详细映射TLV确定FEC堆栈深度。这是通过从底部遍历Stack-D（下游标签）完成的，减少每个非隐式空标签的标签数量，同时增加每个标签的FEC堆栈深度。如果下游详细映射TLV包含一个或多个隐式空标签，则FEC堆栈深度可能大于标签堆栈深度。为了与上述堆叠深度一致，底部被视为入口1*/
Set FEC-stack-depth to 0. Set i to Label-stack-depth.
将FEC堆栈深度设置为0。将i设置为标签堆栈深度。
While (i > 0) do {
而（i>0）做什么{
++FEC-stack-depth.
if Stack-D [ FEC-stack-depth ] != 3 (Implicit Null)
--i.
}
++FEC-stack-depth.
if Stack-D [ FEC-stack-depth ] != 3 (Implicit Null)
--i.
}
If the number of FECs in the FEC stack is greater than or equal to FEC-stack-depth { Perform the FEC Checking procedure (see Section 4.4.1).
如果FEC堆栈中的FEC数量大于或等于FEC堆栈深度{执行FEC检查程序（见第4.4.1节）。
If FEC-status is 2, set Best-return-code to 10 ("Mapping for this FEC is not the given label at stack-depth").
如果FEC状态为2，则将最佳返回代码设置为10（“此FEC的映射不是堆栈深度处的给定标签”）。
If the Return Code is 1, set Best-return-code to FEC-return-code and Best-rtn-subcode to FEC-stack-depth. }
如果返回码为1，则将最佳返回码设置为FEC返回码，将最佳rtn子码设置为FEC堆栈深度。}
Go to step 7 (Send Reply Packet). }
转到步骤7（发送回复数据包）。}
5. Egress Processing:
5. 出口处理：
/* These steps are performed by the LSR that identified itself as
the tail-end LSR for an LSP. */
/* These steps are performed by the LSR that identified itself as
the tail-end LSR for an LSP. */
If the received echo request contains no Downstream Detailed Mapping TLV, or the Downstream IP Address is set to 127.0.0.1 or 0::1, go to step 6 (Egress FEC Validation).
如果接收到的echo请求不包含下游详细映射TLV，或者下游IP地址设置为127.0.0.1或0:：1，则转至步骤6（出口FEC验证）。
Verify that the IP address, interface address, and label stack in the Downstream Detailed Mapping TLV match Interface-I and Stack-R. If not, set Best-return-code to 5, "Downstream Mapping Mismatch". A Received Interface and Label Stack TLV SHOULD be created for the echo response packet. Go to step 7 (Send Reply Packet).
验证下游详细映射TLV中的IP地址、接口地址和标签堆栈是否与interface-I和stack-R匹配。如果不匹配，请将最佳返回代码设置为5，“下游映射不匹配”。应为回波响应数据包创建接收接口和标签堆栈TLV。转至步骤7（发送回复数据包）。
6. Egress FEC Validation:
6. 出口FEC验证：
/* This is a loop for all entries in the Target FEC Stack starting
with FEC-stack-depth. */
/* This is a loop for all entries in the Target FEC Stack starting
with FEC-stack-depth. */
Perform FEC checking by following the algorithm described in Section 4.4.1 for Label-L and the FEC at FEC-stack-depth.
按照第4.4.1节中针对Label-L和FEC堆栈深度的FEC描述的算法执行FEC检查。
Set Best-return-code to FEC-code and Best-rtn-subcode to the value in FEC-stack-depth.
将Best return code设置为FEC code，将Best rtn subcode设置为FEC堆栈深度中的值。
If FEC-status (the result of the check) is 1, go to step 7 (Send Reply Packet).
如果FEC状态（检查结果）为1，则转至步骤7（发送回复数据包）。
/* Iterate to the next FEC entry */
/* Iterate to the next FEC entry */
++FEC-stack-depth. If FEC-stack-depth > the number of FECs in the FEC-stack, go to step 7 (Send Reply Packet).
++FEC堆栈深度。如果FEC堆栈深度>FEC堆栈中的FEC数量，则转至步骤7（发送回复数据包）。
If FEC-status is 0 {
如果FEC状态为0{
++Label-stack-depth. If Label-stack-depth > the number of labels in Stack-R, go to step 7 (Send Reply Packet).
++标签堆栈深度。如果标签堆栈深度>stack-R中的标签数量，请转至步骤7（发送回复数据包）。
Label-L = extracted label from Stack-R at depth Label-stack-depth. Loop back to step 6 (Egress FEC Validation). }
Label-L=在深度标签堆栈深度处从堆栈-R提取的标签。返回到步骤6（出口FEC验证）。}
7. Send Reply Packet:
7. 发送回复数据包：
Send an MPLS echo reply with a Return Code of Best-return-code and a Return Subcode of Best-rtn-subcode. Include any TLVs created during the above process. The procedures for sending the echo reply are found in Section 4.5.
发送MPLS回显回复，返回码为最佳返回码，返回子码为最佳rtn子码。包括在上述过程中创建的任何TLV。发送回音回复的程序见第4.5节。
/* This section describes validation of a FEC entry within the Target
FEC Stack and accepts a FEC, Label-L, and Interface-I.
/* This section describes validation of a FEC entry within the Target
FEC Stack and accepts a FEC, Label-L, and Interface-I.
If the outermost FEC of the Target FEC stack is the Nil FEC, then the
node MUST skip the Target FEC validation completely. This is to
support FEC hiding, in which the outer hidden FEC can be the Nil FEC.
Else, the algorithm performs the following steps. */
If the outermost FEC of the Target FEC stack is the Nil FEC, then the
node MUST skip the Target FEC validation completely. This is to
support FEC hiding, in which the outer hidden FEC can be the Nil FEC.
Else, the algorithm performs the following steps. */
1. Two return values, FEC-status and FEC-return-code, are initialized to 0.
1. 两个返回值FEC status和FEC return code被初始化为0。
2. If the FEC is the Nil FEC {
2. 如果FEC是零FEC{
If Label-L is either Explicit_Null or Router_Alert, return.
如果Label-L是Explicit\u Null或Router\u Alert，则返回。
Else {
否则{
Set FEC-return-code to 10 ("Mapping for this FEC is not the given label at stack-depth"). Set FEC-status to 1 Return. }
将FEC返回代码设置为10（“此FEC的映射不是堆栈深度处的给定标签”）。将FEC状态设置为1返回。}
}
}
3. Check the FEC label mapping that describes how traffic received on the LSP is further switched or which application it is associated with. If no mapping exists, set FEC-return-code to Return 4, "Replying router has no mapping for the FEC at stack-depth". Set FEC-status to 1. Return.
3. 检查FEC标签映射，该映射描述如何进一步切换LSP上接收的通信量，或者该通信量与哪个应用程序关联。如果不存在映射，则将FEC返回代码设置为返回4，“应答路由器在堆栈深度没有FEC的映射”。将FEC状态设置为1。回来
4. If the label mapping for FEC is Implicit Null, set FEC-status to 2 and proceed to step 5. Otherwise, if the label mapping for FEC is Label-L, proceed to step 5. Otherwise, set FEC-return-code to 10 ("Mapping for this FEC is not the given label at stack-depth"), set FEC-status to 1, and return.
4. 如果FEC的标签映射为隐式Null，则将FEC状态设置为2并继续执行步骤5。否则，如果FEC的标签映射为label-L，则转至步骤5。否则，将FEC返回代码设置为10（“此FEC的映射不是堆栈深度处的给定标签”），将FEC状态设置为1，然后返回。
5. This is a protocol check. Check what protocol would be used to advertise the FEC. If it can be determined that no protocol associated with Interface-I would have advertised a FEC of that FEC-Type, set FEC-return-code to 12 ("Protocol not associated with interface at FEC stack-depth"). Set FEC-status to 1.
5. 这是一个协议检查。检查用于公布FEC的协议。如果可以确定没有与接口I关联的协议会公布该FEC类型的FEC，则将FEC返回码设置为12（“与FEC堆栈深度处的接口无关的协议”）。将FEC状态设置为1。
6. Return.
6. 回来
An MPLS echo reply is a UDP packet. It MUST ONLY be sent in response to an MPLS echo request. The source IP address is a routable address of the replier; 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 echo request. The IP TTL is set to 255. If the Reply Mode in the echo request is "Reply via an IPv4 UDP packet with Router Alert", then the IP header MUST contain the Router Alert IP Option of value 0x0 [RFC2113] for IPv4 or 69 [RFC7506] for IPv6. If the reply is sent over an LSP, the topmost label MUST in this case be the Router Alert label (1) (see [RFC3032]).
MPLS回显应答是UDP数据包。它必须仅在响应MPLS回送请求时发送。源IP地址是应答器的可路由地址；源端口是众所周知的用于LSP ping的UDP端口。从echo请求的源IP地址和UDP端口复制目标IP地址和UDP端口。IP TTL设置为255。如果回送请求中的回复模式为“通过IPv4 UDP数据包回复路由器警报”，则IP报头必须包含值0x0[RFC2113]的路由器警报IP选项（对于IPv4）或值69[RFC7506]的路由器警报IP选项（对于IPv6）。如果通过LSP发送回复，则在这种情况下，最上面的标签必须是路由器警报标签（1）（请参阅[RFC3032]）。
The format of the echo reply is the same as the echo request. The Sender's Handle, the Sequence Number, and TimeStamp Sent are copied from the echo request; the TimeStamp Received is set to the time of day that the echo request is received (note that this information is most useful if the time-of-day clocks on the requester and the replier are synchronized). The FEC Stack TLV from the echo request MAY be copied to the reply.
回送回复的格式与回送请求的格式相同。发送方的句柄、序列号和发送的时间戳从echo请求中复制；接收的时间戳被设置为接收回显请求的时间（注意，如果请求者和应答者上的时间时钟是同步的，则此信息最有用）。来自echo请求的FEC堆栈TLV可以复制到应答。
The replier MUST fill in the Return Code and Subcode, as determined in the previous section.
回复者必须填写上一节中确定的返回代码和子代码。
If the echo request contains a Pad TLV, the replier MUST interpret the first octet for instructions regarding how to reply.
如果echo请求包含Pad TLV，应答者必须解释第一个八位字节，以获取有关如何应答的说明。
If the replying router is the destination of the FEC, then Downstream Detailed Mapping TLVs SHOULD NOT be included in the echo reply.
如果应答路由器是FEC的目的地，则回送应答中不应包括下游详细映射TLV。
If the echo request contains a Downstream Detailed Mapping TLV, and the replying router is not the destination of the FEC, the replier SHOULD compute its downstream routers and corresponding labels for the incoming label and add Downstream Detailed Mapping TLVs for each one to the echo reply it sends back. A replying node should follow the procedures defined in Section 4.5.1 if there is a FEC stack change due to tunneled LSP. If the FEC stack change is due to stitched LSP, it should follow the procedures defined in Section 4.5.2.
如果echo请求包含下游详细映射TLV，并且应答路由器不是FEC的目的地，应答器应计算其下游路由器和传入标签的相应标签，并将每个标签的下游详细映射TLV添加到其发送回的echo应答中。如果由于隧道LSP导致FEC堆栈发生变化，则应答节点应遵循第4.5.1节中定义的程序。如果FEC堆栈更改是由于缝合LSP引起的，则应遵循第4.5.2节中规定的程序。
If the Downstream Detailed Mapping TLV contains Multipath Information requiring more processing than the receiving router is willing to perform, the responding router MAY choose to respond with only a subset of multipaths contained in the echo request Downstream Detailed Mapping. (Note: The originator of the echo request MAY send another echo request with the Multipath Information that was not included in the reply.)
如果下游详细映射TLV包含需要比接收路由器愿意执行的更多处理的多路径信息，则响应路由器可以选择仅使用回波请求下游详细映射中包含的多路径子集进行响应。（注意：回显请求的发起人可以发送另一个回显请求，其中包含回复中未包含的多路径信息。）
Except in the case of Reply Mode 4, "Reply via application-level control channel", echo replies are always sent in the context of the IP/MPLS network.
除了回复模式4“通过应用程序级控制通道回复”的情况外，回声回复始终在IP/MPLS网络的上下文中发送。
A transit node knows when the FEC being traced is going to enter a tunnel at that node. Thus, it knows about the new outer FEC. All transit nodes that are the origination point of a new tunnel SHOULD add the FEC stack change sub-TLV (Section 3.4.1.3) to the Downstream Detailed Mapping TLV in the echo reply. The transit node SHOULD add one FEC stack change sub-TLV of operation type PUSH, per new tunnel being originated at the transit node.
传输节点知道被跟踪的FEC何时将进入该节点的隧道。因此，它知道新的外部FEC。作为新隧道起点的所有运输节点应将FEC堆栈变更子TLV（第3.4.1.3节）添加到回声回复中的下游详细映射TLV中。对于在传输节点发起的每个新隧道，传输节点应添加一个操作类型为PUSH的FEC堆栈更改子TLV。
A transit node that sends a Downstream FEC stack change sub-TLV in the echo reply SHOULD fill the address of the remote peer, which is the peer of the current LSP being traced. If the transit node does not know the address of the remote peer, it MUST set the address type to Unspecified.
在回送应答中发送下游FEC堆栈更改子TLV的传输节点应填写远程对等方的地址，该远程对等方是正在跟踪的当前LSP的对等方。如果传输节点不知道远程对等方的地址，则必须将地址类型设置为“未指定”。
The Label Stack sub-TLV MUST contain one additional label per FEC being PUSHed. The label MUST be encoded as defined in Section 3.4.1.2. The label value MUST be the value used to switch the data traffic. If the tunnel is a transparent pipe to the node, i.e., the data-plane trace will not expire in the middle of the new tunnel, then a FEC stack change sub-TLV SHOULD NOT be added, and the Label Stack sub-TLV SHOULD NOT contain a label corresponding to the hidden tunnel.
标签堆栈子TLV必须为每个正在推送的FEC包含一个附加标签。标签必须按照第3.4.1.2节的规定进行编码。标签值必须是用于切换数据流量的值。如果隧道是节点的透明管道，即数据平面迹线不会在新隧道的中间过期，那么不应该添加FEC堆栈改变子TLV，并且标签堆栈子TLV不应该包含对应于隐藏隧道的标签。
If the transit node wishes to hide the nature of the tunnel from the ingress of the echo request, then it MAY not want to send details about the new tunnel FEC to the ingress. In such a case, the transit node SHOULD use the Nil FEC. The echo reply would then contain a FEC stack change sub-TLV with operation type PUSH and a Nil FEC. The value of the label in the Nil FEC MUST be set to zero. The remote peer address type MUST be set to Unspecified. The transit node SHOULD add one FEC stack change sub-TLV of operation type PUSH, per new tunnel being originated at the transit node. The Label Stack sub-TLV MUST contain one additional label per FEC being PUSHed. The label value MUST be the value used to switch the data traffic.
如果传输节点希望对echo请求的入口隐藏隧道的性质，那么它可能不希望向入口发送关于新隧道FEC的详细信息。在这种情况下，传输节点应该使用Nil FEC。然后，echo应答将包含操作类型为PUSH的FEC堆栈更改子TLV和Nil FEC。Nil FEC中标签的值必须设置为零。远程对等地址类型必须设置为未指定。对于在传输节点发起的每个新隧道，传输节点应添加一个操作类型为PUSH的FEC堆栈更改子TLV。标签堆栈子TLV必须为每个正在推送的FEC包含一个附加标签。标签值必须是用于切换数据流量的值。
A transit node stitching two LSPs SHOULD include two FEC stack change sub-TLVs. One with a pop operation for the old FEC (ingress) and one with the PUSH operation for the new FEC (egress). The replying node SHOULD set the Return Code to "Label switched with FEC change" to indicate change in the FEC being traced.
缝合两个LSP的传输节点应包括两个FEC堆栈更改子TLV。一个用于旧FEC的pop操作（入口），另一个用于新FEC的PUSH操作（出口）。应答节点应将返回代码设置为“标签切换FEC更改”，以指示正在跟踪的FEC中的更改。
If the replying node wishes to perform FEC hiding, it SHOULD respond back with two FEC stack change sub-TLVs, one pop followed by one PUSH. The pop operation MAY either exclude the FEC TLV (by setting the FEC TLV length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH operation SHOULD have the FEC TLV containing the Nil FEC. The Return Code SHOULD be set to "Label switched with FEC change".
如果应答节点希望执行FEC隐藏，它应该使用两个FEC堆栈更改子TLV进行响应，一个pop，然后一个PUSH。pop操作可以排除FEC TLV（通过将FEC TLV长度设置为0），或者将FEC TLV设置为包含LDP FEC。推送操作应使FEC TLV包含Nil FEC。返回代码应设置为“标签随FEC变化而切换”。
If the replying node wishes to perform FEC hiding, it MAY choose to not send any FEC stack change sub-TLVs in the echo reply if the number of labels does not change for the downstream node and the FEC type also does not change (Nil FEC). In such case, the replying node MUST NOT set the Return Code to "Label switched with FEC change".
如果应答节点希望执行FEC隐藏，则如果下游节点的标签数量没有改变并且FEC类型也没有改变（Nil FEC），则它可以选择不在echo应答中发送任何FEC堆栈改变子tlv。在这种情况下，应答节点不得将返回代码设置为“标签切换FEC更改”。
An LSR X should only receive an MPLS echo reply in response to an MPLS echo request that it sent. Thus, on receipt of an MPLS echo reply, X should parse the packet to ensure that it is well-formed, then attempt to match up the echo reply with an echo request that it had previously sent, using the destination UDP port and the Sender's Handle. If no match is found, then X jettisons the echo reply; otherwise, it checks the Sequence Number to see if it matches.
LSR X应仅接收MPLS回送回复，以响应其发送的MPLS回送请求。因此，在收到MPLS回送回复时，X应该解析数据包以确保其格式正确，然后尝试使用目标UDP端口和发送方句柄将回送回复与它以前发送的回送请求相匹配。如果没有找到匹配项，则X丢弃回音应答；否则，它会检查序列号以查看是否匹配。
If the echo reply contains Downstream Detailed Mappings, and X wishes to traceroute further, it SHOULD copy the Downstream Detailed Mapping(s) into its next echo request(s) (with TTL incremented by one).
如果回送回复包含下游详细映射，并且X希望进一步跟踪路由，则应将下游详细映射复制到其下一个回送请求中（TTL增加1）。
If one or more FEC stack change sub-TLVs are received in the MPLS echo reply, the ingress node SHOULD process them and perform some validation.
如果在MPLS回送应答中接收到一个或多个FEC堆栈更改子TLV，则入口节点应处理它们并执行一些验证。
The FEC stack changes are associated with a downstream neighbor and along a particular path of the LSP. Consequently, the ingress will need to maintain a FEC stack per path being traced (in case of multipath). All changes to the FEC stack resulting from the processing of a FEC stack change sub-TLV(s) should be applied only for the path along a given downstream neighbor. The following algorithm should be followed for processing FEC stack change sub-TLVs.
FEC堆栈改变与下游邻居关联，并且沿着LSP的特定路径。因此，入口将需要在跟踪的每条路径上保持FEC堆栈（在多路径情况下）。处理FEC堆栈更改子TLV对FEC堆栈的所有更改应仅应用于沿给定下游邻居的路径。处理FEC堆栈更改子TLV时，应遵循以下算法。
push_seen = FALSE fec_stack_depth = current-depth-of-fec-stack-being-traced saved_fec_stack = current_fec_stack
push_seen=FALSE fec_stack_depth=正在跟踪的fec stack的当前深度保存的fec_stack=当前的fec_stack
while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))
而（子tlv=获取下一个子tlv（下游详细地图）
if (sub-tlv == NULL) break
如果（子tlv==NULL）中断
if (sub-tlv.type == FEC-Stack-Change) {
if (sub-tlv.type == FEC-Stack-Change) {
if (sub-tlv.operation == POP) {
if (push_seen) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (sub-tlv.operation == POP) {
if (push_seen) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
Pop FEC from FEC stack being traced
fec_stack_depth--;
}
Pop FEC from FEC stack being traced
fec_stack_depth--;
}
if (sub-tlv.operation == PUSH) {
push_seen = 1
Push FEC on FEC stack being traced
fec_stack_depth++;
}
}
}
if (sub-tlv.operation == PUSH) {
push_seen = 1
Push FEC on FEC stack being traced
fec_stack_depth++;
}
}
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
The next MPLS echo request along the same path should use the modified FEC stack obtained after processing the FEC stack change sub-TLVs. A non-Nil FEC guarantees that the next echo request along the same path will have the Downstream Detailed Mapping TLV validated for IP address, interface address, and label stack mismatches.
沿同一路径的下一个MPLS回波请求应使用在处理FEC堆栈更改子TLV后获得的修改后的FEC堆栈。非Nil FEC保证沿同一路径的下一个echo请求将验证下游详细映射TLV的IP地址、接口地址和标签堆栈不匹配。
If the top of the FEC stack is a Nil FEC and the MPLS echo reply does not contain any FEC stack change sub-TLVs, then it does not necessarily mean that the LSP has not started traversing a different tunnel. It could be that the LSP associated with the Nil FEC terminated at a transit node, and at the same time, a new LSP started at the same transit node. The Nil FEC would now be associated with the new LSP (and the ingress has no way of knowing this). Thus, it is not possible to build an accurate hierarchical LSP topology if a traceroute contains Nil FECs.
如果FEC堆栈的顶部是Nil FEC，并且MPLS echo reply不包含任何FEC堆栈更改子tlv，那么这并不一定意味着LSP没有开始穿越不同的隧道。可能是与Nil FEC相关联的LSP在传输节点处终止，同时，新LSP在同一传输节点处启动。Nil FEC现在将与新LSP相关联（入口无法知道这一点）。因此，如果跟踪路由包含Nil FEC，则不可能构建准确的分层LSP拓扑。
A reply from a downstream node with Return Code 3, may not necessarily be for the FEC being traced. It could be for one of the new FECs that was added. On receipt of an IS_EGRESS reply, the LSP ingress should check if the depth of Target FEC sent to the node that just responded was the same as the depth of the FEC that was being traced. If it was not, then it should pop an entry from the Target FEC stack and resend the request with the same TTL (as previously sent). The process of popping a FEC is to be repeated until either the LSP ingress receives a non-IS_EGRESS reply or until all the additional FECs added to the FEC stack have already been popped. Using an IS_EGRESS reply, an ingress can build a map of the hierarchical LSP structure traversed by a given FEC.
来自下游节点的返回代码为3的应答不一定是针对被跟踪的FEC的。这可能是因为添加了一种新的FEC。在收到IS_出口回复后，LSP入口应检查发送到刚刚响应的节点的目标FEC的深度是否与正在跟踪的FEC的深度相同。如果不是，那么它应该从目标FEC堆栈中弹出一个条目，并使用相同的TTL重新发送请求（与之前发送的相同）。弹出FEC的过程将重复，直到LSP入口接收到非is_出口回复，或者直到添加到FEC堆栈的所有附加FEC已经弹出。使用IS_出口回复，入口可以构建给定FEC所遍历的分层LSP结构的映射。
When the MPLS echo reply Return Code is "Label switched with FEC change", the ingress node SHOULD manipulate the FEC stack as per the FEC stack change sub-TLVs contained in the Downstream Detailed Mapping TLV. A transit node can use this Return Code for stitched LSPs and for hierarchical LSPs. In case of ECMP or P2MP, there could be multiple paths and Downstream Detailed Mapping TLVs with different Return Codes (see Section 3.1, Note 2). The ingress node should build the topology based on the Return Code per ECMP path/P2MP branch.
当MPLS回显回复返回码为“标签切换FEC更改”时，入口节点应根据下游详细映射TLV中包含的FEC堆栈更改子TLV操作FEC堆栈。中转节点可以将此返回代码用于缝合LSP和分层LSP。对于ECMP或P2MP，可能有多条路径和下游详细映射TLV，返回代码不同（见第3.1节注释2）。入口节点应根据每个ECMP path/P2MP分支的返回代码构建拓扑。
Typically, an LSP ping for a VPN IPv4 prefix or VPN IPv6 prefix is sent with a label stack of depth greater than 1, with the innermost label having a TTL of 1. This is to terminate the ping at the egress PE, before it gets sent to the customer device. However, under certain circumstances, the label stack can shrink to a single label before the ping hits the egress PE; this will result in the ping terminating prematurely. One such scenario is a multi-AS Carrier's Carrier VPN.
通常，发送VPN IPv4前缀或VPN IPv6前缀的LSP ping时，标签堆栈的深度大于1，最里面的标签的TTL为1。这是在将ping发送到客户设备之前，在出口PE处终止ping。然而，在某些情况下，标签堆栈可以在ping到达出口PE之前收缩为单个标签；这将导致ping过早终止。其中一个场景是多AS运营商的运营商VPN。
To get around this problem, one approach is for the LSR that receives such a ping to realize that the ping terminated prematurely and to send back Return Code 13. In that case, the initiating LSR can retry
为了解决这个问题，一种方法是让接收到这样一个ping的LSR意识到ping提前终止并发送回返回码13。在这种情况下，启动LSR可以重试
the ping after incrementing the TTL on the VPN label. In this fashion, the ingress LSR will sequentially try TTL values until it finds one that allows the VPN ping to reach the egress PE.
增加VPN标签上的TTL后的ping。以这种方式，入口LSR将依次尝试TTL值，直到找到一个允许VPN ping到达出口PE的值。
If the egress for the FEC Stack being pinged does not support LSP ping, then no reply will be sent, resulting in possible "false negatives". When in "traceroute" mode, if a transit LSR does not support LSP ping, then no reply will be forthcoming from that LSR for some TTL, say, n. The LSR originating the echo request SHOULD try sending the echo request with TTL=n+1, n+2, ..., n+k to probe LSRs further down the path. In such a case, the echo request for TTL > n SHOULD be sent with the Downstream Detailed Mapping TLV "Downstream IP Address" field set to the ALLROUTERs multicast address until a reply is received with a Downstream Detailed Mapping TLV. The label Stack TLV MAY be omitted from the Downstream Detailed Mapping TLV. Furthermore, the "Validate FEC Stack" flag SHOULD NOT be set until an echo reply packet with a Downstream Detailed Mapping TLV is received.
如果正在ping的FEC堆栈的出口不支持LSP ping，则不会发送应答，从而导致可能的“假阴性”。当处于“跟踪路由”模式时，如果传输LSR不支持LSP ping，那么对于某些TTL（例如，n），该LSR将不会给出任何回复。发起回显请求的LSR应尝试发送TTL=n+1，n+2，…，n+k的回显请求，以探测路径上更远的LSR。在这种情况下，TTL>n的回送请求应在下游详细映射TLV“下游IP地址”字段设置为ALLROUTERs多播地址的情况下发送，直到收到带有下游详细映射TLV的回复。标签堆栈TLV可以从下游详细映射TLV中省略。此外，在接收到具有下游详细映射TLV的回声应答包之前，不应设置“验证FEC堆栈”标志。
Overall, the security needs for LSP ping are similar to those of ICMP ping.
总的来说，LSP ping的安全需求与ICMP ping相似。
There are at least three approaches to attacking LSRs using the mechanisms defined here. One is a Denial-of-Service (DoS) attack, by sending MPLS echo requests/replies to LSRs and thereby increasing their workload. The second is obfuscating the state of the MPLS data-plane liveness by spoofing, hijacking, replaying, or otherwise tampering with MPLS echo requests and replies. The third is an unauthorized source using an LSP ping to obtain information about the network.
使用此处定义的机制攻击LSR至少有三种方法。一种是拒绝服务（DoS）攻击，通过向LSR发送MPLS回送请求/回复，从而增加其工作负载。第二种是通过欺骗、劫持、重放或以其他方式篡改MPLS回送请求和回复来混淆MPLS数据平面活动的状态。第三个是未经授权的来源，使用LSP ping获取有关网络的信息。
To avoid potential DoS attacks, it is RECOMMENDED that implementations regulate the LSP ping traffic going to the control plane. A rate limiter SHOULD be applied to the well-known UDP port defined in Section 6.1.
为了避免潜在的DoS攻击，建议实施管理到控制平面的LSP ping通信量。速率限制器应应用于第6.1节中定义的众所周知的UDP端口。
Unsophisticated replay and spoofing attacks involving faking or replaying MPLS echo reply messages are unlikely to be effective. These replies would have to match the Sender's Handle and Sequence Number of an outstanding MPLS echo request message. A non-matching replay would be discarded as the sequence has moved on, thus a spoof has only a small window of opportunity. However, to provide a stronger defense, an implementation MAY also validate the TimeStamp Sent by requiring an exact match on this field.
涉及伪造或重放MPLS回显回复消息的简单重放和欺骗攻击不太可能有效。这些回复必须与未完成的MPLS回送请求消息的发送方句柄和序列号相匹配。当序列继续移动时，不匹配的重播将被丢弃，因此欺骗只有很小的机会。然而，为了提供更强的防御，实现还可以通过要求在该字段上进行精确匹配来验证发送的时间戳。
To protect against unauthorized sources using MPLS echo request messages to obtain network information, it is RECOMMENDED that implementations provide a means of checking the source addresses of MPLS echo request messages against an access list before accepting the message.
为了防止未经授权的源使用MPLS回送请求消息获取网络信息，建议实现提供在接受消息之前根据访问列表检查MPLS回送请求消息的源地址的方法。
It is not clear how to prevent hijacking (non-delivery) of echo requests or replies; however, if these messages are indeed hijacked, LSP ping will report that the data plane is not working as it should.
不清楚如何防止劫持（未送达）回送请求或回复；但是，如果这些消息确实被劫持，LSP ping将报告数据平面没有正常工作。
It does not seem vital (at this point) to secure the data carried in MPLS echo requests and replies, although knowledge of the state of the MPLS data plane may be considered confidential by some. Implementations SHOULD, however, provide a means of filtering the addresses to which echo reply messages may be sent.
保护MPLS回送请求和回复中携带的数据似乎并不重要（此时），尽管一些人可能认为对MPLS数据平面状态的了解是机密的。然而，实现应该提供一种过滤回送回复消息可能发送到的地址的方法。
The value part of the Pad TLV contains a variable number of octets. With the exception of the first octet, these contents, if any, are ignored on receipt, and can therefore serve as a clandestine channel.
Pad TLV的值部分包含可变数量的八位字节。除了第一个八位组外，这些内容（如果有）在收到时被忽略，因此可以作为秘密通道。
When MPLS LSP ping is used within an administrative domain, a deployment can increase security by using border filtering of incoming LSP ping packets as well as outgoing LSP ping packets.
当在管理域内使用MPLS LSP ping时，部署可以通过使用传入LSP ping数据包以及传出LSP ping数据包的边界过滤来提高安全性。
Although this document makes special use of 127/8 addresses, these are used only in conjunction with the UDP port 3503. Furthermore, these packets are only processed by routers. All other hosts MUST treat all packets with a destination address in the range 127/8 in accordance to RFC 1122. Any packet received by a router with a destination address in the range 127/8 without a destination UDP port of 3503 MUST be treated in accordance to RFC 1812. In particular, the default behavior is to treat packets destined to a 127/8 address as "martians".
尽管本文档特别使用127/8地址，但这些地址仅与UDP端口3503结合使用。此外，这些数据包仅由路由器处理。根据RFC 1122，所有其他主机必须处理目标地址在127/8范围内的所有数据包。路由器接收到的目的地址在127/8范围内且目的UDP端口为3503的任何数据包必须按照RFC 1812进行处理。特别是，默认行为是将发送到127/8地址的数据包视为“火星人”。
If a network operator wants to prevent tracing inside a tunnel, one can use the Pipe Model [RFC3443], i.e., hide the outer MPLS tunnel by not propagating the MPLS TTL into the outer tunnel (at the start of the outer tunnel). By doing this, LSP traceroute packets will not expire in the outer tunnel, and the outer tunnel will not get traced.
如果网络运营商想要阻止隧道内的跟踪，可以使用管道模型[RFC3443]，即通过不将MPLS TTL传播到外部隧道（在外部隧道的开始处）来隐藏外部MPLS隧道。通过这样做，LSP跟踪路由数据包将不会在外部隧道中过期，并且外部隧道将不会被跟踪。
If one doesn't wish to expose the details of the new outer LSP, then the Nil FEC can be used to hide those details. Using the Nil FEC ensures that the trace progresses without false negatives and all transit nodes (of the new outer tunnel) perform some minimal validations on the received MPLS echo requests.
如果不希望公开新的外部LSP的细节，那么可以使用Nil FEC来隐藏这些细节。使用Nil FEC可以确保跟踪过程不会出现误报，并且（新外部隧道的）所有传输节点都会对接收到的MPLS回波请求执行一些最小的验证。
The TCP and UDP port number 3503 has been allocated by IANA for LSP echo requests and replies.
IANA已为LSP回显请求和回复分配TCP和UDP端口号3503。
IANA maintains the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry at [IANA-MPLS-LSP-PING].
IANA在[IANA-MPLS-LSP-Ping]维护“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表。
The following subsections detail the name spaces managed by IANA. For some of these name spaces, the space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values: "Standards Action" (as defined in [RFC5226]), "Specification Required", and "Vendor Private Use".
以下小节详细介绍了IANA管理的名称空间。对于其中一些名称空间，该空间被划分为分配范围；以下术语用于描述IANA分配值的程序：“标准行动”（定义见[RFC5226]）、“所需规范”和“供应商私人使用”。
Values from "Specification Required" ranges MUST be registered with IANA. The request MUST be made via an RFC that describes the format and procedures for using the code point; the actual assignment is made during the IANA actions for the RFC.
“所需规格”范围内的值必须向IANA注册。请求必须通过RFC提出，RFC描述了使用代码点的格式和程序；实际分配在IANA针对RFC的行动期间进行。
Values from "Vendor Private" ranges MUST NOT be registered with IANA; however, the message MUST contain an enterprise code as registered with the IANA SMI Private Network Management Private Enterprise Numbers. For each name space that has a Vendor Private range, it must be specified where exactly the SMI Private Enterprise Number resides; see below for examples. In this way, several enterprises (vendors) can use the same code point without fear of collision.
“供应商专用”范围内的值不得向IANA注册；但是，消息必须包含注册IANA SMI专用网络管理专用企业编号的企业代码。对于具有供应商专用范围的每个名称空间，必须指定SMI专用企业编号的确切位置；参见下面的示例。通过这种方式，多个企业（供应商）可以使用相同的代码点，而不必担心冲突。
IANA has created and will maintain registries for Message Types, Reply Modes, and Return Codes. Each of these can take values in the range 0-255. Assignments in the range 0-191 are via Standards Action; assignments in the range 192-251 are made via "Specification Required"; values in the range 252-255 are for Vendor Private Use and MUST NOT be allocated.
IANA已经创建并将维护消息类型、回复模式和返回代码的注册表。每一个都可以取0-255范围内的值。0-191范围内的分配通过标准行动进行；192-251范围内的分配通过“所需规格”进行；252-255范围内的值仅供供应商私人使用，不得分配。
If any of these fields fall in the Vendor Private range, a top-level Vendor Enterprise Number TLV MUST be present in the message.
如果这些字段中的任何一个属于供应商专用范围，则消息中必须存在顶级供应商企业编号TLV。
Message Types defined in this document are the following:
本文档中定义的消息类型如下：
Value Meaning
----- -------
1 MPLS Echo Request
2 MPLS Echo Reply
Value Meaning
----- -------
1 MPLS Echo Request
2 MPLS Echo Reply
Reply Modes defined in this document are the following:
本文件中定义的回复模式如下：
Value Meaning
----- -------
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application-level control channel
Value Meaning
----- -------
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application-level control channel
Return Codes defined in this document are listed in Section 3.1.
第3.1节列出了本文件中定义的返回代码。
IANA has updated the reference for each these values to this document.
IANA已更新了本文件中每个值的参考。
IANA has created and maintains a registry for the Type field of top-level TLVs as well as for any associated sub-TLVs. Note that the meaning of a sub-TLV is scoped by the TLV. The number spaces for the sub-TLVs of various TLVs are independent.
IANA已经为顶级TLV的类型字段以及任何相关子TLV创建并维护了一个注册表。注意，子TLV的含义由TLV确定。不同TLV的子TLV的数字空间是独立的。
The valid range for TLVs and sub-TLVs is 0-65535. Assignments in the ranges 0-16383 and 32768-49161 are made via Standards Action as defined in [RFC5226]; assignments in the ranges 16384-31743 and 49162-64511 are made via "Specification Required"; values in the ranges 31744-32767 and 64512-65535 are for Vendor Private Use and MUST NOT be allocated.
TLV和子TLV的有效范围为0-65535。0-16383和32768-49161范围内的分配通过[RFC5226]中定义的标准行动进行；16384-31743和49162-64511范围内的分配通过“所需规范”进行；31744-32767和64512-65535范围内的值仅供供应商私人使用，不得分配。
If a TLV or sub-TLV has a Type that falls in the range for Vendor Private Use, the Length MUST be at least 4, and the first four octets MUST be that vendor's SMI Private Enterprise Number, in network octet order. The rest of the Value field is private to the vendor.
如果TLV或子TLV的类型在供应商专用范围内，则长度必须至少为4，并且前四个八位字节必须是该供应商的SMI专用企业编号，以网络八位字节顺序排列。值字段的其余部分是供应商专有的。
TLVs and sub-TLVs defined in this document are the following:
本文件中定义的TLV和子TLV如下：
Type Sub-Type Value Field
---- -------- -----------
1 Target FEC Stack
1 LDP IPv4 prefix
2 LDP IPv6 prefix
3 RSVP IPv4 LSP
4 RSVP IPv6 LSP
5 Unassigned
6 VPN IPv4 prefix
7 VPN IPv6 prefix
8 L2 VPN endpoint
9 "FEC 128" Pseudowire - IPv4 (Deprecated)
10 "FEC 128" Pseudowire - IPv4
11 "FEC 129" Pseudowire - IPv4
12 BGP labeled IPv4 prefix
13 BGP labeled IPv6 prefix
14 Generic IPv4 prefix
15 Generic IPv6 prefix
16 Nil FEC
24 "FEC 128" Pseudowire - IPv6
25 "FEC 129" Pseudowire - IPv6
2 Downstream Mapping (Deprecated)
3 Pad
4 Unassigned
5 Vendor Enterprise Number
6 Unassigned
7 Interface and Label Stack
8 Unassigned
9 Errored TLVs
Any value The TLV not understood
10 Reply TOS Byte
20 Downstream Detailed Mapping
Type Sub-Type Value Field
---- -------- -----------
1 Target FEC Stack
1 LDP IPv4 prefix
2 LDP IPv6 prefix
3 RSVP IPv4 LSP
4 RSVP IPv6 LSP
5 Unassigned
6 VPN IPv4 prefix
7 VPN IPv6 prefix
8 L2 VPN endpoint
9 "FEC 128" Pseudowire - IPv4 (Deprecated)
10 "FEC 128" Pseudowire - IPv4
11 "FEC 129" Pseudowire - IPv4
12 BGP labeled IPv4 prefix
13 BGP labeled IPv6 prefix
14 Generic IPv4 prefix
15 Generic IPv6 prefix
16 Nil FEC
24 "FEC 128" Pseudowire - IPv6
25 "FEC 129" Pseudowire - IPv6
2 Downstream Mapping (Deprecated)
3 Pad
4 Unassigned
5 Vendor Enterprise Number
6 Unassigned
7 Interface and Label Stack
8 Unassigned
9 Errored TLVs
Any value The TLV not understood
10 Reply TOS Byte
20 Downstream Detailed Mapping
IANA has updated the reference for each of these values to this document.
IANA已更新了本文件中每个值的参考。
IANA has created a "Global Flags" subregistry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 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 | [RFC8029]
14 | T Flag | [RFC6425]
13 | R Flag | [RFC6426]
12-0 | Unassigned | [RFC8029]
Bit number | Name | Reference
------------+----------------------------+--------------
15 | V Flag | [RFC8029]
14 | T Flag | [RFC6425]
13 | R Flag | [RFC6426]
12-0 | Unassigned | [RFC8029]
This document extends RFC 4379 by defining a new address type for use with the Downstream Mapping and Downstream Detailed Mapping TLVs. IANA has established a registry to assign address types for use with the Downstream Mapping and Downstream Detailed Mapping TLVs, which initially allocates the following assignments:
本文档通过定义一种新的地址类型来扩展RFC4379，以用于下游映射和下游详细映射TLV。IANA已建立了一个注册表，用于分配地址类型，以便与下游映射和下游详细映射TLV一起使用，最初分配以下分配：
Type # Address Type K Octets Reference
------ ------------ -------- ---------
1 IPv4 Numbered 16 [RFC8029]
2 IPv4 Unnumbered 16 [RFC8029]
3 IPv6 Numbered 40 [RFC8029]
4 IPv6 Unnumbered 28 [RFC8029]
5 Non IP 12 [RFC6426]
Type # Address Type K Octets Reference
------ ------------ -------- ---------
1 IPv4 Numbered 16 [RFC8029]
2 IPv4 Unnumbered 16 [RFC8029]
3 IPv6 Numbered 40 [RFC8029]
4 IPv6 Unnumbered 28 [RFC8029]
5 Non IP 12 [RFC6426]
Downstream Detailed Mapping Address Type Registry
下游详细映射地址类型注册表
Because the field in this case is an 8-bit field, the allocation policy for this registry is "Standards Action".
由于本例中的字段是8位字段，因此此注册表的分配策略为“标准操作”。
This document defines the Downstream Mapping (DSMAP) TLV and the Downstream Detailed Mapping (DDMAP) TLV, which have Type 2 and Type 20, respectively, assigned from the "TLVs" subregistry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry.
本文件定义了下游映射（DSMAP）TLV和下游详细映射（DDMAP）TLV，它们分别具有类型2和类型20，从“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表的“TLV”子区分配。
DSMAP has been deprecated by DDMAP, but both TLVs share a field: DS Flags.
DDMAP不推荐使用DSMAP，但两个TLV共享一个字段：DS标志。
IANA has created and now maintains a registry entitled "DS Flags".
IANA已经创建并维护了一个名为“DS标志”的注册表。
The registration policy for this registry is Standards Action [RFC5226].
此注册表的注册策略为标准操作[RFC5226]。
IANA has made the following assignments:
IANA已完成以下任务：
Bit Number Name Reference
---------- ------------------------------------------- ---------
7 N: Treat as a Non-IP Packet [RFC8029]
6 I: Interface and Label Stack Object Request [RFC8029]
5 E: ELI/EL push indicator [RFC8012]
4 L: Label-based load balance indicator [RFC8012]
3-0 Unassigned
Bit Number Name Reference
---------- ------------------------------------------- ---------
7 N: Treat as a Non-IP Packet [RFC8029]
6 I: Interface and Label Stack Object Request [RFC8029]
5 E: ELI/EL push indicator [RFC8012]
4 L: Label-based load balance indicator [RFC8012]
3-0 Unassigned
IANA has created and now maintains a registry entitled "Multipath Types".
IANA已经创建并维护了一个名为“多路径类型”的注册表。
The registration policy [RFC5226] for this registry is Standards Action.
此注册表的注册策略[RFC5226]是标准操作。
IANA has made the following assignments:
IANA已完成以下任务：
Value Meaning Reference
---------- ---------------------------------------- ---------
0 no multipath [RFC8029]
1 Unassigned
2 IP address [RFC8029]
3 Unassigned
4 IP address range [RFC8029]
5-7 Unassigned
8 Bit-masked IP address set [RFC8029]
9 Bit-masked label set [RFC8029]
10 IP and label set [RFC8012]
11-250 Unassigned
251-254 Reserved for Experimental Use [RFC8029]
255 Reserved [RFC8029]
Value Meaning Reference
---------- ---------------------------------------- ---------
0 no multipath [RFC8029]
1 Unassigned
2 IP address [RFC8029]
3 Unassigned
4 IP address range [RFC8029]
5-7 Unassigned
8 Bit-masked IP address set [RFC8029]
9 Bit-masked label set [RFC8029]
10 IP and label set [RFC8012]
11-250 Unassigned
251-254 Reserved for Experimental Use [RFC8029]
255 Reserved [RFC8029]
IANA has created and now maintains a registry entitled "Pad Types".
IANA已经创建并维护了一个名为“焊盘类型”的注册表。
The registration policy [RFC5226] for this registry is Standards Action.
此注册表的注册策略[RFC5226]是标准操作。
IANA has made the following initial assignments:
IANA已完成以下初步任务：
Registry Name: Pad Types
注册表名称：焊盘类型
Value Meaning Reference
---------- ---------------------------------------- ---------
0 Reserved [RFC8029]
1 Drop Pad TLV from reply [RFC8029]
2 Copy Pad TLV to reply [RFC8029]
3-250 Unassigned
251-254 Experimental Use [RFC8029]
255 Reserved [RFC8029]
Value Meaning Reference
---------- ---------------------------------------- ---------
0 Reserved [RFC8029]
1 Drop Pad TLV from reply [RFC8029]
2 Copy Pad TLV to reply [RFC8029]
3-250 Unassigned
251-254 Experimental Use [RFC8029]
255 Reserved [RFC8029]
IANA has created and now maintains a registry entitled "Interface and Label Stack Address Types".
IANA已经创建并维护了一个名为“接口和标签堆栈地址类型”的注册表。
The registration policy [RFC5226] for this registry is Standards Action.
此注册表的注册策略[RFC5226]是标准操作。
IANA has made the following initial assignments:
IANA已完成以下初步任务：
Registry Name: Interface and Label Stack Address Types
注册表名称：接口和标签堆栈地址类型
Value Meaning Reference
---------- ---------------------------------------- ---------
0 Reserved [RFC8029]
1 IPv4 Numbered [RFC8029]
2 IPv4 Unnumbered [RFC8029]
3 IPv6 Numbered [RFC8029]
4 IPv6 Unnumbered [RFC8029]
5-250 Unassigned
251-254 Experimental Use [RFC8029]
255 Reserved [RFC8029]
Value Meaning Reference
---------- ---------------------------------------- ---------
0 Reserved [RFC8029]
1 IPv4 Numbered [RFC8029]
2 IPv4 Unnumbered [RFC8029]
3 IPv6 Numbered [RFC8029]
4 IPv6 Unnumbered [RFC8029]
5-250 Unassigned
251-254 Experimental Use [RFC8029]
255 Reserved [RFC8029]
IANA has updated the reference in Note 1 of the "IANA IPv4 Special-Purpose Address Registry" [IANA-SPECIAL-IPv4] to point to this document.
IANA已更新了“IANA IPv4专用地址注册表”[IANA-Special-IPv4]注释1中的参考，以指向本文档。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<http://www.rfc-editor.org/info/rfc1122>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <http://www.rfc-editor.org/info/rfc1812>.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，DOI 10.17487/RFC1812，1995年6月<http://www.rfc-editor.org/info/rfc1812>.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, DOI 10.17487/RFC2113, February 1997, <http://www.rfc-editor.org/info/rfc2113>.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 2113，DOI 10.17487/RFC2113，1997年2月<http://www.rfc-editor.org/info/rfc2113>.
[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>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <http://www.rfc-editor.org/info/rfc3032>.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，DOI 10.17487/RFC3032，2001年1月<http://www.rfc-editor.org/info/rfc3032>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<http://www.rfc-editor.org/info/rfc4271>.
[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>.
[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>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[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>.
[RFC7506] Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April 2015, <http://www.rfc-editor.org/info/rfc7506>.
[RFC7506]Raza，K.，Akiya，N.，和C.Pignataro，“MPLS操作、管理和维护（OAM）的IPv6路由器警报选项”，RFC 7506，DOI 10.17487/RFC7506，2015年4月<http://www.rfc-editor.org/info/rfc7506>.
[Err108] RFC Errata, Erratum ID 108, RFC 4379.
[Err108]RFC勘误表，勘误表ID 108，RFC 4379。
[Err742] RFC Errata, Erratum ID 742, RFC 4379.
[Err742]RFC勘误表，勘误表ID 742，RFC 4379。
[Err1418] RFC Errata, Erratum ID 1418, RFC 4379.
[Err1418]RFC勘误表，勘误表ID 1418，RFC 4379。
[Err1714] RFC Errata, Erratum ID 1714, RFC 4379.
[Err1714]RFC勘误表，勘误表ID 1714，RFC 4379。
[Err1786] RFC Errata, Erratum ID 1786, RFC 4379.
[Err1786]RFC勘误表，勘误表ID 1786，RFC 4379。
[Err2978] RFC Errata, Erratum ID 2978, RFC 4379.
[Err2978]RFC勘误表，勘误表ID 2978，RFC 4379。
[Err3399] RFC Errata, Erratum ID 3399, RFC 4379.
[Err3399]RFC勘误表，勘误表ID 3399，RFC 4379。
[IANA-ENT] IANA, "PRIVATE ENTERPRISE NUMBERS", <http://www.iana.org/assignments/enterprise-numbers>.
[IANA-ENT]IANA，“私营企业编号”<http://www.iana.org/assignments/enterprise-numbers>.
[IANA-MPLS-LSP-PING] IANA, "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", <http://www.iana.org/assignments/ mpls-lsp-ping-parameters>.
[IANA-MPLS-LSP-PING]IANA，“多协议标签交换（MPLS）标签交换路径（LSP）PING参数”<http://www.iana.org/assignments/ mpls lsp ping参数>。
[IANA-SPECIAL-IPv4] IANA, "IANA IPv4 Special-Purpose Address Registry", <http://www.iana.org/assignments/ iana-ipv4-special-registry>.
[IANA-SPECIAL-IPv4]IANA，“IANA IPv4专用地址注册表”<http://www.iana.org/assignments/ iana-ipv4-special-registry>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，DOI 10.17487/RFC0792，1981年9月<http://www.rfc-editor.org/info/rfc792>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, <http://www.rfc-editor.org/info/rfc3107>.
[RFC3107]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，DOI 10.17487/RFC3107，2001年5月<http://www.rfc-editor.org/info/rfc3107>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <http://www.rfc-editor.org/info/rfc3443>.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，DOI 10.17487/RFC3443，2003年1月<http://www.rfc-editor.org/info/rfc3443>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <http://www.rfc-editor.org/info/rfc4026>.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，DOI 10.17487/RFC4026，2005年3月<http://www.rfc-editor.org/info/rfc4026>.
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, DOI 10.17487/RFC4365, February 2006, <http://www.rfc-editor.org/info/rfc4365>.
[RFC4365]Rosen，E.“BGP/MPLS IP虚拟专用网络（VPN）的适用性声明”，RFC 4365，DOI 10.17487/RFC4365，2006年2月<http://www.rfc-editor.org/info/rfc4365>.
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, <http://www.rfc-editor.org/info/rfc4461>.
[RFC4461]Yasukawa，S.，Ed.“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，DOI 10.17487/RFC4461，2006年4月<http://www.rfc-editor.org/info/rfc4461>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4761]Kompella，K.，Ed.和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，DOI 10.17487/RFC4761，2007年1月<http://www.rfc-editor.org/info/rfc4761>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085]Nadeau，T.，Ed.和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，DOI 10.17487/RFC5085，2007年12月<http://www.rfc-editor.org/info/rfc5085>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <http://www.rfc-editor.org/info/rfc5331>.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 5331，DOI 10.17487/RFC5331，2008年8月<http://www.rfc-editor.org/info/rfc5331>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <http://www.rfc-editor.org/info/rfc5462>.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，DOI 10.17487/RFC5462，2009年2月<http://www.rfc-editor.org/info/rfc5462>.
[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, <http://www.rfc-editor.org/info/rfc5885>.
[RFC5885]Nadeau，T.，Ed.和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，RFC 5885，DOI 10.17487/RFC5885，2010年6月<http://www.rfc-editor.org/info/rfc5885>.
[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>.
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, DOI 10.17487/RFC6829, January 2013, <http://www.rfc-editor.org/info/rfc6829>.
[RFC6829]Chen，M.，Pan，P.，Pignataro，C.，和R.Asati，“IPv6上广告的伪线转发等价类（FEC）的标签交换路径（LSP）Ping”，RFC 6829，DOI 10.17487/RFC6829，2013年1月<http://www.rfc-editor.org/info/rfc6829>.
[RFC7537] Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and S. Aldrin, "IANA Registries for LSP Ping Code Points", RFC 7537, DOI 10.17487/RFC7537, May 2015, <http://www.rfc-editor.org/info/rfc7537>.
[RFC7537]Decraene，B.，Akiya，N.，Pignataro，C.，Andersson，L.，和S.Aldrin，“LSP Ping代码点的IANA注册”，RFC 7537，DOI 10.17487/RFC7537，2015年5月<http://www.rfc-editor.org/info/rfc7537>.
[RFC8012] Akiya, N., Swallow, G., Pignataro, C., Malis, A., and S. Aldrin, "Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs)", RFC 8012, DOI 10.17487/RFC8012, November 2016, <http://www.rfc-editor.org/info/rfc8012>.
[RFC8012]Akiya，N.，Swallow，G.，Pignataro，C.，Malis，A.，和S.Aldrin，“使用熵标签（ELs）在MPLS网络上标记交换路径（LSP）和伪线（PW）Ping/Trace”，RFC 8012，DOI 10.17487/RFC8012，2016年11月<http://www.rfc-editor.org/info/rfc8012>.
[RFC8077] Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <http://www.rfc-editor.org/info/rfc8077>.
[RFC8077]Martini，L.，Ed.，和G.Heron，Ed.，“使用标签分发协议（LDP）的伪线设置和维护”，STD 84，RFC 8077，DOI 10.17487/RFC8077，2017年2月<http://www.rfc-editor.org/info/rfc8077>.
Appendix A. Deprecated TLVs and Sub-TLVs (Non-normative)
附录A.不推荐的TLV和子TLV（非规范性）
This appendix describes deprecated elements, which are non-normative for an implementation. They are included in this document for historical and informational purposes.
本附录描述了不推荐使用的元素，这些元素对于实现来说是非规范性的。出于历史和信息目的，本文件中包含了这些信息。
FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 32-bit connection ID. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below termed encapsulation type with the high-order bit set to zero. Both of these fields are treated in this protocol as opaque values.
[RFC4447]中定义了FEC 128（0x80），术语PW ID（伪线ID）和PW类型（伪线类型）也是如此。PW ID是一个非零的32位连接ID。PW类型是一个指示封装类型的15位数字。它在下面名为封装类型的字段中右对齐，高阶位设置为零。在本协议中，这两个字段都被视为不透明值。
When a FEC 128 is encoded in a label stack, the following format is used. The Value field consists of the Remote PE IPv4 Address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows:
当FEC 128在标签堆栈中编码时，使用以下格式。值字段由远程PE IPv4地址（目标LDP会话的目标地址）、PW 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This FEC is deprecated and is retained only for backward compatibility. Implementations of LSP ping SHOULD accept and process this TLV, but SHOULD send LSP ping echo requests with the new TLV (see Section 3.2.9), unless explicitly configured to use the old TLV.
此FEC已弃用，仅为向后兼容而保留。LSP ping的实现应接受并处理此TLV，但应使用新TLV发送LSP ping回显请求（见第3.2.9节），除非明确配置为使用旧TLV。
An LSR receiving this TLV SHOULD use the source IP address of the LSP echo request to infer the sender's PE address.
接收此TLV的LSR应使用LSP回显请求的源IP地址来推断发送方的PE地址。
The Downstream Mapping object is a TLV that MAY be included in an echo request message. Only one Downstream Mapping object may appear in an echo request. The presence of a Downstream Mapping object is a request that Downstream Mapping objects be included in the echo reply. If the replying router is the destination of the FEC, then a Downstream Mapping TLV SHOULD NOT be included in the echo reply.
下游映射对象是可能包含在回显请求消息中的TLV。回送请求中只能出现一个下游映射对象。下游映射对象的存在是请求在回送应答中包括下游映射对象。如果应答路由器是FEC的目的地，则回送应答中不应包括下游映射TLV。
Otherwise, the replying router SHOULD include a Downstream Mapping object for each interface over which this FEC could be forwarded. For a more precise definition of the notion of "downstream", see Section 3.4.2, "Downstream Router and Interface".
否则，应答路由器应包括每个接口的下游映射对象，该FEC可通过该接口转发。有关“下游”概念的更精确定义，请参见第3.4.2节“下游路由器和接口”。
The Length is K + M + 4*N octets, where M is the Multipath Length, and N is the number of downstream labels. Values for K are found in the description of Address Type below. The Value field of a Downstream Mapping has the following format:
长度为K+M+4*N个八位字节，其中M是多路径长度，N是下游标签的数量。在下面的地址类型描述中可以找到K的值。下游映射的值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Maximum Transmission Unit (MTU)
最大传输单位（MTU）
The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the interface to the downstream LSR.
MTU是适合下游LSR接口的最大MPLS帧（包括标签堆栈）的大小（以八位字节为单位）。
Address Type
地址类型
The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the Downstream IP Address and Downstream Interface fields. The resulting total for the initial part of the TLV is listed in the table below as "K Octets". The Address Type is set to one of the following values:
地址类型指示接口是否已编号。它还确定下游IP地址和下游接口字段的长度。下表中列出了TLV初始部分的总结果，即“K八位字节”。地址类型设置为以下值之一：
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
5 Non IP 12
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
5 Non IP 12
DS Flags
DS标志
The DS Flags field is a bit vector with the following format:
DS标志字段是具有以下格式的位向量：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
Two flags are defined currently, I and N. The remaining flags MUST be set to zero when sending and ignored on receipt.
当前定义了两个标志：I和N。发送时必须将其余标志设置为零，并在接收时忽略。
Flag Name and Meaning
---- ----------------
I Interface and Label Stack Object Request
Flag Name and Meaning
---- ----------------
I Interface and Label Stack Object Request
When this flag is set, it indicates that the replying router SHOULD include an Interface and Label Stack Object in the echo reply message.
设置此标志时，表示应答路由器应在回送应答消息中包含接口和标签堆栈对象。
N Treat as a Non-IP Packet
N将其视为非IP数据包
Echo request messages will be used to diagnose non-IP flows. However, these messages are carried in IP packets. For a router that alters its ECMP algorithm based on the FEC or deep packet examination, this flag requests that the router treat this as it would if the determination of an IP payload had failed.
回显请求消息将用于诊断非IP流。但是，这些消息是在IP数据包中传输的。对于根据FEC或深度数据包检查改变其ECMP算法的路由器，该标志请求路由器将其视为IP有效负载确定失败时的处理方式。
Downstream IP Address and Downstream Interface Address
下游IP地址和下游接口地址
IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets.
IPv4地址和接口索引以4个八位字节编码；IPv6地址编码为16个八位字节。
If the interface to the downstream LSR is numbered, then the Address Type MUST be set to IPv4 or IPv6, the Downstream IP Address MUST be set to either the downstream LSR's Router ID or the interface address of the downstream LSR, and the Downstream Interface Address MUST be set to the downstream LSR's interface address.
如果下游LSR的接口已编号，则地址类型必须设置为IPv4或IPv6，下游IP地址必须设置为下游LSR的路由器ID或下游LSR的接口地址，并且下游接口地址必须设置为下游LSR的接口地址。
If the interface to the downstream LSR is unnumbered, the Address Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP Address MUST be the downstream LSR's Router ID, and the Downstream Interface Address MUST be set to the index assigned by the upstream LSR to the interface.
如果与下游LSR的接口未编号，则地址类型必须为IPv4未编号或IPv6未编号，下游IP地址必须是下游LSR的路由器ID，并且下游接口地址必须设置为上游LSR分配给接口的索引。
If an LSR does not know the IP address of its neighbor, then it MUST set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it must set the Downstream IP Address to 127.0.0.1; for IPv6, the address is set to 0::1. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with either of these addresses in the Downstream IP Address field, this indicates that it MUST bypass interface verification but continue with label validation.
如果LSR不知道其邻居的IP地址，则必须将地址类型设置为IPv4未编号或IPv6未编号。对于IPv4，必须将下行IP地址设置为127.0.0.1；对于IPv6，地址设置为0:：1。在这两种情况下，接口索引都必须设置为0。如果LSR在下游IP地址字段中接收到带有这些地址之一的回显请求数据包，这表明它必须绕过接口验证，但继续标签验证。
If the originator of an echo request packet wishes to obtain Downstream Mapping information but does not know the expected label stack, then it SHOULD set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the Downstream IP Address to 224.0.0.2; for IPv6, the address MUST be set to FF02::2. In both cases, the interface index MUST be set to 0. If an LSR receives an echo request packet with the all-routers multicast address, then this indicates that it MUST bypass both interface and label stack validation, but return Downstream Mapping TLVs using the information provided.
如果echo请求数据包的发起人希望获得下游映射信息，但不知道预期的标签堆栈，则应将地址类型设置为IPv4未编号或IPv6未编号。对于IPv4，必须将下行IP地址设置为224.0.0.2；对于IPv6，地址必须设置为FF02:：2。在这两种情况下，接口索引都必须设置为0。若LSR接收到一个带有所有路由器多播地址的echo请求包，那个么这表明它必须绕过接口和标签堆栈验证，但使用提供的信息返回下游映射TLV。
Multipath Type
多路径类型
The following Multipath Types are defined:
定义了以下多路径类型：
Key Type Multipath Information
--- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0)
2 IP address IP addresses
4 IP address range low/high address pairs
8 Bit-masked IP IP address prefix and bit mask
address set
9 Bit-masked label set Label prefix and bit mask
Key Type Multipath Information
--- ---------------- ---------------------
0 no multipath Empty (Multipath Length = 0)
2 IP address IP addresses
4 IP address range low/high address pairs
8 Bit-masked IP IP address prefix and bit mask
address set
9 Bit-masked label set Label prefix and bit mask
Type 0 indicates that all packets will be forwarded out this one interface.
类型0表示所有数据包都将转发到此接口。
Types 2, 4, 8, and 9 specify that the supplied Multipath Information will serve to exercise this path.
类型2、4、8和9指定提供的多路径信息将用于执行此路径。
Depth Limit
深度限制
The Depth Limit is applicable only to a label stack and is the maximum number of labels considered in the hash; this SHOULD be set to zero if unspecified or unlimited.
深度限制仅适用于标签堆栈，是哈希中考虑的最大标签数；如果未指定或无限制，则应将其设置为零。
Multipath Length
多径长度
The length in octets of the Multipath Information.
多路径信息的长度（以八位字节为单位）。
Multipath Information
多路径信息
Address or label values encoded according to the Multipath Type. See Section 3.4.1.1.1 for encoding details.
根据多路径类型编码的地址或标签值。编码详情见第3.4.1.1.1节。
Downstream Label(s)
下游标签
The set of labels in the label stack as it would have appeared if this router were forwarding the packet through this interface. Any Implicit Null labels are explicitly included. Labels are treated as numbers, i.e., they are right justified in the field.
标签堆栈中的标签集，如果此路由器通过此接口转发数据包，则会显示该标签集。任何隐式空标签都会显式包含。标签被视为数字，即它们在字段中右对齐。
A downstream label is 24 bits, in the same format as an MPLS label minus the TTL field, i.e., the MSBit of the label is bit 0, the LSBit is bit 19, the TC bits are bits 20-22, and bit 23 is the S bit. The replying router SHOULD fill in the TC and S bits; the LSR receiving the echo reply MAY choose to ignore these bits.
下游标签为24位，格式与MPLS标签减去TTL字段相同，即标签的MSBit为位0，LSBit为位19，TC位为位20-22，位23为S位。应答路由器应填写TC和S位；接收回音应答的LSR可以选择忽略这些位。
Protocol
协议
The protocol is taken from the following table:
协议取自下表：
Protocol # Signaling Protocol
---------- ------------------
0 Unknown
1 Static
2 BGP
3 LDP
4 RSVP-TE
Protocol # Signaling Protocol
---------- ------------------
0 Unknown
1 Static
2 BGP
3 LDP
4 RSVP-TE
Acknowledgements
致谢
The original acknowledgements from RFC 4379 state the following:
RFC 4379的原始确认声明如下：
This document is the outcome of many discussions among many people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal, and Vanson Lim.
本文件是许多人讨论的结果，包括Manoj Leelanivas、Paul Traina、Yakov Rekhter、Der Hwa Gan、Brook Bailey、Eric Rosen、Ina Minei、Shivani Aggarwal和Vanson Lim。
The description of the Multipath Information sub-field of the Downstream Mapping TLV was adapted from text suggested by Curtis Villamizar.
下游映射TLV的多路径信息子字段的描述改编自Curtis Villamizar建议的文本。
We would like to thank Loa Andersson for motivating the advancement of this specification.
我们要感谢Loa Andersson推动本规范的发展。
We also would like to thank Alexander Vainshtein, Yimin Shen, Curtis Villamizar, David Allan, Vincent Roca, Mirja Kuhlewind, and Elwyn Davies for their review and useful comments.
我们还要感谢Alexander Vainstein、Shen Yimin、Curtis Villamizar、David Allan、Vincent Roca、Mirja Kuhlewind和Elwyn Davies的评论和有用的评论。
Contributors
贡献者
A mechanism used to detect data-plane failures in MPLS LSPs was originally published as RFC 4379 in February 2006. It was produced by the MPLS Working Group of the IETF and was jointly authored by Kireeti Kompella and George Swallow.
用于检测MPLS LSP中数据平面故障的机制最初于2006年2月发布为RFC 4379。它由IETF的MPLS工作组制作，由Kireeti Kompella和George Swallow联合撰写。
The following made vital contributions to all aspects of the original RFC 4379, and much of the material came out of debate and discussion among this group.
以下内容对原始RFC 4379的各个方面都做出了重要贡献，其中许多材料来自于该小组的辩论和讨论。
Ronald P. Bonica, Juniper Networks, Inc. Dave Cooper, Global Crossing Ping Pan, Hammerhead Systems Nischal Sheth, Juniper Networks, Inc. Sanjay Wadhwa, Juniper Networks, Inc.
Ronald P.Bonica，Juniper Networks，Inc.Dave Cooper，Global Crossing Ping Pan，Hammerhead Systems Nischal Sheth，Juniper Networks，Inc.Sanjay Wadhwa，Juniper Networks，Inc.公司。
Authors' Addresses
作者地址
Kireeti Kompella Juniper Networks, Inc.
Kireeti Kompella Juniper网络公司。
Email: kireeti.kompella@gmail.com
Email: kireeti.kompella@gmail.com
George Swallow Cisco Systems, Inc.
乔治·斯沃诺思科系统公司。
Email: swallow.ietf@gmail.com
Email: swallow.ietf@gmail.com
Carlos Pignataro (editor) Cisco Systems, Inc.
卡洛斯·皮格纳塔罗（编辑）思科系统公司。
Email: cpignata@cisco.com
Email: cpignata@cisco.com
Nagendra Kumar Cisco Systems, Inc.
纳贡德拉·库马尔思科系统公司。
Email: naikumar@cisco.com
Email: naikumar@cisco.com
Sam Aldrin Google
山姆·奥尔德林谷歌
Email: aldrin.ietf@gmail.com
Email: aldrin.ietf@gmail.com
Mach(Guoyi) Chen Huawei
马赫（国一）陈华为
Email: mach.chen@huawei.com
Email: mach.chen@huawei.com