Network Working Group K. Kompella
Request for Comments: 4379 Juniper Networks, Inc.
Updates: 1122 G. Swallow
Category: Standards Track Cisco Systems, Inc.
February 2006
Network Working Group K. Kompella
Request for Comments: 4379 Juniper Networks, Inc.
Updates: 1122 G. Swallow
Category: Standards Track Cisco Systems, Inc.
February 2006
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
检测多协议标签交换（MPLS）数据平面故障
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply.
本文档描述了一种简单有效的机制，可用于检测多协议标签交换（MPLS）标签交换路径（LSP）中的数据平面故障。本文档分为两部分：MPLS“echo request”和“echo reply”中包含的用于故障检测和隔离的信息，以及可靠发送echo reply的机制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions ................................................3
1.2. Structure of This Document .................................3
1.3. Contributors ...............................................3
2. Motivation ......................................................4
2.1. Use of Address Range 127/8 .................................4
3. Packet Format ...................................................6
3.1. Return Codes ..............................................10
3.2. Target FEC Stack ..........................................11
3.2.1. LDP IPv4 Prefix ....................................12
3.2.2. LDP IPv6 Prefix ....................................13
3.2.3. RSVP IPv4 LSP ......................................13
3.2.4. RSVP IPv6 LSP ......................................14
3.2.5. VPN IPv4 Prefix ....................................14
3.2.6. VPN IPv6 Prefix ....................................15
3.2.7. L2 VPN Endpoint ....................................16
1. Introduction ....................................................2
1.1. Conventions ................................................3
1.2. Structure of This Document .................................3
1.3. Contributors ...............................................3
2. Motivation ......................................................4
2.1. Use of Address Range 127/8 .................................4
3. Packet Format ...................................................6
3.1. Return Codes ..............................................10
3.2. Target FEC Stack ..........................................11
3.2.1. LDP IPv4 Prefix ....................................12
3.2.2. LDP IPv6 Prefix ....................................13
3.2.3. RSVP IPv4 LSP ......................................13
3.2.4. RSVP IPv6 LSP ......................................14
3.2.5. VPN IPv4 Prefix ....................................14
3.2.6. VPN IPv6 Prefix ....................................15
3.2.7. L2 VPN Endpoint ....................................16
3.2.8. FEC 128 Pseudowire (Deprecated) ....................16
3.2.9. FEC 128 Pseudowire (Current) .......................17
3.2.10. FEC 129 Pseudowire ................................18
3.2.11. BGP Labeled IPv4 Prefix ...........................19
3.2.12. BGP Labeled IPv6 Prefix ...........................20
3.2.13. Generic IPv4 Prefix ...............................20
3.2.14. Generic IPv6 Prefix ...............................21
3.2.15. Nil FEC ...........................................21
3.3. Downstream Mapping ........................................22
3.3.1. Multipath Information Encoding .....................26
3.3.2. Downstream Router and Interface ....................28
3.4. Pad TLV ...................................................29
3.5. Vendor Enterprise Number ..................................29
3.6. Interface and Label Stack .................................29
3.7. Errored TLVs ..............................................31
3.8. Reply TOS Byte TLV ........................................31
4. Theory of Operation ............................................32
4.1. Dealing with Equal-Cost Multi-Path (ECMP) .................32
4.2. Testing LSPs That Are Used to Carry MPLS Payloads .........33
4.3. Sending an MPLS Echo Request ..............................33
4.4. Receiving an MPLS Echo Request ............................34
4.4.1. FEC Validation .....................................40
4.5. Sending an MPLS Echo Reply ................................41
4.6. Receiving an MPLS Echo Reply ..............................42
4.7. Issue with VPN IPv4 and IPv6 Prefixes .....................42
4.8. Non-compliant Routers .....................................43
5. References .....................................................43
5.1. Normative References ......................................43
5.2. Informative References ....................................44
6. Security Considerations ........................................44
7. IANA Considerations ............................................46
7.1. Message Types, Reply Modes, Return Codes ..................46
7.2. TLVs ......................................................47
8. Acknowledgements ...............................................48
3.2.8. FEC 128 Pseudowire (Deprecated) ....................16
3.2.9. FEC 128 Pseudowire (Current) .......................17
3.2.10. FEC 129 Pseudowire ................................18
3.2.11. BGP Labeled IPv4 Prefix ...........................19
3.2.12. BGP Labeled IPv6 Prefix ...........................20
3.2.13. Generic IPv4 Prefix ...............................20
3.2.14. Generic IPv6 Prefix ...............................21
3.2.15. Nil FEC ...........................................21
3.3. Downstream Mapping ........................................22
3.3.1. Multipath Information Encoding .....................26
3.3.2. Downstream Router and Interface ....................28
3.4. Pad TLV ...................................................29
3.5. Vendor Enterprise Number ..................................29
3.6. Interface and Label Stack .................................29
3.7. Errored TLVs ..............................................31
3.8. Reply TOS Byte TLV ........................................31
4. Theory of Operation ............................................32
4.1. Dealing with Equal-Cost Multi-Path (ECMP) .................32
4.2. Testing LSPs That Are Used to Carry MPLS Payloads .........33
4.3. Sending an MPLS Echo Request ..............................33
4.4. Receiving an MPLS Echo Request ............................34
4.4.1. FEC Validation .....................................40
4.5. Sending an MPLS Echo Reply ................................41
4.6. Receiving an MPLS Echo Reply ..............................42
4.7. Issue with VPN IPv4 and IPv6 Prefixes .....................42
4.8. Non-compliant Routers .....................................43
5. References .....................................................43
5.1. Normative References ......................................43
5.2. Informative References ....................................44
6. Security Considerations ........................................44
7. IANA Considerations ............................................46
7.1. Message Types, Reply Modes, Return Codes ..................46
7.2. TLVs ......................................................47
8. Acknowledgements ...............................................48
This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply", and mechanisms for transporting the echo reply. The first part aims at providing enough information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. The second part suggests two methods of reliable reply channels for the echo request message for more robust fault isolation.
本文档描述了一种简单有效的机制，可用于检测MPLS标签交换路径（LSP）中的数据平面故障。本文档分为两部分：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 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节讨论了这一变化的动机和这一特殊用途的细节。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
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 first; the document is structured the way it is to avoid forward references.
本备忘录正文包含四个主要部分：动机、MPLS回送请求/回复数据包格式、LSP ping操作和可靠的返回路径。建议初次阅读的读者跳过实际的数据包格式，先阅读操作原理；文档的结构是避免转发引用的。
The following made vital contributions to all aspects of this document, and much of the material came out of debate and discussion among this group.
以下内容对本文件的所有方面都作出了重要贡献，其中许多材料来自该小组的辩论和讨论。
Ronald P. Bonica, Juniper Networks, Inc. Dave Cooper, Global Crossing Ping Pan, Hammerhead Systems
Ronald P.Bonica，Juniper Networks，Inc.Dave Cooper，环球交叉平盘，锤头系统
Nischal Sheth, Juniper Networks, Inc. Sanjay Wadhwa, Juniper Networks, Inc.
Nischal Sheth，Juniper Networks，Inc.Sanjay Wadhwa，Juniper Networks，Inc。
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 [ICMP]) 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[ICMP]）用于连接检查，traceroute用于逐跳故障定位以及路径跟踪。本文档指定了用于测试MPLS LSP的“ping”模式和“traceroute”模式。
The basic idea is to verify that packets that belong to a particular Forwarding Equivalence Class (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 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）的数据包实际上在标签交换路由器（LSR）上结束其MPLS路径，该路由器是该FEC的出口。本文件建议通过沿着与属于该FEC的其他数据包相同的数据路径发送数据包（称为“MPLS回送请求”）来执行该测试。MPLS回显请求还携带有关正在验证其MPLS路径的FEC的信息。该回显请求与属于该FEC的任何其他数据包一样被转发。在“ping”模式（基本连接性检查）下，分组应该到达路径的末端，在该点它被发送到出口LSR的控制平面，然后该控制平面验证它是否确实是FEC的出口。在“跟踪路由”模式（故障隔离）下，数据包被发送到每个传输LSR的控制平面，该控制平面执行各种检查，以确定它确实是该路径的传输LSR；此LSR还返回有助于对照数据平面检查控制平面的进一步信息，即转发匹配路由协议确定的路径。
One way these tools can be used is to periodically ping an 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
如上所述，LSP ping旨在作为一种诊断工具。它旨在使基于MPLS的服务提供商能够隔离网络故障。特别是，LSP ping需要诊断情况
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.
其中控制平面和数据平面不同步。它通过仅基于其标签堆栈路由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 multi-path (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 newly designated IPv4 link local addresses. Use of the private address space was deemed ineffective since the leading MPLS-based service is an IPv4 Virtual Private Network (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. Furthermore, the IPv4 link local address range has only recently been allocated. Many deployed routers 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 as IPv4- mapped IPv6 addresses for IPv6 was chosen for a number of reasons.
选择IPv4的127/8范围，以及与IPv6的IPv4映射IPv6地址相同的嵌入范围，原因有很多。
RFC 1122 allocates the 127/8 as "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
RFC 1122将127/8分配为“内部主机环回地址”，并声明：“此形式的地址不得出现在主机外部。”因此，主机的默认行为是丢弃此类数据包。这
helps to ensure that if a diagnostic packet is misdirected to a host, it will be silently discarded.
有助于确保如果诊断数据包被错误地定向到主机，它将被悄悄地丢弃。
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 provides an easy means of identifying possible LSP packets.
127/8地址范围提供16M地址，允许在不同的地址中灵活地使用ECMP路径。最后，作为一种实现优化，127/8提供了一种识别可能的LSP分组的简单方法。
An MPLS echo request 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 (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One flag is defined for now, the V bit; the rest MUST be set to zero when sending and ignored on receipt.
现在定义了一个标志，即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 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
回复模式字段中有1（不回复）的MPLS回送请求可用于单向连接测试；接收路由器可以记录序列号中的间隔和/或保持延迟/抖动统计。MPLS回送请求的回复模式字段中通常有2个（通过IPv4/IPv6 UDP数据包进行回复）。如果认为正常的IP返回路径不可靠，可以使用3（通过带有路由器警报的IPv4/IPv6 UDP数据包进行回复）。注意，这要求所有中间路由器理解并知道如何转发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.
回音回复。回送回复使用与接收到的回送请求相同的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) [VCCV]. 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 codepoint is application specific and thus beyond the scope of this document.
一些应用程序支持IP控制通道。其中一个示例是在虚拟电路连接验证（VCCV）[VCCV]中定义的相关控制信道。任何支持其控制实体之间的IP控制通道的应用程序都可以将应答模式设置为4（通过应用程序级控制通道进行应答），以确保应答使用相同的通道。此代码点的进一步定义是特定于应用程序的，因此超出了本文档的范围。
Return Codes and Subcodes are described in the next section.
返回代码和子代码将在下一节中介绍。
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 (in seconds and microseconds, according to the sender's clock) in NTP format [NTP] 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 NTP format that the corresponding echo request was received.
发送的时间戳是发送MPLS回显请求时以NTP格式[NTP]表示的时间（根据发送方的时钟，以秒和微秒为单位）。回送回复中接收的时间戳是收到相应回送请求的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 follow. The Label Distribution Protocol (LDP) IPv4 FEC sub-TLV has the following format:
下面是两个例子。标签分发协议（LDP）IPv4 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 (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 = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
3 Pad
4 Not Assigned
5 Vendor Enterprise Number
6 Not Assigned
7 Interface and Label Stack
8 Not Assigned
9 Errored TLVs
10 Reply TOS Byte
Type # Value Field
------ -----------
1 Target FEC Stack
2 Downstream Mapping
3 Pad
4 Not Assigned
5 Vendor Enterprise Number
6 Not Assigned
7 Interface and Label Stack
8 Not Assigned
9 Errored TLVs
10 Reply TOS Byte
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，如果实现不理解或不支持它们，则应忽略它们。
The Return Code is set to zero by the sender. The receiver can set it to one of the values listed below. 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
----- -------
Value Meaning
----- -------
0 No return code
0没有返回代码
1 Malformed echo request received
收到1个格式不正确的回显请求
2 One or more of the TLVs was not understood
2一个或多个TLV未被理解
3 Replying router is an egress for the FEC at stack-depth <RSC>
3应答路由器是FEC在堆栈深度的出口<RSC>
4 Replying router has no mapping for the FEC at stack-depth <RSC>
4应答路由器在堆栈深度没有FEC的映射<RSC>
5 Downstream Mapping Mismatch (See Note 1)
5下游映射不匹配（见注1）
6 Upstream Interface Index Unknown (See Note 1)
6上游接口指数未知（见注1）
7 Reserved
7保留
8 Label switched at stack-depth <RSC>
8标签在堆栈深度切换<RSC>
9 Label switched but no MPLS forwarding at stack-depth <RSC>
9标签交换，但在堆栈深度没有MPLS转发<RSC>
10 Mapping for this FEC is not the given label at stack-depth <RSC>
10此FEC的映射不是堆栈深度处的给定标签<RSC>
11 No label entry at stack-depth <RSC>
11堆叠深度<RSC>
12 Protocol not associated with interface at FEC stack-depth <RSC>
12协议与FEC堆栈深度处的接口不关联<RSC>
13 Premature termination of ping due to label stack shrinking to a single label
13由于标签堆栈收缩为单个标签，ping提前终止
Note 1
附注1
The Return Subcode contains the point in the label stack where processing was terminated. If the RSC is 0, no labels were processed. Otherwise the packet would have been label switched at depth RSC.
返回子代码包含标签堆栈中终止处理的点。如果RSC为0，则未处理任何标签。否则，数据包将在深度RSC进行标签交换。
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 Not Assigned
6 13 VPN IPv4 prefix
7 25 VPN IPv6 prefix
8 14 L2 VPN endpoint
9 10 "FEC 128" Pseudowire (deprecated)
10 14 "FEC 128" Pseudowire
11 16+ "FEC 129" Pseudowire
12 5 BGP labeled IPv4 prefix
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 Not Assigned
6 13 VPN IPv4 prefix
7 25 VPN IPv6 prefix
8 14 L2 VPN endpoint
9 10 "FEC 128" Pseudowire (deprecated)
10 14 "FEC 128" Pseudowire
11 16+ "FEC 129" Pseudowire
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
13 17 BGP标记的IPv6前缀14 5通用IPv4前缀15 17通用IPv6前缀16 4 Nil FEC
Other FEC Types 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 [LDP] for 192.168.1.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 an FEC Stack TLV with one FEC in it, namely, of type LDP IPv4 prefix, with prefix 192.168.1.1/32, and send the echo request with a label of 1001.
MPLS回送请求必须有一个描述正在测试的FEC堆栈的目标FEC堆栈。例如，如果LSR X具有用于192.168.1.1（例如，标签1001）的LDP映射[LDP]，则为了验证标签1001确实到达通过LDP宣布该前缀的出口LSR，X可以发送带有FEC堆栈TLV的MPLS回显请求，其中包含一个FEC，即LDP IPv4前缀类型，前缀为192.168.1.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 10/8 in VPN foo. Say further that LSR Y with loopback address 192.168.1.1 announced prefix 10/8 with Route Distinguisher RD-foo-Y (which may in general be different from the Route Distinguisher that LSR X uses in its own advertisements for VPN foo), label 23456 and BGP next hop 192.168.1.1 [BGP]. Finally, suppose that LSR X receives a label binding of 1001 for 192.168.1.1 via LDP. X has two choices in sending an MPLS echo request: X can send an MPLS echo request with an FEC Stack TLV with a single FEC of type VPN IPv4 prefix with a prefix of 10/8 and a Route Distinguisher of RD-foo-Y. Alternatively, X can send an FEC Stack TLV with two FECs, the first of type LDP IPv4 with a prefix of 192.168.1.1/32 and the second of type of IP VPN with a prefix 10/8 with Route Distinguisher 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.)
假设LSR X想要验证<100123456>的标签堆栈是否是用于访问VPN IPv4前缀的正确标签堆栈[请参阅VPN foo中10/8的第3.2.5节]。进一步说，环回地址为192.168.1.1的LSR Y宣布了前缀10/8和路由识别器RD-foo-Y（通常可能不同于LSR X在其自己的VPN foo广告中使用的路由识别器）、标签23456和BGP下一跳192.168.1.1[BGP]。最后，假设LSR X通过LDP接收到192.168.1.1的标签绑定1001。X在发送MPLS回显请求时有两种选择：X可以发送带有FEC堆栈TLV的MPLS回显请求，其中FEC类型为VPN IPv4前缀，前缀为10/8，路由标识符为RD-foo-Y。或者，X可以发送带有两个FEC的FEC堆栈TLV，第一种类型为LDP IPv4，前缀为192.168.1.1/32，第二种类型为IP VPN，前缀为10/8，路由标识符为RD-foo-Y。在任何一种情况下，MPLS回送请求的标签堆栈都将小于100123456>。（注意：在本例中，1001是“外部”标签，23456是“内部”标签。）
The IPv4 Prefix FEC is defined in [LDP]. 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 [LDP] for an example of a Mapping for an IPv4 FEC.
IPv4前缀FEC在[LDP]中定义。在标签堆栈中对LDP IPv4前缀进行编码时，将使用以下格式。该值由IPv4前缀的4个八位字节和前缀长度的1个八位字节（以位为单位）组成；格式如下所示。IPv4前缀按网络字节顺序排列；如果前缀短于32位，则尾随位应设置为零。有关IPv4 FEC的映射示例，请参见[LDP]。
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 [LDP]. 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 [LDP] for an example of a Mapping for an IPv6 FEC.
IPv6前缀FEC在[LDP]中定义。在标签堆栈中对LDP IPv6前缀进行编码时，将使用以下格式。该值由IPv6前缀的16个八位字节和前缀长度的1个八位字节（以位为单位）组成；格式如下所示。IPv6前缀按网络字节顺序排列；如果前缀短于128位，则尾随位应设置为零。有关IPv6 FEC的映射示例，请参见[LDP]。
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, sections 4.6.1.1 and 4.6.2.1. See [RSVP-TE].
该值的格式如下所示。值字段取自RFC 3209第4.6.1.1节和第4.6.2.1节。见[RSVP-TE]。
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 end point 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 end point 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, sections 4.6.1.2 and 4.6.2.2. See [RSVP-TE].
该值的格式如下所示。值字段取自RFC 3209第4.6.1.2节和第4.6.2.2节。见[RSVP-TE]。
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 end point 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 end point 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 [BGP-LABEL].
VPN-IPv4网络层路由信息（NLRI）在[RFC4365]中定义。本文档使用术语VPN IPv4前缀表示已在BGP中以MPLS标签发布的VPN-IPv4 NLRI。参见[BGP-LABEL]。
When a VPN IPv4 prefix is encoded in a label stack, the following format is used. The value field consists of the Route Distinguisher 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前缀播发的路由识别器、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 Route Distinguisher (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 Network Layer Routing Information (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 [BGP-LABEL].
VPN-IPv6网络层路由信息（NLRI）在[RFC4365]中定义。本文档使用术语VPN IPv6前缀表示已在BGP中以MPLS标签发布的VPN-IPv6 NLRI。参见[BGP-LABEL]。
When a VPN IPv6 prefix is encoded in a label stack, the following format is used. The value field consists of the Route Distinguisher 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前缀播发的路由识别器、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 Route Distinguisher 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.
路由识别器与VPN IPv4前缀RD相同，只是它在此处的功能是允许创建到IPv6前缀的不同路由。见第3.2.5节。将此字段与本地FEC信息匹配时，它被视为不透明值。
VPLS stands for Virtual Private LAN Service. The terms VPLS BGP NLRI and VE ID (VPLS Edge Identifier) are defined in [VPLS-BGP]. This document uses the simpler term L2 VPN endpoint when referring to a VPLS BGP NLRI. The Route Distinguisher 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 PW Type in section 3.2.8 below.
VPLS代表虚拟专用LAN服务。术语VPLS BGP NLRI和VE ID（VPLS边缘标识符）在[VPLS-BGP]中定义。本文档在提及VPLS BGP NLRI时使用了更简单的术语L2 VPN端点。路由识别器是一个8个八位组的标识符，用于区分由节点播发的各种L2 VPN的信息。VE ID是一个2-octet标识符，用于标识作为VPLS内服务连接点的特定节点。这两个标识符的结构在这里并不重要；将这些字段与本地FEC信息匹配时，它们被视为不透明值。封装类型与下面第3.2.8节中的PW类型相同。
When an L2 VPN endpoint is encoded in a label stack, the following format is used. The value field consists of a Route Distinguisher (8 octets), the sender (of the ping)'s VE ID (2 octets), the receiver's VE ID (2 octets), and an encapsulation type (2 octets), formatted as follows:
在标签堆栈中对L2 VPN端点进行编码时，将使用以下格式。值字段由路由标识符（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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC 128 (0x80) is defined in [PW-CONTROL], 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.
FEC 128（0x80）在[PW-CONTROL]中定义，术语PW ID（伪线ID）和PW类型（伪线类型）也是如此。PW ID是一个非零的32位连接ID。PW类型是一个指示封装类型的15位数字。它在下面名为封装类型的字段中右对齐，高阶位设置为零。在本协议中，这两个字段都被视为不透明值。
When an FEC 128 is encoded in a label stack, the following format is used. The value field consists of the remote PE address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows:
当在标签堆栈中编码FEC 128时，使用以下格式。值字段由远程PE地址（目标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 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 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 next section), unless explicitly configured to use the old TLV.
此FEC已弃用，仅为向后兼容而保留。LSP ping的实现应该接受并处理这个TLV，但是应该使用新的TLV发送LSP ping回显请求（参见下一节），除非明确配置为使用旧的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地址。
FEC 128 (0x80) is defined in [PW-CONTROL], 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.
FEC 128（0x80）在[PW-CONTROL]中定义，术语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 field to the local FEC information, the match MUST be exact.
在本协议中，这两个字段都被视为不透明值。将这些字段与本地FEC信息匹配时，匹配必须精确。
When an FEC 128 is encoded in a label stack, the following format is used. The value field consists of the sender's PE address (the source address of the targeted LDP session), the remote PE address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type as follows:
当在标签堆栈中编码FEC 128时，使用以下格式。值字段由发送方的PE地址（目标LDP会话的源地址）、远程PE地址（目标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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE 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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE 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 [PW-CONTROL]. 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 addresses.
FEC 129（0x81）和术语PW类型、附件组标识符（AGI）、附件组标识符类型（AGI类型）、附件个体标识符类型（AII类型）、源附件个体标识符（SAII）和目标附件个体标识符（TAII）在[PW-CONTROL]中定义。PW类型是一个15位的数字，指示封装类型。它在PW Type下面的字段中右对齐，高阶位设置为零。所有其他字段被视为不透明值，并直接从FEC 129格式复制。所有这些值一起唯一地定义由源和远程PE地址标识的LDP会话范围内的FEC。
When an 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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE 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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BGP labeled IPv4 prefixes are defined in [BGP-LABEL]. When a BGP labeled IPv4 prefix is encoded in a label stack, the following format is used. The value field consists the IPv4 prefix (with trailing 0 bits to make 32 bits in all), and the prefix length, as follows:
BGP标记的IPv4前缀在[BGP-LABEL]中定义。在标签堆栈中对标记为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 [BGP-LABEL]. 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前缀在[BGP-LABEL]中定义。在标签堆栈中对标记为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, 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 [RSVP-TE] 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[RSVP-TE]以及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字段在发送时必须为零，在接收时被忽略。
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. 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.3.2, "Downstream Router and Interface".
下游映射对象是可能包含在回显请求消息中的TLV。回送请求中只能出现一个下游映射对象。下游映射对象的存在是请求在回送应答中包括下游映射对象。如果应答路由器是FEC的目的地，则回送应答中不应包括下游映射TLV。否则，应答路由器应包括每个接口的下游映射对象，该FEC可通过该接口转发。有关“下游”概念的更精确定义，请参见第3.3.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
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
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
---- ----------------
Flag Name and Meaning
---- ----------------
I Interface and Label Stack Object Request
I接口和标签堆栈对象请求
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 the next section below for encoding details.
根据多路径类型编码的地址或标签值。有关编码详细信息，请参阅下面的下一节。
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 EXP bits are bits 20-22, and bit 23 is the S bit. The replying router SHOULD fill in the EXP and S bits; the LSR receiving the echo reply MAY choose to ignore these bits.
下游标签为24位，格式与MPLS标签减去TTL字段相同，即标签的MSBit为位0，LSBit为位19，EXP位为位20-22，位23为S位。应答路由器应填写EXP和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
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:127/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:127/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 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 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 Mappings: 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个下游映射进行响应：到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 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 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/interfaces (and their corresponding labels) for X with respect to L. Each pair of downstream router and interface requires a separate Downstream Mapping to be added to the reply.
应该解释“下游路由器”和“下游接口”的概念。考虑一个LSR X。如果一个源于TTL n＞1的包在LSR x上到达最外层标签L和TTL＝1，则X必须能够计算哪些LSR可以接收到包，如果它是源于TTL= N+ 1，在哪个接口上请求将到达，哪些LSR会看到LSR。（说明如何进行计算不在本文件的范围内。）这些LSR/接口集包括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
----- -------
1 Drop Pad TLV from reply
2 Copy Pad TLV to reply
3-255 Reserved for future use
Value Meaning
----- -------
1 Drop Pad TLV from reply
2 Copy Pad TLV to reply
3-255 Reserved for future use
SMI Private Enterprise Numbers are maintained by IANA. The Length is always 4; the value is the 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.
SMI私有企业编号由IANA维护。长度始终为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 a Downstream Mapping has the following format:
长度为K+4*N个八位组；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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
------ ------------ --------
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
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 TOS byte set to the value specified in the TLV. This TLV has a length of 4 with the following value field.
echo请求的发起人可使用此TLV请求发送echo回复，并将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 is to an egress IP address of 10.1.1.1, the FEC Stack contains a single element, namely, an LDP IPv4 prefix sub-TLV with value 10.1.1.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设置的，并且是10.1.1.1的出口IP地址，则FEC堆栈包含单个元素，即值为10.1.1.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 10.1/8 that is tunneled over an LDP LSP with egress 10.10.1.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堆栈可能更复杂。例如，您可能希望测试在出口为10.10.1.1的LDP LSP上隧道传输的VPN IPv4前缀10.1/8。然后，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 below.
当接收到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可能会有备份路径、迂回路径和其他可选路径。
To deal with the last two first: 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回显请求可以强制回显请求进入任何所需的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
为了实现备用路径的某种程度的覆盖，在选择目标IP地址和源时有一定的自由度
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 Mapping TLV. This is used as follows. An ingress LSR periodically sends an MPLS traceroute message to determine whether there are multipaths for a given LSP. If so, each hop will provide some information 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回显请求的UDP端口。这显然是不够的；在跟踪路由的情况下，通过下游映射TLV的多路径信息提供更多的纬度。其用途如下。入口LSR定期发送MPLS跟踪路由消息，以确定给定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 differentiate 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 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 IPv6 address from the range 0:0:0:0:0:FFFF:127/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 option MUST be set in the IP header.
MPLS回显请求是UDP数据包。IP报头设置如下：源IP地址是发送方的可路由地址；目标IP地址是127/8范围内的（随机选择的）IPv4地址或0:0:0:0:FFFF:127/104范围内的IPv6地址。IP TTL设置为1。源UDP端口由发送方选择；目标UDP端口设置为3503（由IANA为MPLS回显请求分配）。必须在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 [RSVP-TE]. 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的正常路线是通过交通工程隧道[RSVP-TE]，则可以应用进一步的标签。如果堆栈中的所有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
如果回显请求已标记，则可以（取决于正在ping的内容）将最内层标签的TTL设置为1，以防止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 [VCCV].
请求比它应该走的更远。应执行此操作的示例包括ping VPN IPv4或IPv6前缀、L2 VPN端点或伪线。防止ping请求走得太远也可以通过在该标签上方插入路由器警报标签来实现；然而，这可能导致不希望的副作用，即MPLS回送请求采用与实际数据不同的数据路径。有关如何将这些机制用于伪线连接验证的更多信息，请参阅[VCCV]。
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 seconds and microseconds) that the echo request is sent. The TimeStamp Received is set to zero.
发送的时间戳设置为一天中发送回显请求的时间（以秒和微秒为单位）。接收的时间戳设置为零。
An MPLS echo request MUST have an 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 Mapping TLV.
MPLS回显请求必须具有FEC堆栈TLV。此外，应答模式必须设置为所需的应答模式；返回代码和子代码设置为零。在“traceroute”模式下，echo请求应包括下游映射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 stack is considered to be 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 error 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 to zero. If there are any TLVs not marked as "Ignore" that LSR X does not understand, LSR X SHOULD send an MPLS "TLV not understood" (as appropriate), and the Subcode set 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 fields 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，则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 Downstream Mapping TLV (not always present)
Stack-D：下游映射TLV中携带的标签堆栈（不总是存在）
Label-L: the label from the actual stack currently being examined. Requires no initialization.
Label-L：当前正在检查的实际堆栈中的标签。不需要初始化。
Label-stack-depth: the depth of 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 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 its being a tail-end for the LSP */
/* The LSR needs to report its being 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 L {
如果没有L的条目{
/* Indicates a temporary or permanent label synchronization
problem the LSR needs to report an error */
/* Indicates a temporary or permanent label synchronization
problem 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 NLFE and proceed to step 4 (Label Operation check).
从相应的NLFE中检索相关的标签操作，并继续执行步骤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 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 {
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.
}
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.
}
Else {
否则{
Verify that the IP address, interface address, and label
stack in the Downstream 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).
}
}
Verify that the IP address, interface address, and label
stack in the Downstream 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).
}
}
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 goto Send_Reply_Packet. }
将最佳返回码设置为返回码9，“标签交换但在堆栈深度没有MPLS转发”，并将最佳rtn子码设置为标签堆栈深度并转到发送应答数据包。}
If a Downstream Mapping TLV is present {
如果存在下游映射TLV{
A Downstream Mapping TLV SHOULD be included in the echo
reply (see section 3.3) filled in with information about
the current ECMP path.
}
}
A Downstream Mapping TLV SHOULD be included in the echo
reply (see section 3.3) filled in with information about
the current ECMP path.
}
}
If no Downstream 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 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 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 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 {
++FEC-stack-depth.
if Stack-D[FEC-stack-depth] != 3 (Implicit Null)
--i.
}
While (i > 0 ) do {
++FEC-stack-depth.
if Stack-D[FEC-stack-depth] != 3 (Implicit Null)
--i.
}
If the number of labels in the FEC stack is greater than or equal to FEC-stack-depth {
如果FEC堆栈中的标签数大于或等于FEC堆栈深度{
Perform the FEC Checking procedure (see subsection 4.4.1 below).
执行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 received echo request contains no Downstream Mapping TLV, or the Downstream IP Address is set to 127.0.0.1 or 0::1 go to step 6 (Egress FEC Validation).
如果收到的回显请求不包含下游映射TLV，或者下游IP地址设置为127.0.0.1或0:：1，则转至步骤6（出口FEC验证）。
Verify that the IP address, interface address, and label stack in the Downstream Mapping TLV match Interface-I and Stack-R. If not, set Best-return-code to 5, "Downstream Mapping Mis-match". 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 subsection 4.4.1 for Label-L and the FEC at FEC-stack-depth.
按照第4.4.1小节中针对标签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.
++FEC堆栈深度。
If FEC-stack-depth > the number of FECs in the FEC-stack, go to step 7 (Send Reply Packet).
如果FEC堆栈深度>FEC堆栈中的FEC数量，则转至步骤7（发送回复数据包）。
If FEC-status is 0 { ++Label-stack-depth. If Label-stack-depth > the number of labels in Stack-R, Go to step 7 (Send Reply Packet).
如果FEC状态为0{++标签堆栈深度。如果标签堆栈深度>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 subsection 4.4.1.
发送MPLS回显回复，返回码为最佳返回码，返回子码为最佳rtn子码。包括在上述过程中创建的任何TLV。发送回音回复的程序见第4.4.1小节。
/* This subsection describes validation of an FEC entry within the
Target FEC Stack and accepts an FEC, Label-L, and Interface-I.
The algorithm performs the following steps. */
/* This subsection describes validation of an FEC entry within the
Target FEC Stack and accepts an FEC, Label-L, and Interface-I.
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 { If Label-L is either Explicit_Null or Router_Alert, return.
2. 如果FEC是Nil FEC{如果Label-L是Explicit_Null或Router_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.
}
}
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.
}
}
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
4. 如果FEC的标签映射为隐式Null，则将FEC状态设置为2并继续执行步骤5。否则，如果FEC的标签映射为
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.
标签-L，继续执行步骤5。否则，将FEC返回代码设置为10（“此FEC的映射不是堆栈深度处的给定标签”），将FEC状态设置为1，然后返回。
5. This is a protocol check. Check what protocol would be used to advertise FEC. If it can be determined that no protocol associated with Interface-I would have advertised an 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. If the reply is sent over an LSP, the topmost label MUST in this case be the Router Alert label (1) (see [LABEL-STACK]).
MPLS回显应答是UDP数据包。它必须仅在响应MPLS回送请求时发送。源IP地址是应答器的可路由地址；源端口是众所周知的用于LSP ping的UDP端口。从echo请求的源IP地址和UDP端口复制目标IP地址和UDP端口。IP TTL设置为255。如果回送请求中的回复模式为“通过IPv4 UDP数据包回复路由器警报”，则IP报头必须包含路由器警报IP选项。如果通过LSP发送回复，则在这种情况下，最上面的标签必须是路由器警报标签（1）（请参阅[label-STACK]）。
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 subsection.
回复者必须填写上一小节中确定的返回代码和子代码。
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 Mapping TLVs SHOULD NOT be included in the echo reply.
如果应答路由器是FEC的目的地，则下游映射TLV不应包括在回声应答中。
If the echo request contains a Downstream 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 Mapping TLVs for each one to the echo reply it sends back.
如果回送请求包含下游映射TLV，且应答路由器不是FEC的目的地，应答器应计算其下游路由器和传入标签的相应标签，并将每个下游映射TLV添加到其发送回的回送应答中。
If the Downstream 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 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网络的上下文中发送。
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 Mappings, and X wishes to traceroute further, it SHOULD copy the Downstream Mapping(s) into its next echo request(s) (with TTL incremented by one).
如果echo应答包含下游映射，并且X希望进一步跟踪路由，则它应该将下游映射复制到下一个echo请求中（TTL增加1）。
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 send back error code 13. In that case, the initiating LSR can retry 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.
为了解决这个问题，一种方法是让接收到这种ping的LSR意识到ping提前终止，并发回错误代码13。在这种情况下，启动LSR可以在增加VPN标签上的TTL后重试ping。以这种方式，入口LSR将依次尝试TTL值，直到找到一个允许VPN ping到达出口PE的值。
If the egress for the FEC Stack being pinged does not support MPLS ping, then no reply will be sent, resulting in possible "false negatives". If in "traceroute" mode, 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 Downstream Mapping TLV "Downstream IP Address" field set to the ALLROUTERs multicast address until a reply is received with a Downstream Mapping TLV. The label stack MAY be omitted from the Downstream Mapping TLV. Furthermore, the "Validate FEC Stack" flag SHOULD NOT be set until an echo reply packet with a Downstream Mapping TLV is received.
如果正在ping的FEC堆栈的出口不支持MPLS ping，则不会发送应答，从而导致可能的“误报”。如果在“跟踪路由”模式下，传输LSR不支持LSP ping，那么对于某些TTL（例如，n），该LSR将不会给出任何回复。发起回显请求的LSR应尝试发送TTL=n+1，n+2，…，n+k的回显请求，以探测路径上更远的LSR。在这种情况下，TTL>n的回送请求应在下游映射TLV“下游IP地址”字段设置为ALLROUTERs多播地址的情况下发送，直到收到带有下游映射TLV的回复。标签堆栈可以从下游映射TLV中省略。此外，在接收到具有下游映射TLV的回声应答包之前，不应设置“验证FEC堆栈”标志。
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[LABEL-STACK] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[标签堆栈]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[NTP] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[NTP]Mills，D.，“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 2030，1996年10月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，2005年3月。
[BGP-LABEL] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[BGP-LABEL]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，2001年5月。
[ICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMP]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[LDP]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[PW-CONTROL] Martini, L., El-Aawar, N., Heron, G., Rosen, E., Tappan, D., and T. Smith, "Pseudowire Setup and Maintenance using the Label Distribution Protocol", Work in Progress.
[PW-CONTROL]Martini，L.，El-Aawar，N.，Heron，G.，Rosen，E.，Tappan，D.，和T.Smith，“使用标签分发协议的伪线设置和维护”，正在进行中。
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, February 2006.
[RFC4365]Rosen，E.“BGP/MPLS IP虚拟专用网络（VPN）的适用性声明”，RFC 4365，2006年2月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV), Work in Progress, August 2005.
[VCCV]Nadeau，T.和R.Aggarwal，“伪线虚拟电路连接验证（VCCV）”，正在进行的工作，2005年8月。
[VPLS-BGP] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service", Work in Progress.
[VPLS-BGP]Kompella，K.和Y.Rekhter，“虚拟专用局域网服务”，正在进行中。
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 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至少有三种方法。一种是拒绝服务攻击，通过向LSR发送MPLS回送请求/回复，从而增加其工作负载。第二种是通过欺骗、劫持、重放或以其他方式篡改MPLS回送请求和回复来混淆MPLS数据平面活动的状态。第三个是未经授权的来源，使用LSP ping获取有关网络的信息。
To avoid potential Denial-of-Service 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 below.
为了避免潜在的拒绝服务攻击，建议实施规范流向控制平面的LSP ping通信量。速率限制器应应用于下面定义的众所周知的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 and 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数据平面状态的了解是机密的。然而，实现应该提供一种过滤回送回复消息可能发送到的地址的方法。
Although this document makes special use of 127/8 address, 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地址的数据包视为“火星人”。
The TCP and UDP port number 3503 has been allocated by IANA for LSP echo requests and replies.
IANA已为LSP回显请求和回复分配TCP和UDP端口号3503。
The following sections detail the new name spaces to be managed by IANA. For each 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 [IANA]), "Specification Required", and "Vendor Private Use".
以下各节详细介绍了IANA将管理的新名称空间。对于这些名称空间中的每一个，空间被划分为分配范围；以下术语用于描述IANA分配值的程序：“标准行动”（定义见[IANA]）、“所需规范”和“供应商私人使用”。
Values from "Specification Required" ranges MUST be registered with IANA. The request MUST be made via an Experimental 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专用企业编号的确切位置；参见下面的示例。通过这种方式，多个企业（供应商）可以使用相同的代码点，而不必担心冲突。
The 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节列出了本文件中定义的返回代码。
The IANA has created and will maintain a registry for the Type field of top-level TLVs as well as for any associated sub-TLVs. Note 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 range 0-16383 and 32768-49161 are made via Standards Action as defined in [IANA]; assignments in the range 16384-31743 and 49162-64511 are made via "Specification Required" as defined above; values in the range 31744-32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated.
TLV和子TLV的有效范围为0-65535。0-16383和32768-49161范围内的分配通过[IANA]中定义的标准行动进行；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 Not Assigned
6 VPN IPv4 prefix
7 VPN IPv6 prefix
8 L2 VPN endpoint
9 "FEC 128" Pseudowire (Deprecated)
10 "FEC 128" Pseudowire
11 "FEC 129" Pseudowire
12 BGP labeled IPv4 prefix
13 BGP labeled IPv6 prefix
14 Generic IPv4 prefix
15 Generic IPv6 prefix
16 Nil FEC
2 Downstream Mapping
3 Pad
4 Not Assigned
5 Vendor Enterprise Number
6 Not Assigned
7 Interface and Label Stack
8 Not Assigned
9 Errored TLVs
Any value The TLV not understood
10 Reply TOS Byte
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 Not Assigned
6 VPN IPv4 prefix
7 VPN IPv6 prefix
8 L2 VPN endpoint
9 "FEC 128" Pseudowire (Deprecated)
10 "FEC 128" Pseudowire
11 "FEC 129" Pseudowire
12 BGP labeled IPv4 prefix
13 BGP labeled IPv6 prefix
14 Generic IPv4 prefix
15 Generic IPv6 prefix
16 Nil FEC
2 Downstream Mapping
3 Pad
4 Not Assigned
5 Vendor Enterprise Number
6 Not Assigned
7 Interface and Label Stack
8 Not Assigned
9 Errored TLVs
Any value The TLV not understood
10 Reply TOS Byte
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建议的文本。
Authors' Addresses
作者地址
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
George Swallow Cisco Systems 1414 Massachusetts Ave, Boxborough, MA 01719
马萨诸塞州伯斯堡马萨诸塞大道1414号George Swallow思科系统公司，邮编01719
Phone: +1 978 936 1398
EMail: swallow@cisco.com
Phone: +1 978 936 1398
EMail: swallow@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。