Internet Engineering Task Force (IETF) N. Bahadur
Request for Comments: 6424 K. Kompella
Updates: 4379 Juniper Networks, Inc.
Category: Standards Track G. Swallow
ISSN: 2070-1721 Cisco Systems
November 2011
Internet Engineering Task Force (IETF) N. Bahadur
Request for Comments: 6424 K. Kompella
Updates: 4379 Juniper Networks, Inc.
Category: Standards Track G. Swallow
ISSN: 2070-1721 Cisco Systems
November 2011
Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels
在MPLS隧道上执行标签交换路径Ping（LSP Ping）的机制
Abstract
摘要
This document describes methods for performing LSP ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS Label Switched Paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a new TLV that, along with other procedures outlined in this document, can be used to trace such LSPs.
本文档描述了在MPLS隧道上执行LSP ping（在RFC 4399中指定）跟踪路由和缝合MPLS标签交换路径（LSP）跟踪路由的方法。RFC 4379中概述的技术不足以对通过其他MPLS隧道的LSP或缝合LSP执行跟踪路由转发等效类（FEC）验证和路径发现。本文件反对下游映射TLV（在RFC 4399中定义），支持新的TLV，该TLV与本文件中概述的其他程序一起可用于跟踪此类LSP。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6424.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6424.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Summary of Changes . . . . . . . . . . . . . . . . . . . . 5
3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Return Code per Downstream . . . . . . . . . . . . . . 6
3.2.2. Return Code for Stitched LSPs . . . . . . . . . . . . 6
3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 7
3.3.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1.1. Multipath Data Sub-TLV . . . . . . . . . . . . . . 9
3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 13
4. Performing MPLS Traceroute on Tunnels . . . . . . . . . . . . 13
4.1. Transit Node Procedure . . . . . . . . . . . . . . . . . . 13
4.1.1. Addition of a New Tunnel . . . . . . . . . . . . . . . 13
4.1.2. Transition between Tunnels . . . . . . . . . . . . . . 14
4.1.3. Modification to FEC Validation Procedure on Transit . 16
4.2. Modification to FEC Validation Procedure on Egress . . . . 16
4.3. Ingress Node Procedure . . . . . . . . . . . . . . . . . . 17
4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 17
4.3.1.1. Stack Change Sub-TLV Not Present . . . . . . . . . 17
4.3.1.2. Stack Change Sub-TLV(s) Present . . . . . . . . . 17
4.3.2. Modifications to Handling a Return Code 3 Reply. . . . 19
4.3.3. Handling of New Return Codes . . . . . . . . . . . . . 19
4.4. Handling Deprecated Downstream Mapping TLV . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Summary of Changes . . . . . . . . . . . . . . . . . . . . 5
3.2. New Return Codes . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Return Code per Downstream . . . . . . . . . . . . . . 6
3.2.2. Return Code for Stitched LSPs . . . . . . . . . . . . 6
3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 7
3.3.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1.1. Multipath Data Sub-TLV . . . . . . . . . . . . . . 9
3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 13
4. Performing MPLS Traceroute on Tunnels . . . . . . . . . . . . 13
4.1. Transit Node Procedure . . . . . . . . . . . . . . . . . . 13
4.1.1. Addition of a New Tunnel . . . . . . . . . . . . . . . 13
4.1.2. Transition between Tunnels . . . . . . . . . . . . . . 14
4.1.3. Modification to FEC Validation Procedure on Transit . 16
4.2. Modification to FEC Validation Procedure on Egress . . . . 16
4.3. Ingress Node Procedure . . . . . . . . . . . . . . . . . . 17
4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 17
4.3.1.1. Stack Change Sub-TLV Not Present . . . . . . . . . 17
4.3.1.2. Stack Change Sub-TLV(s) Present . . . . . . . . . 17
4.3.2. Modifications to Handling a Return Code 3 Reply. . . . 19
4.3.3. Handling of New Return Codes . . . . . . . . . . . . . 19
4.4. Handling Deprecated Downstream Mapping TLV . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 22
This documents describes methods for performing LSP ping (specified in [RFC4379]) traceroute over MPLS tunnels. The techniques in [RFC4379] outline a traceroute mechanism that includes Forwarding Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP) path discovery. Those mechanisms are insufficient and do not provide details when the FEC being traced traverses one or more MPLS tunnels and when Label Switched Path (LSP) stitching [RFC5150] is in use. This document deprecates the Downstream Mapping TLV [RFC4379], introducing instead a new TLV that is more extensible and that enables retrieval of detailed information. Using the new TLV format along with the existing definitions of [RFC4379], this document describes procedures by which a traceroute request can correctly traverse MPLS tunnels with proper FEC and label validations.
本文档描述了通过MPLS隧道执行LSP ping（在[RFC4379]中指定）跟踪路由的方法。[RFC4379]中的技术概述了跟踪路由机制，该机制包括转发等价类（FEC）验证和等成本多路径（ECMP）路径发现。当被跟踪的FEC穿过一个或多个MPLS隧道时，以及当使用标签交换路径（LSP）缝合[RFC5150]时，这些机制是不够的，并且没有提供细节。本文档不推荐下游映射TLV[RFC4379]，而是引入了一个新的TLV，该TLV更具扩展性，能够检索详细信息。使用新的TLV格式以及[RFC4379]的现有定义，本文档描述了跟踪路由请求可以通过适当的FEC和标签验证正确穿越MPLS隧道的过程。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An LSP ping traceroute may cross multiple MPLS tunnels en route to the destination. Let us consider a simple case.
LSP ping跟踪路由可以在到达目的地的途中跨越多个MPLS隧道。让我们考虑一个简单的例子。
A B C D E
o -------- o -------- o --------- o --------- o
\_____/ | \______/ \______/ | \______/
LDP | RSVP RSVP | LDP
| |
\____________________/
LDP
A B C D E
o -------- o -------- o --------- o --------- o
\_____/ | \______/ \______/ | \______/
LDP | RSVP RSVP | LDP
| |
\____________________/
LDP
Figure 1: LDP over RSVP Tunnel
图1:RSVP隧道上的LDP
When a traceroute is initiated from router A, router B returns downstream mapping information for node C in the MPLS echo reply. The next MPLS echo request reaches router C with an LDP FEC. Node C is a pure RSVP node and does not run LDP. Node C will receive the MPLS echo request with two labels but only one FEC in the Target FEC stack. Consequently, node C will be unable to perform a complete FEC validation. It will let the trace continue by just providing next-hop information based on the incoming label, and by looking up the forwarding state associated with that label. However, ignoring FEC validation defeats the purpose of control-plane validations. The
当从路由器a启动跟踪路由时，路由器B在MPLS回送应答中返回节点C的下游映射信息。下一个MPLS回波请求通过LDP FEC到达路由器C。节点C是纯RSVP节点，不运行LDP。节点C将接收带有两个标签的MPLS回显请求，但目标FEC堆栈中只有一个FEC。因此，节点C将无法执行完整的FEC验证。它只需根据传入标签提供下一跳信息，并查找与该标签关联的转发状态，就可以继续跟踪。然而，忽略FEC验证会破坏控制平面验证的目的。这个
MPLS echo request should contain sufficient information to allow node C to perform FEC validations to catch any misrouted echo requests.
MPLS回显请求应包含足够的信息，以允许节点C执行FEC验证以捕获任何错误路由的回显请求。
The above problem can be extended for a generic case of hierarchical tunnels or stitched tunnels (e.g., B-C can be a separate RSVP tunnel and C-D can be a separate RSVP tunnel). The problem of FEC validation for tunnels can be solved if the transit routers (router B in the above example) provide some information to the ingress regarding the start of a new tunnel.
上述问题可以扩展到分层隧道或缝合隧道的一般情况（例如，B-C可以是单独的RSVP隧道，C-D可以是单独的RSVP隧道）。如果传输路由器（上例中的路由器B）向入口提供关于新隧道开始的一些信息，则可以解决隧道的FEC验证问题。
Stitched LSPs involve two or more LSP segments stitched together. The LSP segments can be signaled using the same or different signaling protocols. In order to perform an end-to-end trace of a stitched LSP, the ingress needs to know FEC information regarding each of the stitched LSP segments. For example, consider the figure below.
缝合LSP包括两个或多个缝合在一起的LSP段。LSP段可以使用相同或不同的信令协议来信令。为了执行缝合LSP的端到端跟踪，入口需要知道关于每个缝合LSP段的FEC信息。例如，考虑下面的数字。
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
Figure 2: Stitched LSP
图2：缝合LSP
Consider ingress (A) tracing end-to-end stitched LSP A--F. When an MPLS echo request reaches router C, there is a FEC stack change happening at router C. With current LSP ping [RFC4379] mechanisms, there is no way to convey this information to A. Consequently, when the next echo request reaches router D, router D will know nothing about the LDP FEC that A is trying to trace.
考虑入口（a）跟踪端到端拼接LSP A- F。当MPLS回波请求到达路由器C时，在路由器C上发生FEC堆栈变化。用当前的LSP ping [RCF439]机制，无法将该信息传送给A。因此，当下一个回声请求到达路由器D时，路由器D对A试图跟踪的LDP FEC一无所知。
Thus, the procedures defined in [RFC4379] do not make it possible for the ingress node to:
因此，[RFC4379]中定义的程序不允许入口节点：
1. Know that tunneling has occurred.
1. 知道隧道已经发生了。
2. Trace the path of the tunnel.
2. 追踪隧道的路径。
3. Trace the path of stitched LSPs.
3. 跟踪缝合LSP的路径。
In many cases, there is a need to associate additional data in the MPLS echo reply. In most cases, the additional data needs to be associated on a per-downstream-neighbor basis. Currently, the MPLS echo reply contains one Downstream Mapping TLV (DSMAP) per downstream
在许多情况下，需要在MPLS回送应答中关联其他数据。在大多数情况下，需要根据每个下游邻居关联附加数据。目前，MPLS回送应答每个下游包含一个下游映射TLV（DSMAP）
neighbor. However, the DSMAP format is not extensible; hence, it is not possible to associate more information with a downstream neighbor. This document defines a new extensible format for the DSMAP and provides mechanisms for solving the tunneled LSP ping problem using the new format. In summary, this document makes the following TLV changes:
邻居但是，DSMAP格式不可扩展；因此，不可能将更多信息与下游邻居关联。本文档为DSMAP定义了一种新的可扩展格式，并提供了使用新格式解决隧道LSP ping问题的机制。总之，本文件对TLV进行了以下更改：
o Addition of new Downstream Detailed Mapping TLV (DDMAP).
o 新增下游详细测绘TLV（DDMAP）。
o Deprecation of existing Downstream Mapping TLV (DSMAP).
o 现有下游映射TLV（DSMAP）的弃用。
o Addition of Downstream FEC stack change sub-TLV to DDMAP.
o 将下游FEC堆栈更改子TLV添加到DDMAP。
A new Return Code is being defined "See DDM TLV for Return Code and Return Subcode" (Section 6.3) to indicate that the Return Code is per Downstream Detailed Mapping TLV (Section 3.3). This Return Code MUST be used only in the message header and MUST be set only in the MPLS echo reply message. If the Return Code is set in the MPLS echo request message, then it MUST be ignored. When this Return Code is set, each Downstream Detailed Mapping TLV MUST have an appropriate Return Code and Return Subcode. This Return Code MUST be used when there are multiple downstreams for a given node (such as Point to Multipoint (P2MP) or Equal Cost Multi-Path (ECMP)), and the node needs to return a Return Code/Return Subcode for each downstream. This Return Code MAY be used even when there is only one downstream for a given node.
正在定义一个新的返回代码“返回代码和返回子代码见DDM TLV”（第6.3节），以表明返回代码符合下游详细映射TLV（第3.3节）。此返回码只能在消息头中使用，并且只能在MPLS回送回复消息中设置。如果在MPLS回显请求消息中设置了返回码，则必须忽略它。设置此返回代码时，每个下游详细映射TLV必须具有适当的返回代码和返回子代码。当给定节点存在多个下游（如点对多点（P2MP）或等成本多路径（ECMP））时，必须使用此返回码，并且节点需要为每个下游返回一个返回码/返回子码。即使给定节点只有一个下游，也可以使用此返回码。
When a traceroute is being performed on stitched LSPs (Section 4.1.2), the stitching point SHOULD indicate the stitching action to the node performing the trace. This is done by setting the Return Code to "Label switched with FEC change" (Section 6.3). If a node is performing FEC hiding, then it MAY choose to set the Return Code to a value (specified in [RFC4379]) other than "Label switched with FEC change". The Return Code "Label switched with FEC change" MUST NOT be used if no FEC stack sub-TLV (Section 3.3.1.3) is present in the Downstream Detailed Mapping TLV(s). This new Return Code MAY be used for hierarchical LSPs (for indicating the start or end of an outer LSP).
在缝合LSP上执行追踪路由时（第4.1.2节），缝合点应向执行追踪的节点指示缝合动作。这是通过将返回代码设置为“使用FEC更改切换标签”（第6.3节）来实现的。如果节点正在执行FEC隐藏，那么它可以选择将返回码设置为一个值（在[RFC4379]中指定），而不是“使用FEC更改切换标签”。如果下游详细映射TLV中不存在FEC堆栈子TLV（第3.3.1.3节），则不得使用返回代码“随FEC变更切换的标签”。此新返回码可用于分层LSP（用于指示外部LSP的开始或结束）。
Type # Value Field
------ ------------
Type # Value Field
------ ------------
20 Downstream Detailed Mapping
20下游详细测绘
The Downstream Detailed Mapping object is a TLV that MAY be included in an MPLS echo request message. Only one Downstream Detailed Mapping object may appear in an echo request. The presence of a Downstream Detailed Mapping object is a request that Downstream Detailed Mapping objects be included in the MPLS echo reply. If the replying router is the destination (Label Edge Router) of the FEC, then a Downstream Detailed Mapping TLV SHOULD NOT be included in the MPLS echo reply. Otherwise, the replying router SHOULD include a Downstream Detailed Mapping object for each interface over which this FEC could be forwarded.
下游详细映射对象是可能包括在MPLS回送请求消息中的TLV。回送请求中只能出现一个下游详细映射对象。下游详细映射对象的存在是在MPLS回送应答中包括下游详细映射对象的请求。如果应答路由器是FEC的目的地（标签边缘路由器），则MPLS回送应答中不应包括下游详细映射TLV。否则，应答路由器应包括每个接口的下游详细映射对象，该FEC可通过该接口转发。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Sub-tlv Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Return Subcode| Sub-tlv Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Downstream Detailed Mapping TLV
图3：下游详细地图TLV
The Downstream Detailed Mapping TLV format is derived from the Downstream Mapping TLV format. The key change is that variable length and optional fields have been converted into sub-TLVs. The fields have the same use and meaning as in [RFC4379]. A summary of the fields taken from the Downstream Mapping TLV is as below:
下游详细映射TLV格式源自下游映射TLV格式。关键的变化是可变长度和可选字段已转换为子TLV。这些字段的用途和含义与[RFC4379]中的相同。下游映射TLV中的字段汇总如下：
Maximum Transmission Unit (MTU)
最大传输单位（MTU）
The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the interface to the Downstream Label Switching Router (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.
地址类型指示接口是否已编号。它还确定下游IP地址和下游接口字段的长度。
DS Flags
DS标志
The DS Flags field is a bit vector of various flags.
DS Flags字段是各种标志的位向量。
Downstream Address and Downstream Interface Address
下游地址和下游接口地址
IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets. For details regarding setting the address value, refer to [RFC4379].
IPv4地址和接口索引以4个八位字节编码；IPv6地址编码为16个八位字节。有关设置地址值的详细信息，请参阅[RFC4379]。
The newly added sub-TLVs and their fields are as described below.
新添加的子TLV及其字段如下所述。
Return Code
返回码
The Return Code is set to zero by the sender. The receiver can set it to one of the values specified in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry.
发送方将返回代码设置为零。接收器可以将其设置为“多协议标签交换（MPLS）标签交换路径（LSPs）Ping参数”注册表、“返回码”子注册表中指定的值之一。
If the receiver sets a non-zero value of the Return Code field in the Downstream Detailed Mapping TLV, then the receiver MUST also set the Return Code field in the echo reply header to "See DDM TLV for Return Code and Return Subcode" (Section 6.3). An exception to this is if the receiver is a bud node [RFC4461] and is replying as both an egress and a transit node with a Return Code of 3 ("Replying router is an egress for the FEC at stack-depth <RSC>") in the echo reply header.
如果接收机在下游详细映射TLV中设置了非零值的返回码字段，则接收机还必须将回波应答报头中的返回码字段设置为“返回码和返回子码见DDM TLV”（第6.3节）。例外情况是，如果接收器是bud节点[RFC4461]，并且在回音应答报头中以出口和传输节点的身份应答，返回代码为3（“应答路由器是堆栈深度处FEC的出口<RSC>）。
If the Return Code of the echo reply message is not set to either "See DDM TLV for Return Code and Return Subcode" (Section 6.3) or "Replying router is an egress for the FEC at stack-depth <RSC>", then the Return Code specified in the Downstream Detailed Mapping TLV MUST be ignored.
如果回送回复消息的返回码未设置为“请参阅DDM TLV以了解返回码和返回子码”（第6.3节）或“回复路由器是堆栈深度<RSC>处FEC的出口”，则必须忽略下游详细映射TLV中指定的返回码。
Return Subcode
返回子码
The Return Subcode is set to zero by the sender. The receiver can set it to one of the values specified in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry. This field is filled in with the stack-depth for those codes that specify the stack-depth. For all other codes, the Return Subcode MUST be set to zero.
发送方将返回子代码设置为零。接收器可以将其设置为“多协议标签交换（MPLS）标签交换路径（LSPs）Ping参数”注册表、“返回码”子注册表中指定的值之一。此字段由指定堆栈深度的代码的堆栈深度填充。对于所有其他代码，返回子代码必须设置为零。
If the Return Code of the echo reply message is not set to either "See DDM TLV for Return Code and Return Subcode" (Section 6.3) or "Replying router is an egress for the FEC at stack-depth <RSC>", then the Return Subcode specified in the Downstream Detailed Mapping TLV MUST be ignored.
如果回送回复消息的返回码未设置为“请参阅DDM TLV了解返回码和返回子码”（第6.3节）或“回复路由器是堆栈深度<RSC>处FEC的出口”，则必须忽略下游详细映射TLV中指定的返回子码。
Sub-tlv Length
子tlv长度
Total length in bytes of the sub-TLVs associated with this TLV.
与此TLV关联的子TLV的总长度（字节）。
This section defines the sub-TLVs that MAY be included as part of the Downstream Detailed Mapping TLV.
本节定义了子TLV，该子TLV可作为下游详细映射TLV的一部分。
Sub-Type Value Field
--------- ------------
1 Multipath data
2 Label stack
3 FEC stack change
Sub-Type Value Field
--------- ------------
1 Multipath data
2 Label stack
3 FEC stack change
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multipath Type | Multipath Length |Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (Multipath Information) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multipath Type | Multipath Length |Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (Multipath Information) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Multipath Sub-TLV
图4：多路径子TLV
The multipath data sub-TLV includes Multipath Information. The sub-TLV fields and their usage is as defined in [RFC4379]. A brief summary of the fields is as below:
多路径数据子TLV包括多路径信息。子TLV字段及其用法如[RFC4379]中所定义。这些字段的简要摘要如下：
Multipath Type
多路径类型
The type of the encoding for the Multipath Information.
多路径信息的编码类型。
Multipath Length
多径长度
The length in octets of the Multipath Information.
多路径信息的长度（以八位字节为单位）。
MBZ
MBZ
MUST be set to zero when sending; MUST be ignored on receipt.
发送时必须设置为零；必须在收到时忽略。
Multipath Information
多路径信息
Encoded multipath data, according to the Multipath Type.
根据多路径类型编码的多路径数据。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Label Stack Sub-TLV
图5：标签堆栈子TLV
The Label stack sub-TLV contains the set of labels in the label stack as it would have appeared if this router were forwarding the packet through this interface. Any Implicit Null labels are explicitly included. The number of label/protocol pairs present in the sub-TLV is determined based on the sub-TLV data length. The label format and protocol type are as defined in [RFC4379]. When the Downstream Detailed Mapping TLV is sent in the echo reply, this sub-TLV MUST be included.
标签堆栈子TLV包含标签堆栈中的标签集，如果此路由器通过此接口转发数据包，则会出现标签集。任何隐式空标签都会显式包含。子TLV中存在的标签/协议对的数量根据子TLV数据长度确定。标签格式和协议类型如[RFC4379]中所定义。在回送回复中发送下游详细映射TLV时，必须包括该子TLV。
Downstream Label
下游标签
A Downstream label is 24 bits, in the same format as an MPLS label minus the Time to Live (TTL) field, i.e., the MSBit of the label is bit 0, the LSBit is bit 19, the Traffic Class (TC) field [RFC5462] is bits 20-22, and S is bit 23. The replying router SHOULD fill in the TC field and S bit; the LSR receiving the echo reply MAY choose to ignore these.
下游标签为24位，格式与MPLS标签减去生存时间（TTL）字段相同，即标签的MSBit为位0，LSBit为位19，流量类别（TC）字段[RFC5462]为位20-22，S为位23。应答路由器应填写TC字段和S位；接收回音应答的LSR可以选择忽略这些。
Protocol
协议
This specifies the label distribution protocol for the Downstream label.
这指定下游标签的标签分发协议。
A router MUST include the FEC stack change sub-TLV when the downstream node in the echo reply has a different FEC Stack than the FEC Stack received in the echo request. One or more FEC stack change sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The format is as below.
当echo应答中的下游节点具有与echo请求中接收的FEC堆栈不同的FEC堆栈时，路由器必须包括FEC堆栈更改子TLV。一个或多个FEC堆栈改变子TLV可存在于下游详细映射TLV中。格式如下。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address Type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. FEC TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address Type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. FEC TLV .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FEC Stack Change Sub-TLV
图6:FEC堆栈更改子TLV
Operation Type
操作类型
The operation type specifies the action associated with the FEC stack change. The following operation types are defined:
操作类型指定与FEC堆栈更改关联的操作。定义了以下操作类型：
Type # Operation
------ ---------
1 Push
2 Pop
Type # Operation
------ ---------
1 Push
2 Pop
Address Type
地址类型
The Address Type indicates the remote peer's address type. The Address Type is set to one of the following values. The length of the peer address is determined based on the address type. The address type MAY be different from the address type included in the Downstream Detailed Mapping TLV. This can happen when the LSP goes over a tunnel of a different address family. The address type MAY be set to Unspecified if the peer address is either unavailable or the transit router does not wish to provide it for security or administrative reasons.
地址类型指示远程对等方的地址类型。地址类型设置为以下值之一。对等地址的长度根据地址类型确定。地址类型可能不同于下游详细映射TLV中包含的地址类型。当LSP通过不同地址族的隧道时，可能会发生这种情况。如果对等地址不可用或传输路由器出于安全或管理原因不希望提供，则可以将地址类型设置为“未指定”。
Type # Address Type Address length
------ ------------ --------------
Type # Address Type Address length
------ ------------ --------------
0 Unspecified 0 1 IPv4 4 2 IPv6 16
0未指定0 1 IPv4 4 2 IPv6 16
FEC TLV Length
TLV长度
Length in bytes of the FEC TLV.
FEC TLV的字节长度。
Reserved
含蓄的
This field is reserved for future use and MUST be set to zero.
此字段保留供将来使用，必须设置为零。
Remote Peer Address
远程对等地址
The remote peer address specifies the remote peer that is the next-hop for the FEC being currently traced. For example, in the LDP over RSVP case in Figure 1, router B would respond back with the address of router D as the remote peer address for the LDP FEC being traced. This allows the ingress node to provide information regarding FEC peers. If the operation type is PUSH, the remote peer address is the address of the peer from which the FEC being pushed was learned. If the operation type is POP, the remote peer address MAY be set to Unspecified.
远程对等地址指定当前跟踪的FEC的下一跳的远程对等。例如，在图1中的LDP over RSVP情况下，路由器B将以路由器D的地址作为正在跟踪的LDP FEC的远程对等地址进行响应。这允许入口节点提供关于FEC对等点的信息。如果操作类型为推送，则远程对等地址是从中学习被推送的FEC的对等地址。如果操作类型为POP，则远程对等地址可能设置为未指定。
For upstream-assigned labels [RFC5331], an operation type of POP will have a remote peer address (the upstream node that assigned the label) and this SHOULD be included in the FEC stack change sub-TLV. The remote peer address MAY be set to Unspecified if the address needs to be hidden.
对于上游分配的标签[RFC5331]，POP的操作类型将具有远程对等地址（分配标签的上游节点），这应包括在FEC堆栈更改子TLV中。如果需要隐藏远程对等地址，则可以将该地址设置为“未指定”。
FEC TLV
FEC-TLV
The FEC TLV is present only when the FEC-tlv length field is non-zero. The FEC TLV specifies the FEC associated with the FEC stack change operation. This TLV MAY be included when the operation type is POP. It MUST be included when the operation type is PUSH. The FEC TLV contains exactly one FEC from the list of FECs specified in [RFC4379]. A Nil FEC MAY be associated with a PUSH operation if the responding router wishes to hide the details of the FEC being pushed.
仅当FEC TLV长度字段为非零时，FEC TLV才存在。FEC TLV指定与FEC堆栈更改操作关联的FEC。当操作类型为POP时，可包括该TLV。当操作类型为“推送”时，必须包含该选项。FEC TLV仅包含[RFC4379]中指定的FEC列表中的一个FEC。如果响应路由器希望隐藏被推送的FEC的细节，则Nil FEC可与推送操作相关联。
FEC stack change sub-TLV operation rules are as follows:
FEC堆栈更改子TLV操作规则如下：
a. A FEC stack change sub-TLV containing a PUSH operation MUST NOT be followed by a FEC stack change sub-TLV containing a POP operation.
a. 包含推送操作的FEC堆栈更改子TLV后面不得紧跟包含POP操作的FEC堆栈更改子TLV。
b. One or more POP operations MAY be followed by one or more PUSH operations.
b. 一个或多个POP操作之后可能会有一个或多个推送操作。
c. One FEC stack change sub-TLV MUST be included per FEC stack change. For example, if 2 labels are going to be pushed, then one FEC stack change sub-TLV MUST be included for each FEC.
c. 每次FEC堆栈更改必须包括一个FEC堆栈更改子TLV。例如，如果要推送2个标签，则必须为每个FEC包含一个FEC堆栈更改子TLV。
d. A FEC splice operation (an operation where one FEC ends and another FEC starts, see Figure 7) MUST be performed by including a POP type FEC stack change sub-TLV followed by a PUSH type FEC stack change sub-TLV.
d. FEC拼接操作（一个FEC结束另一个FEC开始的操作，见图7）必须通过包括POP型FEC堆栈更改子TLV，然后是推送型FEC堆栈更改子TLV来执行。
e. A Downstream detailed mapping TLV containing only one FEC stack change sub-TLV with Pop operation is equivalent to IS_EGRESS (Return Code 3, [RFC4379]) for the outermost FEC in the FEC stack. The ingress router performing the MPLS traceroute MUST treat such a case as an IS_EGRESS for the outermost FEC.
e. 仅包含一个具有Pop操作的FEC堆栈更改子TLV的下游详细映射TLV相当于FEC堆栈中最外层FEC的is_出口（返回代码3，[RFC4379]）。执行MPLS跟踪路由的入口路由器必须将这种情况视为最外层FEC的IS_出口。
This document deprecates the Downstream Mapping TLV. LSP ping procedures should now use the Downstream Detailed Mapping TLV. Detailed procedures regarding interoperability between the deprecated TLV and the new TLV are specified in Section 4.4.
本文档不推荐下游映射TLV。LSP ping程序现在应使用下游详细映射TLV。第4.4节规定了有关弃用TLV和新TLV之间互操作性的详细程序。
This section describes the procedures to be followed by an LSP ingress node and LSP transit nodes when performing MPLS traceroute over MPLS tunnels.
本节描述在MPLS隧道上执行MPLS跟踪路由时，LSP入口节点和LSP传输节点将遵循的过程。
A transit node (Figure 1) knows when the FEC being traced is going to enter a tunnel at that node. Thus, it knows about the new outer FEC. All transit nodes that are the origination point of a new tunnel SHOULD add the FEC stack change sub-TLV (Section 3.3.1.3) to the Downstream Detailed Mapping TLV (Figure 3) in the echo reply. The transit node SHOULD add one FEC stack change sub-TLV of operation type PUSH, per new tunnel being originated at the transit node.
传输节点（图1）知道被跟踪的FEC何时将进入该节点的隧道。因此，它知道新的外部FEC。作为新隧道起点的所有运输节点应将FEC堆栈变更子TLV（第3.3.1.3节）添加到回声回复中的下游详细映射TLV（图3）。对于在传输节点发起的每个新隧道，传输节点应添加一个操作类型为PUSH的FEC堆栈更改子TLV。
A transit node that sends a Downstream FEC stack change sub-TLV in the echo reply SHOULD fill the address of the remote peer; which is the peer of the current LSP being traced. If the transit node does not know the address of the remote peer, it MUST set the address type to Unspecified.
在回波应答中发送下游FEC堆栈更改子TLV的传输节点应填写远程对等方的地址；它是正在跟踪的当前LSP的对等方。如果传输节点不知道远程对等方的地址，则必须将地址类型设置为“未指定”。
The Label stack sub-TLV MUST contain one additional label per FEC being PUSHed. The label MUST be encoded as per Figure 5. The label value MUST be the value used to switch the data traffic. If the tunnel is a transparent pipe to the node, i.e. the data-plane trace will not expire in the middle of the new tunnel, then a FEC stack change sub-TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD NOT contain a label corresponding to the hidden tunnel.
标签堆栈子TLV必须为每个正在推送的FEC包含一个附加标签。标签必须按照图5进行编码。标签值必须是用于切换数据流量的值。如果隧道是节点的透明管道，即数据平面迹线不会在新隧道的中间过期，那么不应该添加FEC堆栈改变子TLV，并且标签堆栈子TLV不应该包含对应于隐藏隧道的标签。
If the transit node wishes to hide the nature of the tunnel from the ingress of the echo request, then it MAY not want to send details about the new tunnel FEC to the ingress. In such a case, the transit node SHOULD use the Nil FEC. The echo reply would then contain a FEC stack change sub-TLV with operation type PUSH and a Nil FEC. The value of the label in the Nil FEC MUST be set to zero. The remote peer address type MUST be set to Unspecified. The transit node SHOULD add one FEC stack change sub-TLV of operation type PUSH, per new tunnel being originated at the transit node. The Label stack sub-TLV MUST contain one additional label per FEC being PUSHed. The label value MUST be the value used to switch the data traffic.
如果传输节点希望对echo请求的入口隐藏隧道的性质，那么它可能不希望向入口发送关于新隧道FEC的详细信息。在这种情况下，传输节点应该使用Nil FEC。然后，echo应答将包含操作类型为PUSH的FEC堆栈更改子TLV和Nil FEC。Nil FEC中标签的值必须设置为零。远程对等地址类型必须设置为未指定。对于在传输节点发起的每个新隧道，传输节点应添加一个操作类型为PUSH的FEC堆栈更改子TLV。标签堆栈子TLV必须为每个正在推送的FEC包含一个附加标签。标签值必须是用于切换数据流量的值。
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
A B C D E F
o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP
Figure 7: Stitched LSPs
图7：缝合LSP
In the above figure, we have three separate LSP segments stitched at C and D. Node C SHOULD include two FEC stack change sub-TLVs. One with a POP operation for the LDP FEC and one with the PUSH operation for the BGP FEC. Similarly, node D SHOULD include two FEC stack change sub-TLVs, one with a POP operation for the BGP FEC and one with a PUSH operation for the RSVP FEC. Nodes C and D SHOULD set the Return Code to "Label switched with FEC change" (Section 6.3) to indicate change in FEC being traced.
在上图中，我们在C和D处缝合了三个单独的LSP段。节点C应包括两个FEC堆栈更改子TLV。一个用于LDP FEC的POP操作，另一个用于BGP FEC的PUSH操作。类似地，节点D应该包括两个FEC堆栈更改子tlv，一个用于BGP FEC的POP操作，另一个用于RSVP FEC的PUSH操作。节点C和D应将返回代码设置为“使用FEC变更进行标签切换”（第6.3节），以指示正在跟踪的FEC变更。
If node C wishes to perform FEC hiding, it SHOULD respond back with two FEC stack change sub-TLVs, one POP followed by one PUSH. The POP operation MAY either exclude the FEC TLV (by setting the FEC TLV length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH
如果节点C希望执行FEC隐藏，它应该使用两个FEC堆栈更改子TLV进行响应，一个POP，然后一个PUSH。POP操作可以排除FEC TLV（通过将FEC TLV长度设置为0），或者将FEC TLV设置为包含LDP FEC。推动
operation SHOULD have the FEC TLV containing the Nil FEC. The Return Code SHOULD be set to "Label switched with FEC change".
操作应具有包含Nil FEC的FEC TLV。返回代码应设置为“标签随FEC变化而切换”。
If node C performs FEC hiding and node D also performs FEC hiding, then node D MAY choose to not send any FEC stack change sub-TLVs in the echo reply since the number of labels has not changed (for the downstream of node D) and the FEC type also has not changed (Nil FEC). In such a case, node D MUST NOT set the Return Code to "Label switched with FEC change". If node D performs FEC hiding, then node F will respond as IS_EGRESS for the Nil FEC. The ingress (node A) will know that IS_EGRESS corresponds to the end-to-end LSP.
如果节点C执行FEC隐藏，而节点D也执行FEC隐藏，则节点D可以选择在回送应答中不发送任何FEC堆栈更改子TLV，因为标签的数量没有改变（对于节点D的下游），并且FEC类型也没有改变（Nil FEC）。在这种情况下，节点D不得将返回代码设置为“使用FEC更改进行标签切换”。如果节点D执行FEC隐藏，则节点F将对Nil FEC按原样进行响应。入口（节点A）将知道IS_出口对应于端到端LSP。
A B C D E F
o -------- o -------- o --------- o --------- o --------- o
\_____/ |\____________________/ |\_______/
LDP |\ RSVP-A | LDP
| \_______________________________/|
| RSVP-B |
\________________________________/
LDP
A B C D E F
o -------- o -------- o --------- o --------- o --------- o
\_____/ |\____________________/ |\_______/
LDP |\ RSVP-A | LDP
| \_______________________________/|
| RSVP-B |
\________________________________/
LDP
Figure 8: Hierarchical LSPs
图8：分层LSP
In the above figure, we have an end-to-end LDP LSP between nodes A and F. The LDP LSP goes over RSVP LSP RSVP-B. LSP RSVP-B itself goes over another RSVP LSP RSVP-A. When node A initiates a traceroute for the end-to-end LDP LSP, then following sequence of FEC stack change sub-TLVs will be performed
在上图中，我们在节点A和F之间有一个端到端LDP LSP。LDP LSP经过RSVP LSP RSVP-B。LSP RSVP-B本身经过另一个RSVP LSP RSVP-A。当节点A为端到端LDP LSP启动跟踪路由时，将执行以下FEC堆栈更改子TLV序列
Node B:
节点B：
Respond with two FEC stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.
使用两个FEC堆栈更改子TLV进行响应：推送RSVP-B，推送RSVP-A。
Node D:
节点D：
Respond with Return Code 3 when RSVP-A is the top of FEC stack. When the echo request contains RSVP-B as top of stack, respond with Downstream information for node E and an appropriate Return Code.
当RSVP-A是FEC堆栈的顶部时，用返回代码3进行响应。当echo请求包含RSVP-B作为栈顶时，使用节点E的下游信息和适当的返回码进行响应。
If node B is performing tunnel hiding, then:
如果节点B正在执行隧道隐藏，则：
Node B:
节点B：
Respond with two FEC stack change sub-TLVs: PUSH Nil FEC, PUSH Nil FEC.
使用两个FEC堆栈更改子TLV进行响应：PUSH Nil FEC，PUSH Nil FEC。
Node D:
节点D：
If D determines that the Nil FEC corresponds to RSVP-A, which terminates at D, then it SHOULD respond with Return Code 3. D can also respond with FEC stack change sub-TLV: POP (since D knows that number of labels towards next-hop is decreasing). Both responses would be valid.
如果D确定Nil FEC对应于RSVP-A，RSVP-A终止于D，那么它应该用返回代码3进行响应。D还可以响应FEC堆栈更改子TLV:POP（因为D知道下一跳的标签数量正在减少）。这两种回答都是有效的。
A B C D E F G
o -------- o -------- o ------ o ------ o ----- o ----- o
LDP LDP BGP \ RSVP RSVP / LDP
\_____________/
LDP
A B C D E F G
o -------- o -------- o ------ o ------ o ----- o ----- o
LDP LDP BGP \ RSVP RSVP / LDP
\_____________/
LDP
Figure 9: Stitched Hierarchical LSPs
图9：缝合层次LSP
In the above case, node D will send three FEC stack change sub-TLVs. One POP (for the BGP FEC) followed by two PUSHes (one for LDP and one for RSVP). Nodes C and D SHOULD set the Return Code to "Label switched with FEC change" (Section 6.3) to indicate change in FEC being traced.
在上述情况下，节点D将发送三个FEC堆栈更改子TLV。一次POP（用于BGP FEC）之后是两次推送（一次用于LDP，一次用于RSVP）。节点C和D应将返回代码设置为“使用FEC变更进行标签切换”（第6.3节），以指示正在跟踪的FEC变更。
Section 4.4 of [RFC4379] specifies Target FEC stack validation procedures. This document enhances the FEC validation procedures as follows. If the outermost FEC of the target FEC stack is the Nil FEC, then the node MUST skip the target FEC validation completely. This is to support FEC hiding, in which the outer hidden FEC can be the Nil FEC.
[RFC4379]第4.4节规定了目标FEC堆栈验证程序。本文件增强了FEC验证程序，如下所示。如果目标FEC堆栈的最外层FEC是Nil FEC，则节点必须完全跳过目标FEC验证。这是为了支持FEC隐藏，其中外部隐藏的FEC可以是Nil FEC。
Section 4.4 of [RFC4379] specifies Target FEC stack validation procedures. This document enhances the FEC validation procedures as follows. If the outermost FEC of the Target FEC stack is the Nil FEC, then the node MUST skip the target FEC validation completely. This is to support FEC hiding, in which the outer hidden FEC can be the Nil FEC.
[RFC4379]第4.4节规定了目标FEC堆栈验证程序。本文件增强了FEC验证程序，如下所示。如果目标FEC堆栈的最外层FEC是Nil FEC，则节点必须完全跳过目标FEC验证。这是为了支持FEC隐藏，其中外部隐藏的FEC可以是Nil FEC。
It is the responsibility of an ingress node to understand tunnel within tunnel semantics and LSP stitching semantics when performing a MPLS traceroute. This section describes the ingress node procedure based on the kind of reply an ingress node receives from a transit node.
在执行MPLS跟踪路由时，入口节点负责理解隧道内隧道语义和LSP缝合语义。本节基于入口节点从传输节点接收的回复类型描述入口节点过程。
Downstream Detailed Mapping TLV should be processed in the same way as the Downstream Mapping TLV, defined in Section 4.4 of [RFC4379]. This section describes the procedures for processing the new elements introduced in this document.
下游详细测绘TLV的处理方式应与[RFC4379]第4.4节中定义的下游测绘TLV相同。本节描述了处理本文档中介绍的新元素的过程。
This would be the default behavior as described in [RFC4379]. The ingress node MUST perform MPLS echo reply processing as per the procedures in [RFC4379].
这将是[RFC4379]中描述的默认行为。入口节点必须按照[RFC4379]中的程序执行MPLS回送回复处理。
If one or more FEC stack change sub-TLVs (Section 3.3.1.3) are received in the MPLS echo reply, the ingress node SHOULD process them and perform some validation.
如果在MPLS回送应答中接收到一个或多个FEC堆栈更改子TLV（第3.3.1.3节），则入口节点应处理它们并执行一些验证。
The FEC stack changes are associated with a downstream neighbor and along a particular path of the LSP. Consequently, the ingress will need to maintain a FEC stack per path being traced (in case of multipath). All changes to the FEC stack resulting from the processing of FEC stack change sub-TLV(s) should be applied only for the path along a given downstream neighbor. The following algorithm should be followed for processing FEC stack change sub-TLVs.
FEC堆栈改变与下游邻居关联，并且沿着LSP的特定路径。因此，入口将需要在跟踪的每条路径上保持FEC堆栈（在多路径情况下）。由于FEC堆栈更改子TLV的处理而导致的FEC堆栈的所有更改应仅应用于沿给定下游邻居的路径。处理FEC堆栈更改子TLV时，应遵循以下算法。
push_seen = FALSE fec_stack_depth = current-depth-of-fec-stack-being-traced saved_fec_stack = current_fec_stack
push_seen=FALSE fec_stack_depth=正在跟踪的fec stack的当前深度保存的fec_stack=当前的fec_stack
while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv))
而（子tlv=获取下一个子tlv（下游详细地图）
if (sub-tlv == NULL) break
如果（子tlv==NULL）中断
if (sub-tlv.type == FEC-Stack-Change) {
if (sub-tlv.type == FEC-Stack-Change) {
if (sub-tlv.operation == POP) {
if (push_seen) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (sub-tlv.operation == POP) {
if (push_seen) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
Pop FEC from FEC stack being traced
fec_stack_depth--;
}
Pop FEC from FEC stack being traced
fec_stack_depth--;
}
if (sub-tlv.operation == PUSH) {
push_seen = 1
Push FEC on FEC stack being traced
fec_stack_depth++;
}
}
}
if (sub-tlv.operation == PUSH) {
push_seen = 1
Push FEC on FEC stack being traced
fec_stack_depth++;
}
}
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
if (fec_stack_depth == 0) {
Drop the echo reply
current_fec_stack = saved_fec_stack
return
}
Figure 10: FEC Stack Change Sub-TLV Processing Guideline
图10:FEC堆栈更改子TLV处理指南
The next MPLS echo request along the same path should use the modified FEC stack obtained after processing the FEC stack change sub-TLVs. A non-Nil FEC guarantees that the next echo request along the same path will have the Downstream Detailed Mapping TLV validated for IP address, Interface address, and label stack mismatches.
沿同一路径的下一个MPLS回波请求应使用在处理FEC堆栈更改子TLV后获得的修改后的FEC堆栈。非Nil FEC保证沿同一路径的下一个echo请求将验证下游详细映射TLV的IP地址、接口地址和标签堆栈不匹配。
If the top of the FEC stack is a Nil FEC and the MPLS echo reply does not contain any FEC stack change sub-TLVs, then it does not necessarily mean that the LSP has not started traversing a different tunnel. It could be that the LSP associated with the Nil FEC terminated at a transit node and at the same time a new LSP started at the same transit node. The Nil FEC would now be associated with the new LSP (and the ingress has no way of knowing this). Thus, it is not possible to build an accurate hierarchical LSP topology if a traceroute contains Nil FECs.
如果FEC堆栈的顶部是Nil FEC，并且MPLS echo reply不包含任何FEC堆栈更改子tlv，那么这并不一定意味着LSP没有开始穿越不同的隧道。可能是与Nil FEC相关联的LSP在传输节点处终止，同时新LSP在同一传输节点处启动。Nil FEC现在将与新LSP相关联（入口无法知道这一点）。因此，如果跟踪路由包含Nil FEC，则不可能构建准确的分层LSP拓扑。
4.3.2. Modifications to Handling a Return Code 3 Reply.
4.3.2. 处理返回代码3回复的修改。
The procedures above allow the addition of new FECs to the original FEC being traced. Consequently, a reply from a downstream node with Return Code 3 (IS_EGRESS) may not necessarily be for the FEC being traced. It could be for one of the new FECs that was added. On receipt of an IS_EGRESS reply, the LSP ingress should check if the depth of Target FEC sent to the node that just responded, was the same as the depth of the FEC that was being traced. If it was not, then it should pop an entry from the Target FEC stack and resend the request with the same TTL (as previously sent). The process of popping a FEC is to be repeated until either the LSP ingress receives a non-IS_EGRESS reply or until all the additional FECs added to the FEC stack have already been popped. Using an IS_EGRESS reply, an ingress can build a map of the hierarchical LSP structure traversed by a given FEC.
上述程序允许在跟踪的原始FEC中添加新的FEC。因此，来自下游节点的返回代码为3（IS_出口）的应答不一定是针对被跟踪的FEC的。这可能是因为添加了一种新的FEC。在收到IS_出口回复后，LSP入口应检查发送到刚刚响应的节点的目标FEC的深度是否与正在跟踪的FEC的深度相同。如果不是，那么它应该从目标FEC堆栈中弹出一个条目，并使用相同的TTL重新发送请求（与之前发送的相同）。弹出FEC的过程将重复，直到LSP入口接收到非is_出口回复，或者直到添加到FEC堆栈的所有附加FEC已经弹出。使用IS_出口回复，入口可以构建给定FEC所遍历的分层LSP结构的映射。
When the MPLS echo reply Return Code is "Label switched with FEC change" (Section 3.2.2), the ingress node SHOULD manipulate the FEC stack as per the FEC stack change sub-TLVs contained in the downstream detailed mapping TLV. A transit node can use this Return Code for stitched LSPs and for hierarchical LSPs. In case of ECMP or P2MP, there could be multiple paths and Downstream Detailed Mapping TLVs with different Return Codes (Section 3.2.1). The ingress node should build the topology based on the Return Code per ECMP path/P2MP branch.
当MPLS回显回复返回码为“标签切换FEC更改”（第3.2.2节）时，入口节点应根据下游详细映射TLV中包含的FEC堆栈更改子TLV操作FEC堆栈。中转节点可以将此返回代码用于缝合LSP和分层LSP。对于ECMP或P2MP，可能有多条路径和下游详细映射TLV，返回代码不同（第3.2.1节）。入口节点应根据每个ECMP path/P2MP分支的返回代码构建拓扑。
The Downstream Mapping TLV has been deprecated. Applications should now use the Downstream Detailed Mapping TLV. The following procedures SHOULD be used for backward compatibility with routers that do not support the Downstream Detailed Mapping TLV.
下游映射TLV已被弃用。应用程序现在应该使用下游详细映射TLV。以下程序应用于与不支持下游详细映射TLV的路由器的向后兼容性。
o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV MUST never be sent together in the same MPLS echo request or in the same MPLS echo reply.
o 下游映射TLV和下游详细映射TLV不得在同一MPLS回送请求或同一MPLS回送回复中一起发送。
o If the echo request contains a Downstream Detailed Mapping TLV and the corresponding echo reply contains a Return Code 2 ("One or more of the TLVs was not understood"), then the sender of the echo request MAY resend the echo request with the Downstream Mapping TLV (instead of the Downstream Detailed Mapping TLV). In cases where a detailed reply is needed, the sender can choose to ignore the router that does not support the Downstream Detailed Mapping TLV.
o 如果回送请求包含下游详细映射TLV，并且相应的回送回复包含返回代码2（“一个或多个TLV未被理解”），则回送请求的发送方可以使用下游映射TLV（而不是下游详细映射TLV）重新发送回送请求。在需要详细回复的情况下，发送方可以选择忽略不支持下游详细映射TLV的路由器。
o If the echo request contains a Downstream Mapping TLV, then a Downstream Detailed Mapping TLV MUST NOT be sent in the echo reply. This is to handle the case that the sender of the echo request does not support the new TLV. The echo reply MAY contain Downstream Mapping TLV(s).
o 如果回送请求包含下游映射TLV，则回送回复中不得发送下游详细映射TLV。这是为了处理回显请求的发送方不支持新TLV的情况。回波应答可能包含下游映射TLV。
o If echo request forwarding is in use (such that the echo request is processed at an intermediate LSR and then forwarded on), then the intermediate router is responsible for making sure that the TLVs being used among the ingress, intermediate and destination are consistent. The intermediate router MUST NOT forward an echo request or an echo reply containing a Downstream Detailed Mapping TLV if it itself does not support that TLV.
o 如果正在使用回送请求转发（这样回送请求在中间LSR处处理，然后在上转发），则中间路由器负责确保入口、中间和目的地之间使用的TLV是一致的。如果中间路由器本身不支持包含下游详细映射TLV的回显请求或回显回复，则中间路由器不得转发该回显请求或回显回复。
1. If a network operator wants to prevent tracing inside a tunnel, one can use the Pipe Model [RFC3443], i.e., hide the outer MPLS tunnel by not propagating the MPLS TTL into the outer tunnel (at the start of the outer tunnel). By doing this, MPLS traceroute packets will not expire in the outer tunnel and the outer tunnel will not get traced.
1. 如果网络运营商想要阻止隧道内的跟踪，可以使用管道模型[RFC3443]，即通过不将MPLS TTL传播到外部隧道（在外部隧道的开始处）来隐藏外部MPLS隧道。通过这样做，MPLS跟踪路由数据包不会在外部隧道中过期，也不会跟踪外部隧道。
2. If one doesn't wish to expose the details of the new outer LSP, then the Nil FEC can be used to hide those details. Using the Nil FEC ensures that the trace progresses without false negatives and all transit nodes (of the new outer tunnel) perform some minimal validations on the received MPLS echo requests.
2. 如果不希望公开新的外部LSP的细节，那么可以使用Nil FEC来隐藏这些细节。使用Nil FEC可以确保跟踪过程不会出现误报，并且（新外部隧道的）所有传输节点都会对接收到的MPLS回波请求执行一些最小的验证。
Other security considerations, as discussed in [RFC4379], are also applicable to this document.
[RFC4379]中讨论的其他安全注意事项也适用于本文件。
IANA has assigned a TLV type value to the following TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry.
IANA已从“多协议标签交换体系结构（MPLS）标签交换路径（LSP）Ping参数”注册表、“TLV和子TLV”子注册表为以下TLV分配了TLV类型值。
Downstream Detailed Mapping TLV (see Section 3.3): 20.
下游详细测绘TLV（见第3.3节）：20。
IANA has registered the Sub-Type field of Downstream Detailed Mapping TLV. The valid range for this is 0-65535. Assignments in the range 0-16383 and 32768-49161 are made via Standards Action as defined in [RFC3692]; assignments in the range 16384-31743 and 49162-64511 are made via Specification Required [RFC4379]; values in the range 31744- 32767 and 64512-65535 are for Vendor Private Use, and MUST NOT be allocated. If a 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 Enterprise Code, in network octet order. The rest of the Value field is private to the vendor.
IANA已注册下游详细映射TLV的子类型字段。有效范围为0-65535。0-16383和32768-49161范围内的分配通过[RFC3692]中定义的标准行动进行；16384-31743和49162-64511范围内的分配通过所需规范[RFC4379]进行；31744-32767和64512-65535范围内的值供供应商私人使用，不得分配。如果子TLV的类型在供应商专用范围内，则长度必须至少为4，并且前四个八位字节必须是该供应商的SMI企业代码，以网络八位字节顺序排列。值字段的其余部分是供应商专有的。
IANA has assigned the following sub-TLV types (see Section 3.3.1):
IANA分配了以下子TLV类型（见第3.3.1节）：
Multipath data: 1
多路径数据：1
Label stack: 2
标签堆栈：2
FEC stack change: 3
FEC堆栈更改：3
IANA has assigned new Return Code values from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "Return Codes" sub-registry, as follows using a Standards Action value.
IANA已使用标准操作值从“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表、“返回代码”子注册表分配了新的返回代码值，如下所示。
Value Meaning
----- -------
14 See DDM TLV for Return Code and Return Subcode
15 Label switched with FEC change
Value Meaning
----- -------
14 See DDM TLV for Return Code and Return Subcode
15 Label switched with FEC change
The authors would like to thank Yakov Rekhter and Adrian Farrel for their suggestions on the document.
作者要感谢雅科夫·雷克特和阿德里安·法雷尔对该文件的建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]Yasukawa，S.，“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 51502008年2月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
Authors' Addresses
作者地址
Nitin Bahadur Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US
Nitin Bahadur Juniper Networks，Inc.美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号，邮编94089
Phone: +1 408 745 2000
EMail: nitinb@juniper.net
URI: www.juniper.net
Phone: +1 408 745 2000
EMail: nitinb@juniper.net
URI: www.juniper.net
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 US
Kireeti Kompella Juniper Networks，Inc.美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号，邮编94089
Phone: +1 408 745 2000
EMail: kireeti@juniper.net
URI: www.juniper.net
Phone: +1 408 745 2000
EMail: kireeti@juniper.net
URI: www.juniper.net
George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 US
美国马萨诸塞州伯斯堡马萨诸塞大道1414号George Swallow思科系统公司01719
EMail: swallow@cisco.com
URI: www.cisco.com
EMail: swallow@cisco.com
URI: www.cisco.com