Internet Engineering Task Force (IETF) N. Akiya
Request for Comments: 8611 Big Switch Networks
Updates: 8029 G. Swallow
Category: Standards Track SETC
ISSN: 2070-1721 S. Litkowski
B. Decraene
Orange
J. Drake
Juniper Networks
M. Chen
Huawei
June 2019
Internet Engineering Task Force (IETF) N. Akiya
Request for Comments: 8611 Big Switch Networks
Updates: 8029 G. Swallow
Category: Standards Track SETC
ISSN: 2070-1721 S. Litkowski
B. Decraene
Orange
J. Drake
Juniper Networks
M. Chen
Huawei
June 2019
Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces
链路聚合组（LAG）接口的标签交换路径（LSP）Ping和跟踪路由多路径支持
Abstract
摘要
This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).
本文档定义了对RFC 8029中指定的MPLS标签交换路径（LSP）Ping和跟踪路由机制的扩展。这些扩展允许MPLS LSP Ping和跟踪路由机制在链路聚合组（LAG）接口上发现和执行第2层（L2）等成本多路径（ECMP）的特定路径。此外，还定义了一种机制，用于确定标签交换路由器（LSR）支持的功能。
This document updates RFC 8029.
本文档更新了RFC 8029。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8611.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8611.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview of Solution . . . . . . . . . . . . . . . . . . . . 4
3. LSR Capability Discovery . . . . . . . . . . . . . . . . . . 6
3.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7
3.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 7
4. Mechanism to Discover L2 ECMP . . . . . . . . . . . . . . . . 7
4.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7
4.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 8
4.3. Additional Initiator LSR Procedures . . . . . . . . . . . 10
5. Mechanism to Validate L2 ECMP Traversal . . . . . . . . . . . 11
5.1. Incoming LAG Member Links Verification . . . . . . . . . 11
5.1.1. Initiator LSR Procedures . . . . . . . . . . . . . . 11
5.1.2. Responder LSR Procedures . . . . . . . . . . . . . . 12
5.1.3. Additional Initiator LSR Procedures . . . . . . . . . 12
5.2. Individual End-to-End Path Verification . . . . . . . . . 14
6. LSR Capability TLV . . . . . . . . . . . . . . . . . . . . . 14
7. LAG Description Indicator Flag: G . . . . . . . . . . . . . . 15
8. Local Interface Index Sub-TLV . . . . . . . . . . . . . . . . 16
9. Remote Interface Index Sub-TLV . . . . . . . . . . . . . . . 17
10. Detailed Interface and Label Stack TLV . . . . . . . . . . . 17
10.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1.1. Incoming Label Stack Sub-TLV . . . . . . . . . . . . 19
10.1.2. Incoming Interface Index Sub-TLV . . . . . . . . . . 20
11. Rate-Limiting on Echo Request/Reply Messages . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13.1. LSR Capability TLV . . . . . . . . . . . . . . . . . . . 22
13.1.1. LSR Capability Flags . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview of Solution . . . . . . . . . . . . . . . . . . . . 4
3. LSR Capability Discovery . . . . . . . . . . . . . . . . . . 6
3.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7
3.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 7
4. Mechanism to Discover L2 ECMP . . . . . . . . . . . . . . . . 7
4.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7
4.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 8
4.3. Additional Initiator LSR Procedures . . . . . . . . . . . 10
5. Mechanism to Validate L2 ECMP Traversal . . . . . . . . . . . 11
5.1. Incoming LAG Member Links Verification . . . . . . . . . 11
5.1.1. Initiator LSR Procedures . . . . . . . . . . . . . . 11
5.1.2. Responder LSR Procedures . . . . . . . . . . . . . . 12
5.1.3. Additional Initiator LSR Procedures . . . . . . . . . 12
5.2. Individual End-to-End Path Verification . . . . . . . . . 14
6. LSR Capability TLV . . . . . . . . . . . . . . . . . . . . . 14
7. LAG Description Indicator Flag: G . . . . . . . . . . . . . . 15
8. Local Interface Index Sub-TLV . . . . . . . . . . . . . . . . 16
9. Remote Interface Index Sub-TLV . . . . . . . . . . . . . . . 17
10. Detailed Interface and Label Stack TLV . . . . . . . . . . . 17
10.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1.1. Incoming Label Stack Sub-TLV . . . . . . . . . . . . 19
10.1.2. Incoming Interface Index Sub-TLV . . . . . . . . . . 20
11. Rate-Limiting on Echo Request/Reply Messages . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13.1. LSR Capability TLV . . . . . . . . . . . . . . . . . . . 22
13.1.1. LSR Capability Flags . . . . . . . . . . . . . . . . 22
13.2. Local Interface Index Sub-TLV . . . . . . . . . . . . . 22
13.2.1. Interface Index Flags . . . . . . . . . . . . . . . 22
13.3. Remote Interface Index Sub-TLV . . . . . . . . . . . . . 23
13.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23
13.4.1. Sub-TLVs for TLV Type 6 . . . . . . . . . . . . . . 23
13.4.2. Interface and Label Stack Address Types . . . . . . 25
13.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. LAG with Intermediate L2 Switch Issues . . . . . . . 27
A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 27
A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 27
A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 27
A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
13.2. Local Interface Index Sub-TLV . . . . . . . . . . . . . 22
13.2.1. Interface Index Flags . . . . . . . . . . . . . . . 22
13.3. Remote Interface Index Sub-TLV . . . . . . . . . . . . . 23
13.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23
13.4.1. Sub-TLVs for TLV Type 6 . . . . . . . . . . . . . . 23
13.4.2. Interface and Label Stack Address Types . . . . . . 25
13.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. LAG with Intermediate L2 Switch Issues . . . . . . . 27
A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 27
A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 27
A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 27
A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
The MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms [RFC8029] are powerful tools designed to diagnose all available Layer 3 (L3) paths of LSPs, including diagnostic coverage of L3 Equal-Cost Multipath (ECMP). In many MPLS networks, Link Aggregation Groups (LAGs), as defined in [IEEE802.1AX], provide Layer 2 (L2) ECMP and are often used for various reasons. MPLS LSP Ping and Traceroute tools were not designed to discover and exercise specific paths of L2 ECMP. This produces a limitation for the following scenario when an LSP traverses a LAG:
MPLS标签交换路径（LSP）Ping和跟踪路由机制[RFC8029]是设计用于诊断LSP的所有可用第3层（L3）路径的强大工具，包括L3等成本多路径（ECMP）的诊断覆盖范围。在许多MPLS网络中，[IEEE802.1AX]中定义的链路聚合组（LAG）提供第2层（L2）ECMP，通常用于各种原因。MPLS LSP Ping和Traceroute工具不是为发现和使用L2 ECMP的特定路径而设计的。当LSP穿越滞后时，这会对以下场景产生限制：
o Label switching over some member links of the LAG is successful, but fails over other member links of the LAG.
o 标签切换LAG的某些成员链接成功，但切换LAG的其他成员链接失败。
o MPLS echo request for the LSP over the LAG is load-balanced on one of the member links that is label switching successfully.
o 在标签切换成功的一个成员链路上，针对延迟的LSP的MPLS回显请求是负载平衡的。
With the above scenario, MPLS LSP Ping and Traceroute will not be able to detect the label-switching failure of the problematic member link(s) of the LAG. In other words, lack of L2 ECMP diagnostic coverage can produce an outcome where MPLS LSP Ping and Traceroute can be blind to label-switching failures over a problematic LAG interface. It is, thus, desirable to extend the MPLS LSP Ping and Traceroute to have deterministic diagnostic coverage of LAG interfaces.
在上述场景中，MPLS LSP Ping和Traceroute将无法检测LAG中有问题的成员链路的标签切换故障。换句话说，缺乏L2 ECMP诊断覆盖可能会产生这样的结果，即MPLS LSP Ping和Traceroute可能无法通过有问题的延迟接口标记交换故障。因此，期望扩展MPLS LSP Ping和Traceroute以具有滞后接口的确定性诊断覆盖。
The work toward a solution to this problem was motivated by issues encountered in live networks.
解决此问题的工作是由实时网络中遇到的问题推动的。
The following acronyms/terms are used in this document:
本文件中使用了以下首字母缩略词/术语：
o MPLS - Multiprotocol Label Switching.
o 多协议标签交换。
o LSP - Label Switched Path.
o 标签交换路径。
o LSR - Label Switching Router.
o 标签交换路由器。
o ECMP - Equal-Cost Multipath.
o ECMP-等成本多路径。
o LAG - Link Aggregation Group.
o 滞后链接聚合组。
o Initiator LSR - The LSR that sends the MPLS echo request message.
o 启动器LSR—发送MPLS回显请求消息的LSR。
o Responder LSR - The LSR that receives the MPLS echo request message and sends the MPLS echo reply message.
o Responder LSR—接收MPLS回显请求消息并发送MPLS回显回复消息的LSR。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This document defines a new TLV to discover the capabilities of a responder LSR and extensions for use with the MPLS LSP Ping and Traceroute mechanisms to describe Multipath Information for individual LAG member links, thus allowing MPLS LSP Ping and Traceroute to discover and exercise specific paths of L2 ECMP over LAG interfaces. The reader is expected to be familiar with the Downstream Detailed Mapping TLV (DDMAP) described in Section 3.4 of [RFC8029].
本文档定义了一个新的TLV，用于发现响应者LSR的功能，以及与MPLS LSP Ping和Traceroute机制一起使用的扩展，以描述各个滞后成员链路的多路径信息，从而允许MPLS LSP Ping和Traceroute发现和使用L2 ECMP的特定路径。读者应熟悉[RFC8029]第3.4节中所述的下游详细映射TLV（DDMAP）。
The solution consists of the MPLS echo request containing a DDMAP TLV and the new LSR Capability TLV to indicate that separate load-balancing information for each L2 next hop over LAG is desired in the MPLS echo reply. The responder LSR places the same LSR Capability TLV in the MPLS echo reply to provide acknowledgement back to the initiator LSR. It also adds, for each downstream LAG member, load-balancing information (i.e., multipath information and interface
该解决方案包括包含DDMAP TLV的MPLS回显请求和新的LSR功能TLV，以指示MPLS回显回复中需要为每个L2下一跳滞后提供单独的负载平衡信息。响应方LSR将相同的LSR能力TLV放置在MPLS回送回复中，以向发起方LSR提供确认。它还为每个下游滞后成员添加负载平衡信息（即多路径信息和接口）
index). This mechanism is applicable to all types of LSPs that can traverse LAG interfaces. Many LAGs are built from peer-to-peer links, with router X and router X+1 having direct connectivity and the same number of LAG members. It is possible to build LAGs asymmetrically by using Ethernet switches between two routers. Appendix A lists some use cases for which the mechanisms defined in this document may not be applicable. Note that the mechanisms described in this document do not impose any changes to scenarios where an LSP is pinned down to a particular LAG member (i.e., the LAG is not treated as one logical interface by the LSP).
索引）。此机制适用于可以遍历滞后接口的所有类型的LSP。许多LAG是通过对等链路构建的，路由器X和路由器X+1具有直接连接和相同数量的LAG成员。通过在两个路由器之间使用以太网交换机，可以不对称地建立延迟。附录A列出了本文件中定义的机制可能不适用的一些用例。请注意，本文档中描述的机制不会对LSP固定到特定LAG成员（即，LSP不会将LAG视为一个逻辑接口）的场景施加任何更改。
The following figure and description provide an example of an LDP network.
下图和说明提供了LDP网络的示例。
<----- LDP Network ----->
<----- LDP Network ----->
+-------+
| |
A-------B=======C-------E
| |
+-------D-------+
+-------+
| |
A-------B=======C-------E
| |
+-------D-------+
---- Non-LAG
==== LAG comprising of two member links
---- Non-LAG
==== LAG comprising of two member links
Figure 1: Example LDP Network
图1：示例LDP网络
When node A is initiating LSP Traceroute to node E, node B will return to node A load-balancing information for the following entries:
当节点A启动到节点E的LSP跟踪路由时，节点B将向节点A返回以下条目的负载平衡信息：
1. Downstream C over Non-LAG (upper path).
1. 下游C超过非滞后（上游路径）。
2. First Downstream C over LAG (middle path).
2. 第一个下游C过滞后（中间路径）。
3. Second Downstream C over LAG (middle path).
3. 第二个下游C过滞后（中间路径）。
4. Downstream D over Non-LAG (lower path).
4. 下游D超过非滞后（较低路径）。
This document defines:
本文件规定：
o in Section 3, a mechanism to discover capabilities of responder LSRs;
o 在第3节中，发现响应者LSR能力的机制；
o in Section 4, a mechanism to discover L2 ECMP information;
o 在第4节中，一种发现L2 ECMP信息的机制；
o in Section 5, a mechanism to validate L2 ECMP traversal;
o 在第5节中，验证L2 ECMP遍历的机制；
o in Section 6, the LSR Capability TLV;
o 在第6节中，LSR能力为TLV；
o in Section 7, the LAG Description Indicator flag;
o 在第7节中，滞后描述指示器标志；
o in Section 8, the Local Interface Index Sub-TLV;
o 在第8节中，本地接口索引子TLV；
o in Section 9, the Remote Interface Index Sub-TLV; and
o 在第9节中，远程接口索引子TLV；和
o in Section 10, the Detailed Interface and Label Stack TLV.
o 在第10节中，详细介绍了接口和标签堆栈TLV。
The MPLS Ping operates by an initiator LSR sending an MPLS echo request message and receiving back a corresponding MPLS echo reply message from a responder LSR. The MPLS Traceroute operates in a similar way except the initiator LSR potentially sends multiple MPLS echo request messages with incrementing TTL values.
MPLS Ping通过发起方LSR发送MPLS回显请求消息并从响应方LSR接收回相应的MPLS回显回复消息来操作。MPLS跟踪路由以类似的方式运行，除了启动器LSR可能发送多个具有递增TTL值的MPLS回显请求消息。
There have been many extensions to the MPLS Ping and Traceroute mechanisms over the years. Thus, it is often useful, and sometimes necessary, for the initiator LSR to deterministically disambiguate the differences between:
多年来，MPLS Ping和Traceroute机制有许多扩展。因此，发起者LSR确定地消除以下两者之间的差异通常是有用的，有时是必要的：
o The responder LSR sent the MPLS echo reply message with contents C because it has feature X, Y, and Z implemented.
o 响应程序LSR发送内容为C的MPLS回显回复消息，因为它实现了功能X、Y和Z。
o The responder LSR sent the MPLS echo reply message with contents C because it has a subset of features X, Y, and Z (i.e., not all of them) implemented.
o 响应者LSR发送内容为C的MPLS回送回复消息，因为它实现了特征X、Y和Z的子集（即，并非全部）。
o The responder LSR sent the MPLS echo reply message with contents C because it does not have features X, Y, or Z implemented.
o 响应程序LSR发送了内容为C的MPLS回显回复消息，因为它没有实现功能X、Y或Z。
To allow the initiator LSR to disambiguate the above differences, this document defines the LSR Capability TLV (described in Section 6). When the initiator LSR wishes to discover the capabilities of the responder LSR, the initiator LSR includes the LSR Capability TLV in the MPLS echo request message. When the responder LSR receives an MPLS echo request message with the LSR Capability TLV included, if it knows the LSR Capability TLV, then it MUST include the LSR Capability TLV in the MPLS echo reply message with the LSR Capability TLV describing the features and extensions supported by the local LSR. Otherwise, an MPLS echo reply must be sent back to the initiator LSR with the return code set to "One or more of the TLVs was not understood", according to the rules defined in Section 3 of [RFC8029]. Then, the initiator LSR can send another MPLS echo request without including the LSR Capability TLV.
为了让发起方LSR消除上述差异的歧义，本文件定义了LSR能力TLV（如第6节所述）。当发起方LSR希望发现响应方LSR的能力时，发起方LSR在MPLS回显请求消息中包括LSR能力TLV。当响应者LSR接收到包含LSR能力TLV的MPLS回显请求消息时，如果它知道LSR能力TLV，那么它必须在MPLS回显回复消息中包含LSR能力TLV，LSR能力TLV描述本地LSR支持的功能和扩展。否则，根据[RFC8029]第3节中定义的规则，必须将MPLS回送回复发送回启动器LSR，返回代码设置为“一个或多个TLV未被理解”。然后，发起方LSR可以发送另一个MPLS回显请求，而不包括LSR能力TLV。
It is RECOMMENDED that implementations supporting the LAG multipath extensions defined in this document include the LSR Capability TLV in MPLS echo request messages.
建议支持本文档中定义的滞后多路径扩展的实现包括MPLS回显请求消息中的LSR功能TLV。
If an initiator LSR does not know what capabilities a responder LSR can support, it can send an MPLS echo request message and carry the LSR Capability TLV to the responder to discover the capabilities that the responder LSR can support.
如果发起方LSR不知道响应方LSR可以支持哪些功能，它可以发送MPLS回送请求消息，并将LSR功能TLV传送给响应方，以发现响应方LSR可以支持的功能。
When a responder LSR receives an MPLS echo request message that carries the LSR Capability TLV, the following procedures are used:
当响应者LSR接收到携带LSR能力TLV的MPLS回显请求消息时，使用以下过程：
If the responder knows how to process the LSR Capability TLV, the following procedures are used:
如果响应者知道如何处理LSR能力TLV，则使用以下程序：
o The responder LSR MUST include the LSR Capability TLV in the MPLS echo reply message.
o 响应者LSR必须在MPLS回显回复消息中包含LSR能力TLV。
o If the responder LSR understands the LAG Description Indicator flag:
o 如果响应者LSR理解滞后描述指示器标志：
* Set the Downstream LAG Info Accommodation flag if the responder LSR is capable of describing the outgoing LAG member links separately; otherwise, clear the Downstream LAG Info Accommodation flag.
* 如果应答器LSR能够单独描述传出滞后成员链路，则设置下行滞后信息调节标志；否则，清除下游滞后信息调节标志。
* Set the Upstream LAG Info Accommodation flag if the responder LSR is capable of describing the incoming LAG member links separately; otherwise, clear the Upstream LAG Info Accommodation flag.
* 如果应答器LSR能够单独描述传入的滞后成员链路，则设置上游滞后信息适应标志；否则，清除上游滞后信息调节标志。
Through LSR Capability Discovery as defined in Section 3, the initiator LSR can understand whether the responder LSR can describe incoming/outgoing LAG member links separately in the DDMAP TLV.
通过第3节中定义的LSR能力发现，发起方LSR可以了解响应方LSR是否可以在DDMAP TLV中单独描述传入/传出LAG成员链路。
Once the initiator LSR knows that a responder can support this mechanism, then it sends an MPLS echo request carrying a DDMAP TLV with the LAG Description Indicator flag (G) set to the responder LSR. The LAG Description Indicator flag (G) indicates that separate load-
一旦发起方LSR知道响应方可以支持此机制，则它将发送一个带有DDMAP TLV的MPLS回显请求，并将滞后描述指示符标志（G）设置为响应方LSR。滞后描述指示器标志（G）表示单独的负载-
balancing information for each L2 next hop over a LAG is desired in the MPLS echo reply. The new LAG Description Indicator flag is described in Section 7.
在MPLS回送应答中，需要在延迟上平衡每个L2下一跳的信息。第7节介绍了新的滞后描述指示器标志。
When a responder LSR receives an MPLS echo request message with the LAG Description Indicator flag set in the DDMAP TLV, if the responder LSR understands the LAG Description Indicator flag and is capable of describing outgoing LAG member links separately, the following procedures are used, regardless of whether or not the outgoing interfaces include LAG interfaces:
当响应者LSR接收到具有在DDMAP TLV中设置的滞后描述指示符标志的MPLS回显请求消息时，如果响应者LSR理解滞后描述指示符标志并且能够单独描述传出滞后成员链路，则使用以下过程，无论传出接口是否包含滞后接口：
o For each downstream interface that is a LAG interface:
o 对于作为滞后接口的每个下游接口：
* The responder LSR MUST include a DDMAP TLV when sending the MPLS echo reply. There is a single DDMAP TLV for the LAG interface, with member links described using sub-TLVs.
* 在发送MPLS回显应答时，应答器LSR必须包括DDMAP TLV。LAG接口只有一个DDMAP TLV，使用子TLV描述成员链接。
* The responder LSR MUST set the LAG Description Indicator flag in the DS Flags field of the DDMAP TLV.
* 应答器LSR必须在DDMAP TLV的DS标志字段中设置滞后描述指示器标志。
* In the DDMAP TLV, the Local Interface Index Sub-TLV, Remote Interface Index Sub-TLV, and Multipath Data Sub-TLV are used to describe each LAG member link. All other fields of the DDMAP TLV are used to describe the LAG interface.
* 在DDMAP TLV中，本地接口索引子TLV、远程接口索引子TLV和多路径数据子TLV用于描述每个LAG成员链路。DDMAP TLV的所有其他字段用于描述LAG接口。
* For each LAG member link of the LAG interface:
* 对于LAG接口的每个LAG成员链接：
+ The responder LSR MUST add a Local Interface Index Sub-TLV (described in Section 8) with the LAG Member Link Indicator flag set in the Interface Index Flags field. It describes the interface index of this outgoing LAG member link (the local interface index is assigned by the local LSR).
+ 响应程序LSR必须添加本地接口索引子TLV（如第8节所述），并在接口索引标志字段中设置滞后成员链接标志。它描述此传出LAG成员链接的接口索引（本地接口索引由本地LSR分配）。
+ The responder LSR MAY add a Remote Interface Index Sub-TLV (described in Section 9) with the LAG Member Link Indicator flag set in the Interface Index Flags field. It describes the interface index of the incoming LAG member link on the downstream LSR (this interface index is assigned by the downstream LSR). How the local LSR obtains the interface index of the LAG member link on the downstream LSR is outside the scope of this document.
+ 响应者LSR可以添加远程接口索引子TLV（在第9节中描述），在接口索引标志字段中设置滞后成员链接标志。它描述了下游LSR上传入滞后成员链路的接口索引（该接口索引由下游LSR分配）。本地LSR如何获得下游LSR上LAG成员链接的接口索引不在本文档范围内。
+ The responder LSR MUST add a Multipath Data Sub-TLV for this LAG member link, if the received DDMAP TLV requested multipath information.
+ 如果接收到的DDMAP TLV请求多路径信息，则响应程序LSR必须为此滞后成员链路添加多路径数据子TLV。
Based on the procedures described above, every LAG member link will have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV entry in the DDMAP TLV. The order of the sub-TLVs in the DDMAP TLV for a LAG member link MUST be Local Interface Index Sub-TLV immediately followed by Multipath Data Sub-TLV, except as follows. A LAG member link MAY also have a corresponding Remote Interface Index Sub-TLV. When a Local Interface Index Sub-TLV, a Remote Interface Index Sub-TLV, and a Multipath Data Sub-TLV are placed in the DDMAP TLV to describe a LAG member link, they MUST be placed in the order of Local Interface Index Sub-TLV, Remote Interface Index Sub-TLV, and Multipath Data Sub-TLV. The blocks of Local Interface Index, Remote Interface Index (optional), and Multipath Data Sub-TLVs for each member link MUST appear adjacent to each other and be in order of increasing local interface index.
基于上述过程，每个LAG成员链路将在DDMAP TLV中具有本地接口索引子TLV和多路径数据子TLV条目。滞后成员链路的DDMAP TLV中的子TLV顺序必须是本地接口索引子TLV，紧接着是多路径数据子TLV，以下情况除外。滞后成员链路还可以具有相应的远程接口索引子TLV。当本地接口索引子TLV、远程接口索引子TLV和多路径数据子TLV放置在DDMAP TLV中以描述滞后成员链路时，它们必须按照本地接口索引子TLV、远程接口索引子TLV和多路径数据子TLV的顺序放置。每个成员链路的本地接口索引、远程接口索引（可选）和多路径数据子TLV块必须彼此相邻，并按增加本地接口索引的顺序排列。
A responder LSR possessing a LAG interface with two member links would send the following DDMAP for this LAG interface:
拥有带有两个成员链接的滞后接口的响应者LSR将为此滞后接口发送以下DDMAP：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DDMAP fields describing LAG interface (DS Flags with G set) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Index Sub-TLV of LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Index Sub-TLV of LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Data Sub-TLV LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Index Sub-TLV of LAG member link #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Index Sub-TLV of LAG member link #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Data Sub-TLV LAG member link #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DDMAP fields describing LAG interface (DS Flags with G set) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Index Sub-TLV of LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Index Sub-TLV of LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Data Sub-TLV LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Index Sub-TLV of LAG member link #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Index Sub-TLV of LAG member link #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Data Sub-TLV LAG member link #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example of DDMAP in MPLS Echo Reply
图2:MPLS回送应答中的DDMAP示例
When none of the received multipath information maps to a particular LAG member link, then the responder LSR MUST still place the Local Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG member link in the DDMAP TLV. The value of the Multipath Length field of the Multipath Data Sub-TLV is set to zero.
当没有接收到的多路径信息映射到特定的滞后成员链路时，响应者LSR必须仍然将该滞后成员链路的本地接口索引子TLV和多路径数据子TLV放置在DDMAP TLV中。多路径数据子TLV的多路径长度字段的值设置为零。
The procedures in Section 4.2 allow an initiator LSR to:
第4.2节中的程序允许启动器LSR：
o Identify whether or not the responder LSR can describe outgoing LAG member links separately, by looking at the LSR Capability TLV.
o 通过查看LSR功能TLV，确定响应者LSR是否可以单独描述传出滞后成员链接。
o Utilize the value of the LAG Description Indicator flag in DS Flags to identify whether each received DDMAP TLV describes a LAG interface or a non-LAG interface.
o 利用DS标志中滞后描述指示符标志的值来识别每个接收到的DDMAP TLV是描述滞后接口还是非滞后接口。
o Obtain multipath information that is expected to traverse the specific LAG member link described by the corresponding interface index.
o 获取预期将通过相应接口索引描述的特定滞后成员链接的多路径信息。
When an initiator LSR receives a DDMAP containing LAG member information from a downstream LSR with TTL=n, then the subsequent DDMAP sent by the initiator LSR to the downstream LSR with TTL=n+1 through a particular LAG member link MUST be updated according to the following procedures:
当发起者LSR从TTL=n的下游LSR接收到包含滞后成员信息的DDMAP时，发起者LSR通过特定滞后成员链接发送给TTL=n+1的下游LSR的后续DDMAP必须按照以下过程进行更新：
o The Local Interface Index Sub-TLVs MUST be removed in the sending DDMAP.
o 必须在发送DDMAP中删除本地接口索引子TLV。
o If the Remote Interface Index Sub-TLVs were present and the initiator LSR is traversing over a specific LAG member link, then the Remote Interface Index Sub-TLV corresponding to the LAG member link being traversed SHOULD be included in the sending DDMAP. All other Remote Interface Index Sub-TLVs MUST be removed from the sending DDMAP.
o 如果存在远程接口索引子TLV，并且启动器LSR正在穿越特定的滞后成员链路，则与正在穿越的滞后成员链路相对应的远程接口索引子TLV应包含在发送DDMAP中。必须从发送DDMAP中删除所有其他远程接口索引子TLV。
o The Multipath Data Sub-TLVs MUST be updated to include just one Multipath Data Sub-TLV. The initiator LSR MAY just keep the Multipath Data Sub-TLV corresponding to the LAG member link being traversed or combine the Multipath Data Sub-TLVs for all LAG member links into a single Multipath Data Sub-TLV when diagnosing further downstream LSRs.
o 必须更新多路径数据子TLV，以仅包括一个多路径数据子TLV。当诊断进一步的下游LSR时，发起方LSR可以仅保持与正在穿越的滞后成员链路相对应的多路径数据子TLV，或者将所有滞后成员链路的多路径数据子TLV组合成单个多路径数据子TLV。
o All other fields of the DDMAP are to comply with procedures described in [RFC8029].
o DDMAP的所有其他字段应符合[RFC8029]中所述的程序。
Figure 3 is an example that shows how to use the DDMAP TLV to send a notification about which member link (link #1 in the example) will be chosen to send the MPLS echo request message to the next downstream LSR:
图3是一个示例，显示了如何使用DDMAP TLV发送关于将选择哪个成员链路（示例中的链路#1）向下一个下游LSR发送MPLS回显请求消息的通知：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DDMAP fields describing LAG interface (DS Flags with G set) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Data Sub-TLV LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Sub-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DDMAP fields describing LAG interface (DS Flags with G set) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Data Sub-TLV LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example of DDMAP in MPLS Echo Request
图3:MPLS回显请求中的DDMAP示例
Section 4 defines the responder LSR procedures to construct a DDMAP for a downstream LAG. The Remote Interface Index Sub-TLV that describes the incoming LAG member links of the downstream LSR is optional, because this information from the downstream LSR is often not available on the responder LSR. In such case, the traversal of LAG member links can be validated with procedures described in Section 5.1. If LSRs can provide the Remote Interface Index Sub-TLVs, then the validation procedures described in Section 5.2 can be used.
第4节定义了响应者LSR程序，以构建下游滞后的DDMAP。描述下游LSR的传入滞后成员链路的远程接口索引子TLV是可选的，因为来自下游LSR的此信息通常在响应者LSR上不可用。在这种情况下，可以使用第5.1节中描述的程序验证滞后构件链接的遍历。如果LSR可以提供远程接口索引子TLV，则可以使用第5.2节中描述的验证程序。
Without downstream LSRs returning Remote Interface Index Sub-TLVs in the DDMAP, validation of the LAG member link traversal requires that the initiator LSR traverses all available LAG member links and takes the results through additional logic. This section provides the mechanism for the initiator LSR to obtain additional information from the downstream LSRs and describes the additional logic in the initiator LSR to validate the L2 ECMP traversal.
如果下游LSR在DDMAP中不返回远程接口索引子TLV，则滞后成员链接遍历的验证要求启动器LSR遍历所有可用的滞后成员链接，并通过附加逻辑获取结果。本节提供了启动器LSR从下游LSR获取附加信息的机制，并描述了启动器LSR中验证L2 ECMP遍历的附加逻辑。
An MPLS echo request carrying a DDMAP TLV with the Interface and Label Stack Object Request flag and LAG Description Indicator flag set is sent to indicate the request for Detailed Interface and Label Stack TLV with additional LAG member link information (i.e., interface index) in the MPLS echo reply.
发送带有DDMAP TLV的MPLS回送请求，该DDMAP TLV具有接口和标签堆栈对象请求标志和滞后描述指示符标志集，以指示在MPLS回送回复中对详细接口和标签堆栈TLV的请求以及附加滞后成员链接信息（即，接口索引）。
When it receives an echo request with the LAG Description Indicator flag set, a responder LSR that understands that flag and is capable of describing the incoming LAG member link SHOULD use the following procedures, regardless of whether or not the incoming interface was a LAG interface:
当接收到设置了滞后描述指示符标志的回显请求时，理解该标志并能够描述传入滞后成员链接的响应程序LSR应使用以下程序，无论传入接口是否为滞后接口：
o When the I flag (Interface and Label Stack Object Request flag) of the DDMAP TLV in the received MPLS echo request is set:
o 设置接收到的MPLS回波请求中DDMAP TLV的I标志（接口和标签堆栈对象请求标志）时：
* The responder LSR MUST add the Detailed Interface and Label Stack TLV (described in Section 10) in the MPLS echo reply.
* 应答器LSR必须在MPLS回送应答中添加详细的接口和标签堆栈TLV（如第10节所述）。
* If the incoming interface is a LAG, the responder LSR MUST add the Incoming Interface Index Sub-TLV (described in Section 10.1.2) in the Detailed Interface and Label Stack TLV. The LAG Member Link Indicator flag MUST be set in the Interface Index Flags field, and the Interface Index field set to the LAG member link that received the MPLS echo request.
* 如果传入接口为滞后接口，响应方LSR必须在详细接口和标签堆栈TLV中添加传入接口索引子TLV（如第10.1.2节所述）。必须在接口索引标志字段中设置滞后成员链路指示符标志，并将接口索引字段设置为接收MPLS回显请求的滞后成员链路。
These procedures allow the initiator LSR to utilize the Incoming Interface Index Sub-TLV in the Detailed Interface and the Label Stack TLV to derive, if the incoming interface is a LAG, the identity of the incoming LAG member.
这些过程允许启动器LSR利用详细接口中的传入接口索引子TLV和标签堆栈TLV，如果传入接口是LAG，则派生传入LAG成员的标识。
Along with procedures described in Section 4, the procedures described in this section will allow an initiator LSR to know:
除了第4节中描述的程序外，本节中描述的程序将允许启动器LSR了解：
o The expected load-balance information of every LAG member link, at LSR with TTL=n.
o 在TTL=n的LSR处，每个滞后成员链路的预期负载平衡信息。
o With specific entropy, the expected interface index of the outgoing LAG member link at TTL=n.
o 使用特定熵，TTL=n时传出滞后成员链路的预期接口索引。
o With specific entropy, the interface index of the incoming LAG member link at TTL=n+1.
o 在特定熵下，TTL=n+1处传入滞后成员链路的接口索引。
Depending on the LAG traffic division algorithm, the messages may or may not traverse different member links. The expectation is that there's a relationship between the interface index of the outgoing LAG member link at TTL=n and the interface index of the incoming LAG member link at TTL=n+1 for all entropies examined. In other words, the messages with a set of entropies that load-balances to outgoing LAG member link X at TTL=n should all reach the next hop on the same incoming LAG member link Y at TTL=n+1.
根据滞后流量分配算法，消息可能会也可能不会穿越不同的成员链路。对于所检查的所有熵，期望在TTL=n的传出滞后成员链接的接口索引和TTL=n+1的传入滞后成员链接的接口索引之间存在关系。换句话说，具有一组熵的消息（在TTL=n时负载平衡到传出滞后成员链路X）应在TTL=n+1时到达同一传入滞后成员链路Y上的下一跳。
With additional logic, the initiator LSR can perform the following checks in a scenario where it (a) knows that there is a LAG that has two LAG members, between TTL=n and TTL=n+1, and (b) has the multipath information to traverse the two LAG member links.
通过附加逻辑，启动器LSR可以在以下情况下执行以下检查：（a）知道在TTL=n和TTL=n+1之间存在具有两个滞后成员的滞后，并且（b）具有多路径信息以遍历两个滞后成员链路。
The initiator LSR sends two MPLS echo request messages to traverse the two LAG member links at TTL=n+1:
发起方LSR发送两条MPLS回显请求消息，以在TTL=n+1处遍历两个LAG成员链路：
o Success case:
o 成功案例：
* One MPLS echo request message reaches TTL=n+1 on LAG member link 1.
* 一条MPLS回送请求消息到达滞后成员链路1上的TTL=n+1。
* The other MPLS echo request message reaches TTL=n+1 on LAG member link 2.
* 另一个MPLS回显请求消息在LAG成员链路2上到达TTL=n+1。
The two MPLS echo request messages sent by the initiator LSR reach the immediate downstream LSR from two different LAG member links.
启动器LSR发送的两条MPLS回显请求消息从两个不同的LAG成员链路到达直接下游LSR。
o Error case:
o 错误案例：
* One MPLS echo request message reaches TTL=n+1 on LAG member link 1.
* 一条MPLS回送请求消息到达滞后成员链路1上的TTL=n+1。
* The other MPLS echo request message also reaches TTL=n+1 on LAG member link 1.
* 另一个MPLS回显请求消息也到达滞后成员链路1上的TTL=n+1。
* One or both MPLS echo request messages cannot reach the immediate downstream LSR on whichever link.
* 一条或两条MPLS回送请求消息无法到达任何链路上的直接下游LSR。
One or two MPLS echo request messages sent by the initiator LSR cannot reach the immediate downstream LSR, or the two MPLS echo request messages reach at the immediate downstream LSR from the same LAG member link.
启动器LSR发送的一个或两个MPLS回显请求消息无法到达直接下游LSR，或者两个MPLS回显请求消息从同一LAG成员链路到达直接下游LSR。
Note that the procedures defined above will provide a deterministic result for LAG interfaces that are back-to-back connected between LSRs (i.e., no L2 switch in between). If there is an L2 switch between the LSR at TTL=n and the LSR at TTL=n+1, there is no guarantee that every incoming interface at TTL=n+1 can be traversed, even when traversing every outgoing LAG member link at TTL=n. Issues resulting from LAG with an L2 switch in between are further described in Appendix A. LAG provisioning models in operator networks should be considered when analyzing the output of LSP Traceroute that is exercising L2 ECMPs.
注意，上面定义的过程将为在LSR之间背靠背连接的滞后接口（即，两者之间没有L2交换机）提供确定性结果。如果在TTL=n处的LSR和TTL=n+1处的LSR之间存在L2开关，则无法保证TTL=n+1处的每个传入接口都可以被遍历，即使在TTL=n处遍历每个传出滞后成员链路时也是如此。附录A中进一步描述了由于二级交换机之间的延迟而导致的问题。在分析执行二级ECMP的LSP跟踪路由的输出时，应考虑运营商网络中的延迟供应模型。
When the Remote Interface Index Sub-TLVs are available from an LSR with TTL=n, then the validation of LAG member link traversal can be performed by the downstream LSR of TTL=n+1. The initiator LSR follows the procedures described in Section 4.3.
当远程接口索引子TLV可从TTL=n的LSR获得时，则可以由TTL=n+1的下游LSR执行滞后成员链路遍历的验证。启动器LSR遵循第4.3节中描述的程序。
The DDMAP validation procedures for the downstream responder LSR are then updated to include the comparison of the incoming LAG member link to the interface index described in the Remote Interface Index Sub-TLV in the DDMAP TLV. Failure of this comparison results in the return code being set to "Downstream Mapping Mismatch (5)".
然后更新下游响应器LSR的DDMAP验证程序，以包括传入滞后成员链接与DDMAP TLV中远程接口索引子TLV中描述的接口索引的比较。此比较失败将导致返回代码设置为“下游映射不匹配（5）”。
This document defines a new TLV that is referred to as the LSR Capability TLV. It MAY be included in the MPLS echo request message and the MPLS echo reply message. An MPLS echo request message and an MPLS echo reply message MUST NOT include more than one LSR Capability TLV. The presence of an LSR Capability TLV in an MPLS echo request message is a request that a responder LSR includes an LSR Capability TLV in the MPLS echo reply message, with the LSR Capability TLV describing features and extensions that the responder LSR supports.
本文件定义了一种新的TLV，称为LSR能力TLV。它可以包括在MPLS回显请求消息和MPLS回显回复消息中。MPLS回显请求消息和MPLS回显回复消息不得包含多个LSR功能TLV。MPLS回显请求消息中存在LSR能力TLV是响应者LSR在MPLS回显回复消息中包括LSR能力TLV的请求，其中LSR能力TLV描述响应者LSR支持的特性和扩展。
The format of the LSR Capability TLV is as below:
LSR能力TLV的格式如下：
LSR Capability TLV Type is 4. Length is 4. The LSR Capability TLV has the following format:
LSR能力TLV类型为4。长度是4。LSR能力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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Capability Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Capability Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: LSR Capability TLV
图4:LSR能力TLV
Where:
哪里：
The Type field is 2 octets in length, and the value is 4.
类型字段的长度为2个八位字节，值为4。
The Length field is 2 octets in length, and the value is 4.
长度字段的长度为2个八位字节，值为4。
The LSR Capability Flags field is 4 octets in length; this document defines the following flags:
LSR能力标志字段的长度为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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Must Be Zero) |U|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Must Be Zero) |U|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines two flags. The unallocated flags MUST be set to zero when sending and ignored on receipt. Both the U and the D flag MUST be cleared in the MPLS echo request message when sending and ignored on receipt. Zero, one, or both of the flags (U and D) MAY be set in the MPLS echo reply message.
本文档定义了两个标志。发送时，未分配标志必须设置为零，接收时忽略。发送MPLS回显请求消息时，必须清除U和D标志，并在接收时忽略。可以在MPLS回送回复消息中设置零、一个或两个标志（U和D）。
Flag Name and Meaning
---- ----------------
Flag Name and Meaning
---- ----------------
U Upstream LAG Info Accommodation
上游滞后信息住宿
An LSR sets this flag when the LSR is capable of describing a LAG member link in the Incoming Interface Index Sub-TLV in the Detailed Interface and Label Stack TLV.
当LSR能够在详细接口和标签堆栈TLV中的传入接口索引子TLV中描述滞后成员链接时，LSR设置此标志。
D Downstream LAG Info Accommodation
D.下游滞后信息调节
An LSR sets this flag when the LSR is capable of describing LAG member links in the Local Interface Index Sub-TLV and the Multipath Data Sub-TLV in the Downstream Detailed Mapping TLV.
当LSR能够描述本地接口索引子TLV中的滞后成员链路和下游详细映射TLV中的多路径数据子TLV时，LSR设置此标志。
This document defines a new flag, the G flag (LAG Description Indicator), in the DS Flags field of the DDMAP TLV.
本文档在DDMAP TLV的DS标志字段中定义了一个新标志，即G标志（滞后描述指示器）。
The G flag in the MPLS echo request message indicates the request for detailed LAG information from the responder LSR. In the MPLS echo reply message, the G flag MUST be set if the DDMAP TLV describes a LAG interface. It MUST be cleared otherwise.
MPLS回显请求消息中的G标志指示从响应者LSR请求详细滞后信息。在MPLS回显回复消息中，如果DDMAP TLV描述滞后接口，则必须设置G标志。否则必须清除它。
The G flag is defined as below:
G标志的定义如下：
The Bit Number is 3.
位号是3。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |G|E|L|I|N|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |G|E|L|I|N|
+-+-+-+-+-+-+-+-+
Flag Name and Meaning
---- ----------------
Flag Name and Meaning
---- ----------------
G LAG Description Indicator
滞后描述指示器
When this flag is set in the MPLS echo request, the responder LSR is requested to respond with detailed LAG information. When this flag is set in the MPLS echo reply, the corresponding DDMAP TLV describes a LAG interface.
当在MPLS回显请求中设置此标志时，将请求响应者LSR使用详细的延迟信息进行响应。当在MPLS回送应答中设置此标志时，相应的DDMAP TLV描述滞后接口。
The Local Interface Index Sub-TLV describes the interface index assigned by the local LSR to an egress interface. One or more Local Interface Index sub-TLVs MAY appear in a DDMAP TLV.
本地接口索引子TLV描述本地LSR分配给出口接口的接口索引。一个或多个本地接口索引子TLV可能出现在DDMAP TLV中。
The format of the Local Interface Index Sub-TLV is below:
本地接口索引子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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Local Interface Index Sub-TLV
图5：本地接口索引子TLV
Where:
哪里：
o The Type field is 2 octets in length, and the value is 4.
o 类型字段的长度为2个八位字节，值为4。
o The Length field is 2 octets in length, and the value is 4.
o 长度字段的长度为2个八位字节，值为4。
o The Local Interface Index field is 4 octets in length; it is an interface index assigned by a local LSR to an egress interface. It's normally an unsigned integer and in network byte order.
o 本地接口索引字段的长度为4个八位字节；它是本地LSR分配给出口接口的接口索引。它通常是一个无符号整数，按网络字节顺序排列。
The Remote Interface Index Sub-TLV is an optional TLV; it describes the interface index assigned by a downstream LSR to an ingress interface. One or more Remote Interface Index sub-TLVs MAY appear in a DDMAP TLV.
远程接口索引子TLV是可选的TLV；它描述了下游LSR分配给入口接口的接口索引。一个或多个远程接口索引子TLV可能出现在DDMAP TLV中。
The format of the Remote Interface Index Sub-TLV is below:
远程接口索引子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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Remote Interface Index Sub-TLV
图6：远程接口索引子TLV
Where:
哪里：
o The Type field is 2 octets in length, and the value is 5.
o 类型字段的长度为2个八位字节，值为5。
o The Length field is 2 octets in length, and the value is 4.
o 长度字段的长度为2个八位字节，值为4。
o The Remote Interface Index field is 4 octets in length; it is an interface index assigned by a downstream LSR to an ingress interface. It's normally an unsigned integer and in network byte order.
o 远程接口索引字段长度为4个八位字节；它是由下游LSR分配给入口接口的接口索引。它通常是一个无符号整数，按网络字节顺序排列。
The Detailed Interface and Label Stack TLV MAY be included in an MPLS echo reply message to report the interface on which the MPLS echo request message was received and the label stack that was on the packet when it was received. A responder LSR MUST NOT insert more than one instance of this TLV into the MPLS echo reply message. This TLV allows the initiator LSR to obtain the exact interface and label stack information as it appears at the responder LSR.
详细的接口和标签栈TLV可以包括在MPLS回送回复消息中，以报告接收MPLS回送请求消息的接口和接收时在分组上的标签栈。响应者LSR不得将此TLV的多个实例插入MPLS回显回复消息中。此TLV允许启动器LSR获得在响应程序LSR上显示的确切接口和标签堆栈信息。
Detailed Interface and Label Stack TLV Type is 6. Length is K + Sub-TLV Length (sum of Sub-TLVs). K is the sum of all fields of this TLV prior to the list of Sub-TLVs, but the length of K depends on the Address Type. Details of this information is described below. The Detailed Interface and Label Stack TLV has the following format:
详细的接口和标签堆栈TLV类型为6。长度为K+子TLV长度（子TLV之和）。K是子TLV列表之前该TLV所有字段的总和，但K的长度取决于地址类型。下文详细介绍了这些信息。详细接口和标签堆栈TLV的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Reserved (Must Be Zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Reserved (Must Be Zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Detailed Interface and Label Stack TLV
图7：详细的接口和标签堆栈TLV
The Detailed Interface and Label Stack TLV format is derived from the Interface and Label Stack TLV format (from [RFC8029]). Two changes are introduced. The first is that the label stack is converted into a sub-TLV. The second is that a new sub-TLV is added to describe an interface index. The other fields of the Detailed Interface and Label Stack TLV have the same use and meaning as in [RFC8029]. A summary of these fields is as below:
详细的接口和标签堆栈TLV格式源自接口和标签堆栈TLV格式（来自[RFC8029]）。引入了两个变化。第一个是将标签堆栈转换为子TLV。第二个是添加一个子TLV来描述接口索引。详细接口和标签堆栈TLV的其他字段具有与[RFC8029]中相同的用途和含义。这些字段的摘要如下所示：
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 length of the initial part of the TLV is listed 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
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
如果接收回显请求消息的接口已编号，则地址类型必须设置为IPv4
Numbered or IPv6 Numbered, 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.
编号或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，并且接口必须设置为分配给接口的索引。
Note: Usage of IPv6 Unnumbered has the same issue as [RFC8029], which is described in Section 3.4.2 of [RFC7439]. A solution should be considered and applied to both [RFC8029] and this document.
注：未编号IPv6的使用与[RFC8029]存在相同的问题，如[RFC7439]第3.4.2节所述。[RFC8029]和本文件均应考虑并应用解决方案。
This section defines the sub-TLVs that MAY be included as part of the Detailed Interface and Label Stack TLV. Two sub-TLVs are defined:
本节定义了子TLV，该子TLV可作为详细接口和标签堆栈TLV的一部分。定义了两个子TLV：
Sub-Type Sub-TLV Name
--------- ------------
1 Incoming Label Stack
2 Incoming Interface Index
Sub-Type Sub-TLV Name
--------- ------------
1 Incoming Label Stack
2 Incoming Interface Index
The Incoming Label Stack Sub-TLV contains the label stack as received by an LSR. If any TTL values have been changed by this LSR, they SHOULD be restored.
传入标签堆栈子TLV包含LSR接收的标签堆栈。如果此LSR更改了任何TTL值，则应恢复这些值。
Incoming Label Stack Sub-TLV Type is 1. Length is variable, and its format is as below:
传入标签堆栈子TLV类型为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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Incoming Label Stack Sub-TLV
图8：传入标签堆栈子TLV
The Incoming Interface Index Sub-TLV MAY be included in a Detailed Interface and Label Stack TLV. The Incoming Interface Index Sub-TLV describes the index assigned by a local LSR to the interface that received the MPLS echo request message.
传入接口索引子TLV可以包含在详细的接口和标签堆栈TLV中。传入接口索引子TLV描述本地LSR分配给接收MPLS回显请求消息的接口的索引。
Incoming Interface Index Sub-TLV Type is 2. Length is 8, and its format is as below:
传入接口索引子TLV类型为2。长度为8，格式如下：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index Flags | Reserved (Must Be Zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index Flags | Reserved (Must Be Zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Incoming Interface Index Sub-TLV
图9：传入接口索引子TLV
Interface Index Flags
接口索引标志
The Interface Index Flags field is a bit vector with following format.
接口索引标志字段是具有以下格式的位向量。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Must Be Zero) |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Must Be Zero) |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One flag is defined: M. The remaining flags MUST be set to zero when sending and ignored on receipt.
定义了一个标志：M。发送时，其余标志必须设置为零，接收时忽略。
Flag Name and Meaning
---- ----------------
Flag Name and Meaning
---- ----------------
M LAG Member Link Indicator
M滞后成员链接指示器
When this flag is set, the interface index described in this sub-TLV is a member of a LAG.
设置此标志时，此子TLV中描述的接口索引是LAG的成员。
Incoming Interface Index
传入接口索引
An Index assigned by the LSR to this interface. It's normally an unsigned integer and in network byte order.
LSR分配给该接口的索引。它通常是一个无符号整数，按网络字节顺序排列。
An LSP may be over several LAGs. Each LAG may have many member links. To exercise all the links, many echo request/reply messages will be sent in a short period. It's possible that those messages may traverse a common path as a burst. Under some circumstances, this might cause congestion at the common path. To avoid potential congestion, it is RECOMMENDED that implementations randomly delay the echo request and reply messages at the initiator LSRs and responder LSRs. Rate-limiting of ping traffic is further specified in Section 5 of [RFC8029] and Section 4.1 of [RFC6425], which apply to this document as well.
LSP可能超过几个滞后时间。每个LAG可能有许多成员链接。为了使用所有链接，将在短时间内发送许多回显请求/回复消息。这些消息可能以突发的形式穿越公共路径。在某些情况下，这可能会导致公共路径出现拥塞。为了避免潜在的拥塞，建议实现在发起方LSR和响应方LSR处随机延迟回显请求和回复消息。[RFC8029]的第5节和[RFC6425]的第4.1节进一步规定了ping流量的速率限制，这也适用于本文件。
This document extends the LSP Traceroute mechanism [RFC8029] to discover and exercise L2 ECMP paths to determine problematic member link(s) of a LAG. These on-demand diagnostic mechanisms are used by an operator within an MPLS control domain.
本文档扩展了LSP跟踪路由机制[RFC8029]，以发现和使用L2 ECMP路径来确定延迟的问题成员链接。这些按需诊断机制由MPLS控制域内的操作员使用。
[RFC8029] reviews the possible attacks and approaches to mitigate possible threats when using these mechanisms.
[RFC8029]回顾了使用这些机制时可能的攻击和减轻可能威胁的方法。
To prevent leakage of vital information to untrusted users, a responder LSR MUST only accept MPLS echo request messages from designated trusted sources via filtering the source IP address field of received MPLS echo request messages. As noted in [RFC8029], spoofing attacks only have a small window of opportunity. If an intermediate node hijacks these messages (i.e., causes non-delivery), the use of these mechanisms will determine the data plane is not working as it should. Hijacking of a responder node such that it provides a legitimate reply would involve compromising the node itself and the MPLS control domain. [RFC5920] provides additional MPLS network-wide operation recommendations to avoid attacks. Please note that source IP address filtering provides only a weak form of access control and is not, in general, a reliable security mechanism. Nonetheless, it is required here in the absence of any more robust mechanisms that might be used.
为了防止重要信息泄漏给不受信任的用户，响应者LSR必须通过过滤接收到的MPLS回显请求消息的源IP地址字段，仅接受来自指定受信任源的MPLS回显请求消息。如[RFC8029]所述，欺骗攻击的机会很小。如果中间节点劫持这些消息（即，导致不传递），则使用这些机制将确定数据平面没有正常工作。劫持响应者节点以使其提供合法的应答将涉及损害节点本身和MPLS控制域。[RFC5920]提供额外的MPLS网络范围操作建议，以避免攻击。请注意，源IP地址过滤只提供一种弱形式的访问控制，通常不是一种可靠的安全机制。尽管如此，在没有任何更可靠的机制可供使用的情况下，这是必需的。
IANA has assigned value 4 (from the range 0-16383) for the LSR Capability TLV from the "TLVs" registry under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANA为“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表[IANA-MPLS-LSP-Ping]下的“TLV”注册表中的LSR功能TLV分配了值4（范围0-16383）。
Type TLV Name Reference
----- -------- ---------
4 LSR Capability RFC 8611
Type TLV Name Reference
----- -------- ---------
4 LSR Capability RFC 8611
IANA has created a new "LSR Capability Flags" registry. The initial contents are as follows:
IANA已经创建了一个新的“LSR能力标志”注册表。初步内容如下:
Value Meaning Reference
----- ------- ---------
31 D: Downstream LAG Info Accommodation RFC 8611
30 U: Upstream LAG Info Accommodation RFC 8611
0-29 Unassigned
Value Meaning Reference
----- ------- ---------
31 D: Downstream LAG Info Accommodation RFC 8611
30 U: Upstream LAG Info Accommodation RFC 8611
0-29 Unassigned
Assignments of LSR Capability Flags are via Standards Action [RFC8126].
LSR能力标志的分配通过标准行动[RFC8126]进行。
IANA has assigned value 4 (from the range 0-16383) for the Local Interface Index Sub-TLV from the "Sub-TLVs for TLV Type 20" subregistry of the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANA为“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表[IANA-MPLS-LSP-Ping]中“TLV”注册表的“TLV类型20的子TLV”子注册表中的本地接口索引子TLV分配了值4（范围0-16383）。
Sub-Type Sub-TLV Name Reference
-------- ------------ ---------
4 Local Interface Index RFC 8611
Sub-Type Sub-TLV Name Reference
-------- ------------ ---------
4 Local Interface Index RFC 8611
IANA has created a new "Interface Index Flags" registry. The initial contents are as follows:
IANA已经创建了一个新的“接口索引标志”注册表。初步内容如下:
Bit Number Name Reference
---------- -------------------------------- ---------
15 M: LAG Member Link Indicator RFC 8611
0-14 Unassigned
Bit Number Name Reference
---------- -------------------------------- ---------
15 M: LAG Member Link Indicator RFC 8611
0-14 Unassigned
Assignments of Interface Index Flags are via Standards Action [RFC8126].
通过标准操作[RFC8126]分配接口索引标志。
Note that this registry is used by the Interface Index Flags field of the following sub-TLVs:
请注意，此注册表由以下子TLV的接口索引标志字段使用：
o The Local Interface Index Sub-TLV, which may be present in the Downstream Detailed Mapping TLV.
o 本地接口索引子TLV，可能出现在下游详细映射TLV中。
o The Remote Interface Index Sub-TLV, which may be present in the Downstream Detailed Mapping TLV.
o 远程接口索引子TLV，可能存在于下游详细映射TLV中。
o The Incoming Interface Index Sub-TLV, which may be present in the Detailed Interface and Label Stack TLV.
o 传入接口索引子TLV，可能出现在详细接口和标签堆栈TLV中。
IANA has assigned value 5 (from the range 0-16383) for the Remote Interface Index Sub-TLV from the "Sub-TLVs for TLV Type 20" subregistry of the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANA为“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表[IANA-MPLS-LSP-Ping]中“TLV”注册表的“TLV类型20的子TLV”子注册表中的远程接口索引子TLV分配了值5（范围0-16383）。
Sub-Type Sub-TLV Name Reference
-------- ------------ ---------
5 Remote Interface Index RFC 8611
Sub-Type Sub-TLV Name Reference
-------- ------------ ---------
5 Remote Interface Index RFC 8611
IANA has assigned value 6 (from the range 0-16383) for the Detailed Interface and Label Stack TLV from the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANA为“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表[IANA-MPLS-LSP-Ping]中的“TLV”注册表中的详细接口和标签堆栈TLV分配了值6（范围0-16383）。
Type TLV Name Reference
----- -------- ---------
6 Detailed Interface and Label Stack RFC 8611
Type TLV Name Reference
----- -------- ---------
6 Detailed Interface and Label Stack RFC 8611
RFC 8029 changed the registration procedures for TLV and sub-TLV registries for LSP Ping.
RFC 8029更改了LSP Ping的TLV和子TLV注册表的注册程序。
IANA has created a new "Sub-TLVs for TLV Type 6" subregistry under the "TLVs" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANA已在“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表[IANA-MPLS-LSP-Ping]的“TLV”注册表下创建了一个新的“TLV 6型子TLV”分区。
This registry conforms with RFC 8029.
此注册表符合RFC 8029。
The registration procedures for this sub-TLV registry are:
该TLV子注册中心的注册程序如下：
Range Registration Procedure Note
----- ---------------------- -----
0-16383 Standards Action This range is for mandatory
TLVs or for optional TLVs that
require an error message if
not recognized.
16384-31743 RFC Required This range is for mandatory
TLVs or for optional TLVs that
require an error message if
not recognized.
31744-32767 Private Use Not to be assigned
32768-49161 Standards Action This range is for optional TLVs
that can be silently dropped if
not recognized.
49162-64511 RFC Required This range is for optional TLVs
that can be silently dropped if
not recognized.
64512-65535 Private Use Not to be assigned
Range Registration Procedure Note
----- ---------------------- -----
0-16383 Standards Action This range is for mandatory
TLVs or for optional TLVs that
require an error message if
not recognized.
16384-31743 RFC Required This range is for mandatory
TLVs or for optional TLVs that
require an error message if
not recognized.
31744-32767 Private Use Not to be assigned
32768-49161 Standards Action This range is for optional TLVs
that can be silently dropped if
not recognized.
49162-64511 RFC Required This range is for optional TLVs
that can be silently dropped if
not recognized.
64512-65535 Private Use Not to be assigned
The initial allocations for this registry are:
此注册表的初始分配为：
Sub-Type Sub-TLV Name Reference Comment
-------- ------------ --------- -------
0 Reserved RFC 8611
1 Incoming Label Stack RFC 8611
2 Incoming Interface Index RFC 8611
3-31743 Unassigned
31744-32767 RFC 8611 Reserved for
Private Use
32768-64511 Unassigned
64512-65535 RFC 8611 Reserved for
Private Use
Sub-Type Sub-TLV Name Reference Comment
-------- ------------ --------- -------
0 Reserved RFC 8611
1 Incoming Label Stack RFC 8611
2 Incoming Interface Index RFC 8611
3-31743 Unassigned
31744-32767 RFC 8611 Reserved for
Private Use
32768-64511 Unassigned
64512-65535 RFC 8611 Reserved for
Private Use
Note: IETF does not prescribe how the Private Use sub-TLVs are handled; however, if a packet containing a sub-TLV from a Private Use ranges is received by an LSR that does not recognize the sub-TLV, an error message MAY be returned if the sub-TLV is from the range 31744-32767, and the packet SHOULD be silently dropped if it is from the range 64511-65535.
注：IETF未规定如何处理专用子TLV；然而，如果不识别子TLV的LSR接收到包含来自私用范围的子TLV的分组，则如果子TLV来自范围31744-32767，则可能返回错误消息，并且如果该分组来自范围64511-65535，则该分组应被静默丢弃。
The Detailed Interface and Label Stack TLV shares the Interface and Label Stack Address Types with the Interface and Label Stack TLV. To reflect this, IANA has updated the name of the registry from "Interface and Label Stack Address Types" to "Interface and Label Stack and Detailed Interface and Label Stack Address Types".
详细接口和标签堆栈TLV与接口和标签堆栈TLV共享接口和标签堆栈地址类型。为了反映这一点，IANA将注册表的名称从“接口和标签堆栈地址类型”更新为“接口和标签堆栈以及详细的接口和标签堆栈地址类型”。
IANA has assigned a new bit number from the "DS Flags" subregistry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANA已从“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表[IANA-MPLS-LSP-Ping]的“DS标志”子区分配了一个新的位号。
Note: the "DS Flags" subregistry was created by [RFC8029].
注：“DS标志”子区域由[RFC8029]创建。
Bit number Name Reference
---------- ---------------------------------------- ---------
3 G: LAG Description Indicator RFC 8611
Bit number Name Reference
---------- ---------------------------------------- ---------
3 G: LAG Description Indicator RFC 8611
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[RFC8029]Kompella，K.，Swallow，G.，Pignataro，C.，Ed.，Kumar，N.，Aldrin，S.，和M.Chen，“检测多协议标签交换（MPLS）数据平面故障”，RFC 8029，DOI 10.17487/RFC8029，2017年3月<https://www.rfc-editor.org/info/rfc8029>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[IANA-MPLS-LSP-PING] IANA, "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", <https://www.iana.org/assignments/ mpls-lsp-ping-parameters/>.
[IANA-MPLS-LSP-PING]IANA，“多协议标签交换（MPLS）标签交换路径（LSP）PING参数”<https://www.iana.org/assignments/ mpls lsp ping参数/>。
[IEEE802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std. 802.1AX.
[IEEE802.1AX]IEEE，“局域网和城域网的IEEE标准-链路聚合”，IEEE标准802.1AX。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <https://www.rfc-editor.org/info/rfc6425>.
[RFC6425]Saxena，S.，Ed.，Swallow，G.，Ali，Z.，Farrel，A.，Yasukawa，S.，和T.Nadeau，“检测点对多点MPLS中的数据平面故障-LSP Ping扩展”，RFC 6425，DOI 10.17487/RFC6425，2011年11月<https://www.rfc-editor.org/info/rfc6425>.
[RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for Operating IPv6-Only MPLS Networks", RFC 7439, DOI 10.17487/RFC7439, January 2015, <https://www.rfc-editor.org/info/rfc7439>.
[RFC7439]George，W.，Ed.和C.Pignataro，Ed.，“仅运行IPv6 MPLS网络的差距分析”，RFC 7439，DOI 10.17487/RFC7439，2015年1月<https://www.rfc-editor.org/info/rfc7439>.
Several flavors of provisioning models that use a "LAG with L2 switch" and the corresponding MPLS data-plane ECMP traversal validation issues are described in this appendix.
本附录描述了几种使用“二级交换机延迟”的供应模型以及相应的MPLS数据平面ECMP遍历验证问题。
R1 ==== S1 ==== R2
R1 ==== S1 ==== R2
The issue with this LAG provisioning model is that packets traversing a LAG member from Router 1 (R1) to intermediate L2 switch (S1) can get load-balanced by S1 towards Router 2 (R2). Therefore, MPLS echo request messages traversing a specific LAG member from R1 to S1 can actually reach R2 via any of the LAG members, and the sender of the MPLS echo request messages has no knowledge of this nor any way to control this traversal. In the worst case, MPLS echo request messages with specific entropies will exercise every LAG member link from R1 to S1 and can all reach R2 via the same LAG member link. Thus, it is impossible for the MPLS echo request sender to verify that packets intended to traverse a specific LAG member link from R1 to S1 did actually traverse that LAG member link and to deterministically exercise "receive" processing of every LAG member link on R2. (Note: As far as we can tell, there's not a better option than "try a bunch of entropy labels and see what responses you can get back", and that's the same remedy in all the described topologies.)
这种滞后供应模型的问题是，从路由器1（R1）到中间L2交换机（S1）的滞后成员的数据包可以通过S1到路由器2（R2）的负载平衡。因此，从R1到S1遍历特定滞后成员的MPLS回送请求消息实际上可以通过任何滞后成员到达R2，并且MPLS回送请求消息的发送者不知道这一点，也不知道控制此遍历的任何方法。在最坏的情况下，具有特定熵的MPLS回显请求消息将执行从R1到S1的每个滞后成员链接，并且都可以通过相同的滞后成员链接到达R2。因此，MPLS echo请求发送方不可能验证打算从R1到S1遍历特定滞后成员链路的分组是否确实遍历了该滞后成员链路，并且不可能确定地对R2上的每个滞后成员链路执行“接收”处理。（注意：据我们所知，没有比“尝试一堆熵标签，看看你能得到什么样的响应”更好的选择了，在所有描述的拓扑中，这是相同的补救方法。）
____
R1 ==== S1 ==== R2
____
R1 ==== S1 ==== R2
There are deviating numbers of LAG members on the two sides of the L2 switch. The issue with this LAG provisioning model is the same as with the previous model: the sender of MPLS echo request messages has no knowledge of the L2 load-balancing algorithm nor entropy values to control the traversal.
L2开关两侧的滞后构件数量不同。此延迟供应模型的问题与前一个模型相同：MPLS回送请求消息的发送方不知道L2负载平衡算法，也不知道控制遍历的熵值。
R1 ---- S1 ==== R2
R1 ---- S1 ==== R2
The issue with this LAG provisioning model is that there is no way for an MPLS echo request sender to deterministically exercise both LAG member links from S1 to R2. And without such, "receive" processing of R2 on each LAG member cannot be verified.
这种延迟供应模型的问题是，MPLS回送请求发送方无法确定地执行从S1到R2的两个延迟成员链接。如果没有这些，则无法验证每个滞后成员上R2的“接收”处理。
R1 ==== S1 ---- R2
R1 ==== S1 ---- R2
The MPLS echo request sender has knowledge of how to traverse both LAG members from R1 to S1. However, both types of packets will terminate on the non-LAG interface at R2. It becomes impossible for the MPLS echo request sender to know that MPLS echo request messages intended to traverse a specific LAG member from R1 to S1 did indeed traverse that LAG member.
MPLS回显请求发送方知道如何从R1到S1遍历两个滞后成员。但是，这两种类型的数据包都将在R2的非滞后接口上终止。MPLS回显请求发送方不可能知道打算从R1到S1遍历特定滞后成员的MPLS回显请求消息确实遍历了该滞后成员。
Acknowledgements
致谢
The authors would like to thank Nagendra Kumar and Sam Aldrin for providing useful comments and suggestions. The authors would like to thank Loa Andersson for performing a detailed review and providing a number of comments.
作者要感谢Nagendra Kumar和Sam Aldrin提供了有用的意见和建议。作者要感谢Loa Andersson进行了详细的审查并提出了一些意见。
The authors also would like to extend sincere thanks to the MPLS RT review members who took the time to review and provide comments. The members are Eric Osborne, Mach Chen, and Yimin Shen. The suggestion by Mach Chen to generalize and create the LSR Capability TLV was tremendously helpful for this document and likely for future documents extending the MPLS LSP Ping and Traceroute mechanisms. The suggestion by Yimin Shen to create two separate validation procedures had a big impact on the contents of this document.
作者还想向MPLS RT审查成员表示诚挚的感谢，他们花时间审查并提供意见。成员包括埃里克·奥斯本、陈马赫和沈一民。Mach Chen提出的推广和创建LSR能力TLV的建议对本文档以及未来扩展MPLS LSP Ping和跟踪路由机制的文档非常有帮助。沈一民提出的创建两个独立验证程序的建议对本文件的内容产生了很大影响。
Authors' Addresses
作者地址
Nobo Akiya Big Switch Networks
Nobo Akiya大交换网络
Email: nobo.akiya.dev@gmail.com
Email: nobo.akiya.dev@gmail.com
George Swallow Southend Technical Center
乔治·斯沃恩·索森德技术中心
Email: swallow.ietf@gmail.com
Email: swallow.ietf@gmail.com
Stephane Litkowski Orange
斯蒂芬利特科夫斯基橙
Email: stephane.litkowski@orange.com
Email: stephane.litkowski@orange.com
Bruno Decraene Orange
布鲁诺橙
Email: bruno.decraene@orange.com
Email: bruno.decraene@orange.com
John E. Drake Juniper Networks
约翰·E·德雷克·杜松网络
Email: jdrake@juniper.net
Email: jdrake@juniper.net
Mach(Guoyi) Chen Huawei
马赫（国一）陈华为
Email: mach.chen@huawei.com
Email: mach.chen@huawei.com