Internet Engineering Task Force (IETF) M. Chen
Request for Comments: 7110 W. Cao
Category: Standards Track Huawei Technologies Co., Ltd
ISSN: 2070-1721 S. Ning
Tata Communications
F. Jounay
Orange CH
S. Delord
January 2014
Internet Engineering Task Force (IETF) M. Chen
Request for Comments: 7110 W. Cao
Category: Standards Track Huawei Technologies Co., Ltd
ISSN: 2070-1721 S. Ning
Tata Communications
F. Jounay
Orange CH
S. Delord
January 2014
Return Path Specified Label Switched Path (LSP) Ping
返回路径指定的标签交换路径（LSP）Ping
Abstract
摘要
This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness.
本文档定义了多协议标签交换（MPLS）标签交换路径（LSP）数据平面故障检测协议的扩展，称为“LSP ping”。这些扩展允许选择用于回显回复路径的LSP。强制执行特定的返回路径可以用于验证双向连接，还可以提高LSP ping的健壮性。
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/rfc7110.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7110.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Problem Statements and Solution Overview ........................3
3.1. Limitations of Existing Mechanisms for Bidirectional LSPs ..4
3.2. Limitations of Existing Mechanisms for Handling
Unreliable Return Paths ....................................4
4. Extensions ......................................................5
4.1. Reply via Specified Path Mode ..............................6
4.2. Reply Path (RP) TLV ........................................6
4.3. Tunnel Sub-TLVs ............................................8
4.3.1. IPv4 RSVP Tunnel Sub-TLV ...........................10
4.3.2. IPv6 RSVP Tunnel Sub-TLV ...........................11
4.3.3. Static Tunnel Sub-TLV ..............................12
4.4. Reply TC TLV ..............................................12
5. Theory of Operation ............................................13
5.1. Sending an Echo Request ...................................14
5.2. Receiving an Echo Request .................................14
5.3. Sending an Echo Reply .....................................15
5.4. Receiving an Echo Reply ...................................16
5.5. Non-IP Encapsulation for MPLS-TP LSPs .....................16
6. Security Considerations ........................................16
7. IANA Considerations ............................................17
7.1. TLVs ......................................................17
7.2. New Target FEC Stack Sub-TLVs .............................17
7.3. New Reply Mode ............................................17
7.4. Reply Path Return Code ....................................18
8. Contributors ...................................................19
9. Acknowledgements ...............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Problem Statements and Solution Overview ........................3
3.1. Limitations of Existing Mechanisms for Bidirectional LSPs ..4
3.2. Limitations of Existing Mechanisms for Handling
Unreliable Return Paths ....................................4
4. Extensions ......................................................5
4.1. Reply via Specified Path Mode ..............................6
4.2. Reply Path (RP) TLV ........................................6
4.3. Tunnel Sub-TLVs ............................................8
4.3.1. IPv4 RSVP Tunnel Sub-TLV ...........................10
4.3.2. IPv6 RSVP Tunnel Sub-TLV ...........................11
4.3.3. Static Tunnel Sub-TLV ..............................12
4.4. Reply TC TLV ..............................................12
5. Theory of Operation ............................................13
5.1. Sending an Echo Request ...................................14
5.2. Receiving an Echo Request .................................14
5.3. Sending an Echo Reply .....................................15
5.4. Receiving an Echo Reply ...................................16
5.5. Non-IP Encapsulation for MPLS-TP LSPs .....................16
6. Security Considerations ........................................16
7. IANA Considerations ............................................17
7.1. TLVs ......................................................17
7.2. New Target FEC Stack Sub-TLVs .............................17
7.3. New Reply Mode ............................................17
7.4. Reply Path Return Code ....................................18
8. Contributors ...................................................19
9. Acknowledgements ...............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................20
This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping" [RFC4379] that can be used to specify the return paths for the echo reply message, increasing the robustness of LSP ping, reducing the opportunity for error, and improving the reliability of the echo reply message. A new Reply Mode, which is referred to as "Reply via Specified Path", is added and a new Type-Length-Value (TLV), which is referred to as "Reply Path (RP) TLV", is defined in this memo. The procedures defined in this document currently only apply to "ping" mode. The "traceroute" mode is out of scope for this document.
本文件定义了多协议标签交换（MPLS）标签交换路径（LSP）数据平面故障检测协议的扩展，称为“LSP ping”[RFC4379]，可用于指定回送回复消息的返回路径，提高LSP ping的健壮性，减少出错机会，以及提高回声回复消息的可靠性。添加了一种称为“通过指定路径回复”的新回复模式，并在本备忘录中定义了一种称为“回复路径（RP）TLV”的新类型长度值（TLV）。本文件中定义的程序目前仅适用于“ping”模式。“跟踪路由”模式超出了本文档的范围。
In this document, the term bidirectional LSP includes the co-routed bidirectional LSP defined in [RFC3945] and the associated bidirectional LSP that is constructed from a pair of unidirectional LSPs (one for each direction) that are associated with one another at the LSP's ingress/egress points [RFC5654]. The mechanisms defined in this document can apply to both IP/MPLS and MPLS Transport Profile (MPLS-TP) scenarios.
在本文件中，术语双向LSP包括[RFC3945]中定义的共路由双向LSP和关联的双向LSP，该双向LSP由一对单向LSP（每个方向一个）构成，在LSP的入口/出口点[RFC5654]处彼此关联。本文档中定义的机制可以应用于IP/MPLS和MPLS传输配置文件（MPLS-TP）场景。
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]中所述进行解释。
MPLS LSP ping is defined in [RFC4379]. It can be used to detect data-path failures in all MPLS LSPs.
MPLS LSP ping在[RFC4379]中定义。它可用于检测所有MPLS LSP中的数据路径故障。
LSPs are increasingly being deployed to provide bidirectional services. The co-routed bidirectional LSP is defined in [RFC3945], and the associated bidirectional LSP is defined in [RFC5654]. With the deployment of such services, operators have a desire to test both directions of a bidirectional LSP in a single operation.
LSP越来越多地用于提供双向服务。共路由双向LSP在[RFC3945]中定义，相关联的双向LSP在[RFC5654]中定义。随着此类服务的部署，运营商希望在单个操作中测试双向LSP的两个方向。
Additionally, when testing a single direction of an LSP (either a unidirectional LSP or a single direction of a bidirectional LSP) using LSP ping, the validity of the result may be affected by the success of delivering the echo reply message. Failure to exchange these messages between the egress Label Switching Router (LSR) and the ingress LSR can lead to false negatives where the LSP under test is reported as "down" even though it is functioning correctly.
此外，当使用LSP ping测试LSP的单个方向（单向LSP或双向LSP的单个方向）时，结果的有效性可能受到回送回复消息的成功传递的影响。如果在出口标签交换路由器（LSR）和入口LSR之间未能交换这些消息，则可能导致误报，其中被测LSP被报告为“关闭”，即使其功能正常。
With the existing LSP ping mechanisms, as defined in [RFC4379], operators have to enable LSP detection on each of the two ends of a bidirectional LSP independently. This not only doubles the workload for the operators but may also bring additional difficulties when checking the backward direction of the LSP under the following condition:
使用[RFC4379]中定义的现有LSP ping机制，操作员必须独立地在双向LSP的两端启用LSP检测。这不仅使操作员的工作量增加了一倍，而且在以下情况下检查LSP的向后方向时可能会带来额外的困难：
The LSR that the operator logged on to perform the checking operations might not have out-of-band connectivity to the LSR at the far end of the LSP. That can mean it is not possible to check the return direction of a bidirectional LSP in a single operation -- the operator must log on to the LSR at the other end of the LSP to test the return direction.
操作员登录以执行检查操作的LSR可能与LSP远端的LSR没有带外连接。这可能意味着不可能在单个操作中检查双向LSP的返回方向——操作员必须登录到LSP另一端的LSR以测试返回方向。
Associated bidirectional LSPs have the same issues as those listed for co-routed bidirectional LSPs.
关联的双向LSP与为共路由双向LSP列出的问题相同。
This document defines a mechanism to allow the operator to request that both directions of a bidirectional LSP be tested by a single LSP ping message exchange.
本文档定义了一种机制，允许操作员请求通过单个LSP ping消息交换测试双向LSP的两个方向。
3.2. Limitations of Existing Mechanisms for Handling Unreliable Return Paths
3.2. 处理不可靠返回路径的现有机制的局限性
[RFC4379] defines four Reply Modes:
[RFC4379]定义了四种回复模式：
1. Do not reply 2. Reply via an IPv4/IPv6 UDP packet 3. Reply via an IPv4/IPv6 UDP packet with Router Alert 4. Reply via application level control channel
1. 不要回答2。通过IPv4/IPv6 UDP数据包进行回复3。通过路由器警报4的IPv4/IPv6 UDP数据包进行回复。通过应用程序级控制通道进行回复
Obviously, the issue of the reliability of the return path for an echo reply message does not apply in the first of these cases.
显然，回送回复消息返回路径的可靠性问题不适用于第一种情况。
[RFC4379] states that the third mode may be used when the IP return path is deemed unreliable. This mode of operation requires that all intermediate nodes support the Router Alert option and understand how to forward MPLS echo replies. This is a rigorous requirement in deployed IP/MPLS networks, especially since the return path may be through legacy IP-only routers.
[RFC4379]指出，当IP返回路径被认为不可靠时，可以使用第三种模式。此操作模式要求所有中间节点支持路由器警报选项，并了解如何转发MPLS回送回复。这在已部署的IP/MPLS网络中是一个严格的要求，特别是因为返回路径可能通过传统的纯IP路由器。
In any case, the use of Reply Modes 2 or 3 cannot guarantee the delivery of echo responses through an IP network that is fundamentally unreliable. The failure to deliver echo response messages can lead to false negatives, making it appear that the LSP has failed.
在任何情况下，回复模式2或3的使用都不能保证通过根本不可靠的IP网络发送回显响应。未能传递回显响应消息可能会导致误报，使LSP出现故障。
Allowing the ingress LSR to control the path used for echo reply messages enables an operator to apply an extra level of deterministic process to the LSP ping test. For example, when testing an LSP, Reply Mode 2 is used at the beginning but no echo reply is received. When failure of the return path is suspected, the operator can initiate another LSP ping with the Reply Mode defined in this document and specify a different return path that is deemed workable to complete the test.
允许入口LSR控制回显回复消息使用的路径使操作员能够对LSP ping测试应用额外级别的确定性过程。例如，在测试LSP时，在开始时使用应答模式2，但未收到回音应答。当怀疑返回路径出现故障时，操作员可以使用本文档中定义的应答模式启动另一个LSP ping，并指定一个被认为可用于完成测试的不同返回路径。
This document defines extensions to LSP ping that can be used to specify the return paths of the echo reply message in an echo request message.
本文档定义了LSP ping的扩展，可用于指定回显请求消息中回显回复消息的返回路径。
LSP ping, defined in [RFC4379], is carried out by sending an echo request message. It carries the Forwarding Equivalence Class (FEC) information of the LSP being tested. The FEC information indicates which MPLS path is being verified along the same data path as other normal data packets belonging to the FEC.
[RFC4379]中定义的LSP ping通过发送回显请求消息来执行。它携带被测试LSP的转发等价类（FEC）信息。FEC信息指示哪个MPLS路径正沿着与属于FEC的其他正常数据分组相同的数据路径被验证。
LSP ping [RFC4379] defines four Reply Modes that are used to direct the egress LSR in how to send back an echo reply. This document defines a new Reply Mode, the "Reply via Specified Path" mode. This new mode is used to direct the egress LSR of the tested LSP to send the echo reply message back along the path specified in the echo request message.
LSP ping[RFC4379]定义了四种应答模式，用于指导出口LSR如何发送回显应答。本文档定义了一种新的回复模式，“通过指定路径回复”模式。此新模式用于指示被测LSP的出口LSR沿echo请求消息中指定的路径发送回显回复消息。
In addition, two new TLVs, the "Reply Path (RP) TLV" and "Reply Traffic Class (TC) TLV" [RFC5462], are defined in this document. The Reply Path TLV contains one or more nested sub-TLVs that can be used to carry the specified return path information to be used by the echo reply message.
此外，本文件中还定义了两种新的TLV，即“回复路径（RP）TLV”和“回复流量等级（TC）TLV”[RFC5462]。回复路径TLV包含一个或多个嵌套子TLV，可用于承载回送回复消息要使用的指定返回路径信息。
A new Reply Mode is defined to be carried in the Reply Mode field of the echo request message.
在回显请求消息的回复模式字段中定义了一个新的回复模式。
The value of the Reply via Specified Path mode is 5 (This has been allocated by IANA using early allocation and is to be confirmed by IANA).
通过指定路径模式回复的值为5（这已由IANA使用早期分配进行分配，并由IANA确认）。
Value Meaning
----- -------
5 Reply via Specified Path
Value Meaning
----- -------
5 Reply via Specified Path
The Reply via Specified Path mode is used to request that the remote LSR receiving the echo request message sends back the echo reply message along the specified paths carried in the Reply Path TLV.
通过指定路径模式的回复用于请求接收回显请求消息的远程LSR沿着回复路径TLV中携带的指定路径发回回回显回复消息。
The Reply Path (RP) TLV is an optional TLV within the LSP ping protocol. However, if the Reply via Specified Path mode requested, as described in Section 4.1, the Reply Path (RP) TLV MUST be included in an echo request message, and its absence is treated as a malformed echo request, as described in [RFC4379]. Furthermore, if a Reply Path (RP) TLV is included in an echo request message, a Reply Path (RP) TLV MUST be included in the corresponding echo reply message sent by an implementation that is conformant to this specification.
应答路径（RP）TLV是LSP ping协议中的可选TLV。但是，如第4.1节所述，如果请求通过指定路径模式进行回复，回复路径（RP）TLV必须包含在回送请求消息中，并且其缺失被视为格式错误的回送请求，如[RFC4379]所述。此外，如果应答路径（RP）TLV包括在回显请求消息中，则应答路径（RP）TLV必须包括在由符合本规范的实现发送的相应回显应答消息中。
The Reply Path (RP) TLV carries the specified return path that the echo reply message is required to follow. The format of Reply Path TLV is as follows:
回复路径（RP）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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path return code | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path return code | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Path |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reply Path TLV
图1：回复路径TLV
Reply Path TLV Type: It is 2 octets in length, and the type value is 21.
应答路径TLV类型：长度为2个八位字节，类型值为21。
Length: It is 2 octets in length. It defines the length in octets of the Reply Path return code, Flags, and Reply Path fields.
长度：长度为2个八位字节。它定义回复路径返回代码、标志和回复路径字段的长度（以八位字节为单位）。
Reply Path return code: The Reply Path return code field is 2 octets in length. It is defined for the egress LSR of the forward LSP to report the results of Reply Path TLV processing and return path selection. This field MUST be set to zero in a Reply Path TLV carried on an echo request message and MUST be ignored on receipt. This document defines the following Reply Path return codes for inclusion in a Reply Path TLV carried on an echo reply:
回复路径返回码：回复路径返回码字段长度为2个八位字节。定义转发LSP的出口LSR报告应答路径TLV处理和返回路径选择的结果。在回送请求消息中携带的回复路径TLV中，此字段必须设置为零，并且在收到时必须忽略。本文档定义了以下回复路径返回代码，以包含在回送回复中的回复路径TLV中：
Value Meaning
------ ----------------------
0x0000 Reserved, MUST NOT be used
0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood
0x0003 The echo reply was sent successfully using the
specified Reply Path
0x0004 The specified Reply Path was not found, the echo
reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS)
path
0x0006-0xfffb Unassigned
0xfffc-0xffff Experimental Use
Value Meaning
------ ----------------------
0x0000 Reserved, MUST NOT be used
0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood
0x0003 The echo reply was sent successfully using the
specified Reply Path
0x0004 The specified Reply Path was not found, the echo
reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS)
path
0x0006-0xfffb Unassigned
0xfffc-0xffff Experimental Use
Flags: It is also 2 octets in length, it is used to notify the egress how to process the Reply Paths field when performing return path selection. The Flags field is a bit vector and has following format:
标志：长度也是2个八位字节，用于在执行返回路径选择时通知出口如何处理回复路径字段。Flags字段是位向量，具有以下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |A|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flags
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |A|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flags
A (Alternative path): the egress LSR MUST select a non-default path as the return path. This is very useful when reverse default path problems are suspected that can be confirmed when the echo reply is forced to follow a non-default return path. Here, the default path refers to the path that the egress LSR will use to send the echo reply when Reply Mode 2 or 3 is used. If A bit is set, there is no need to carry any specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD be ignored.
A（备用路径）：出口LSR必须选择非默认路径作为返回路径。这在怀疑反向默认路径问题时非常有用，当回送回复被强制遵循非默认返回路径时，可以确认反向默认路径问题。这里，默认路径是指当使用应答模式2或3时出口LSR将用于发送回显应答的路径。如果设置了位，则无需携带任何特定的应答路径子TLV，并且在收到时，应忽略子TLV。
B (Bidirectional): the return path is required to follow the reverse direction of the tested bidirectional LSP. If B bit is set, there is no need to carry any specific reply path sub-TLVs, and when received, the sub-TLVs SHOULD be ignored.
B（双向）：要求返回路径遵循被测双向LSP的相反方向。如果设置了B位，则无需携带任何特定的应答路径子TLV，并且在接收时，子TLV应被忽略。
The A flag and B flag MUST NOT both be set, otherwise, an echo reply with the RP return code set to "Malformed Reply Path TLV was received" MUST be returned.
不能同时设置A标志和B标志，否则，必须返回RP返回代码设置为“接收到格式错误的回复路径TLV”的回显回复。
Reply Path: It is used to describe the return path that an echo reply will be send along. It is variable in length and can contain zero, one or more Target FEC sub-TLVs [RFC4379]. In an echo request, it carries sub-TLVs that describe the specified path that the echo reply message is required to follow. In an echo reply, the sub-TLVs describe the FEC Stack information of the return path (when the return path is an MPLS path) that the echo reply will be sent along.
回复路径：用于描述回音回复将发送的返回路径。它的长度可变，可以包含零个、一个或多个目标FEC子TLV[RFC4379]。在回送请求中，它携带子TLV，描述回送回复消息需要遵循的指定路径。在回送回复中，子TLV描述回送回复将随之发送的返回路径（当返回路径为MPLS路径时）的FEC堆栈信息。
[RFC4379] has already defined several Target FEC sub-TLVs, the Target FEC sub-TLVs provide a good way to identify a specific return path. The Reply Path TLV can carry any (existing and future defined) sub-TLV defined for use in the Target FEC Stack TLV to specify the return path.
[RFC4379]已经定义了多个目标FEC子TLV，目标FEC子TLV提供了识别特定返回路径的好方法。回复路径TLV可以携带任何（现有和未来定义的）子TLV，该子TLV定义用于目标FEC堆栈TLV中，以指定返回路径。
This document defines three new Target FEC sub-TLVs: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static Tunnel sub-TLV. One usage of these generic RSVP Tunnel sub-TLVs is when LSP ping is used to periodically verify the control plane against the data plane [RFC5884], using a Tunnel other than a particular LSP can avoid the impact of an LSP identifier changing when Make-Before-Break (MBB) is deployed. These sub-TLVs also can be used in the Reply Path TLV to allow the operator to specify a more generic tunnel FEC other than a particular LSP as the return path.
本文档定义了三个新的目标FEC子TLV：IPv4 RSVP隧道子TLV、IPv6 RSVP隧道子TLV和静态隧道子TLV。这些通用RSVP隧道子TLV的一种用法是，当使用LSP ping定期对照数据平面验证控制平面[RFC5884]时，使用特定LSP以外的隧道可以避免在部署先通后断（MBB）时更改LSP标识符的影响。这些子TLV还可以在应答路径TLV中使用，以允许操作员指定除特定LSP之外的更通用的隧道FEC作为返回路径。
No assignments of sub-TLVs are made directly for TLV Type 21, the sub-TLV space and assignments for TLV Type 21 will be the same as that for TLV Type 1. Sub-types for TLV Type 1 and TLV Type 21 MUST be kept the same. Any new sub-type added to TLV Type 1 MUST apply to the TLV Type 21 as well.
未直接为TLV类型21分配子TLV，TLV类型21的子TLV空间和分配与TLV类型1相同。TLV类型1和TLV类型21的子类型必须保持相同。TLV类型1中添加的任何新子类型也必须适用于TLV类型21。
With the Return Path TLV flags and the sub-TLVs defined for the Target FEC Stack TLV and in this document, it could provide the following options for return paths specifying:
通过为目标FEC堆栈TLV和本文档中定义的返回路径TLV标志和子TLV，它可以为指定返回路径提供以下选项：
1. a particular LSP as return path
1. 作为返回路径的特定LSP
- use those sub-TLVs defined for the Target FEC Stack TLV
- 使用为目标FEC堆栈TLV定义的子TLV
2. a more generic tunnel FEC as return path - use the IPv4/IPv6 RSVP and Static Tunnel sub-TLVs defined in Sections Section 4.3.1, Section 4.3.2, and Section 4.3.3 of this document
2. 更通用的隧道FEC作为返回路径-使用本文档第4.3.1节、第4.3.2节和第4.3.3节中定义的IPv4/IPv6 RSVP和静态隧道子TLV
3. the reverse path of the bidirectional LSP as return path
3. 双向LSP的反向路径作为返回路径
- use B bit defined in Section 4.2 of this document.
- 使用本文件第4.2节中定义的B位。
4. Force return path to non-default path
4. 强制将路径返回到非默认路径
- use A bit defined in Section 4.2 of this document.
- 使用本文件第4.2节中定义的位。
The format of the IPv4 RSVP Tunnel sub-TLV is as follows:
IPv4 RSVP隧道子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 RSVP Tunnel Sub-TLV
图3:IPv4 RSVP隧道子TLV
The IPv4 RSVP Tunnel sub-TLV is derived from the RSVP IPv4 FEC TLV that is defined in Section 3.2.3 of [RFC4379]. All fields have the same semantics as defined in [RFC4379] except that the LSP-ID field is omitted and a new Flags field is defined.
IPv4 RSVP隧道子TLV源自[RFC4379]第3.2.3节中定义的RSVP IPv4 FEC TLV。所有字段的语义与[RFC4379]中定义的相同，只是省略了LSP-ID字段，并定义了一个新的标志字段。
The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and the recommended type value is 26.
IPv4 RSVP隧道子TLV类型字段的长度为2个八位字节，建议的类型值为26。
The Flags field is 2 octets in length, it is used to notify the egress LSR how to choose the return path. The Flags field is a bit vector and has following format:
Flags字段的长度为2个八位字节，用于通知出口LSR如何选择返回路径。Flags字段是位向量，具有以下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Tunnel Flags
图4：隧道标志
P (Primary): the return path MUST be chosen from the LSPs that belong to the specified Tunnel and the LSP MUST be the primary LSP.
P（主）：返回路径必须从属于指定隧道的LSP中选择，并且LSP必须是主LSP。
S (Secondary): the return path MUST be chosen from the LSPs that belong to the specified Tunnel and the LSP MUST be the secondary LSP. Primary and secondary LSPs are defined in [RFC4872].
S（次要）：返回路径必须从属于指定隧道的LSP中选择，并且LSP必须是次要LSP。主要和次要LSP在[RFC4872]中定义。
P bit and S bit MUST NOT both be set, otherwise, an echo reply with the RP return code set to "Malformed Reply Path TLV was received" SHOULD be returned. If P bit and S bit are both not set, the return path could be any one of the LSPs from the same Tunnel.
P bit and S bit MUST NOT both be set, otherwise, an echo reply with the RP return code set to "Malformed Reply Path TLV was received" SHOULD be returned. If P bit and S bit are both not set, the return path could be any one of the LSPs from the same Tunnel.translate error, please retry
The format of the IPv6 RSVP Tunnel sub-TLV is as follows:
IPv6 RSVP隧道子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 RSVP Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv6 RSVP Tunnel Sub-TLV
图5:IPv6 RSVP隧道子TLV
The IPv6 RSVP Tunnel sub-TLV is derived from the RSVP IPv6 FEC TLV that is defined in Section 3.2.4 of [RFC4379]. All fields have the same semantics as defined in [RFC4379] except that the LSP-ID field is omitted and a new Flags field is defined.
IPv6 RSVP隧道子TLV源自[RFC4379]第3.2.4节中定义的RSVP IPv6 FEC TLV。所有字段的语义与[RFC4379]中定义的相同，只是省略了LSP-ID字段，并定义了一个新的标志字段。
The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and the type value is 27.
IPv6 RSVP隧道子TLV类型字段的长度为2个八位字节，类型值为27。
The Flags field is 2 octets in length and is identical to that described in Section 4.3.1.
标志字段的长度为2个八位字节，与第4.3.1节中描述的相同。
The format of the Static RSVP Tunnel sub-TLV is as follows. The value fields are taken from the definitions in [RFC6370].
静态RSVP隧道子TLV的格式如下所示。值字段取自[RFC6370]中的定义。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Num | Destination Tunnel Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static Tunnel sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Num | Destination Tunnel Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Static Tunnel Sub-TLV
图6：静态隧道子TLV
The Flags field is 2 octets in length and is identical to that described in Section 4.3.1.
标志字段的长度为2个八位字节，与第4.3.1节中描述的相同。
The sub-TLV type value is 28.
子TLV类型值为28。
Reply TOS Byte TLV [RFC4379] is used by the originator of the echo request to request that an echo reply be sent with the IP header TOS byte set to the value specified in the TLV. Similarly, in this document, a new TLV, Reply TC TLV, is defined and MAY be used by the originator of the echo request to request that an echo reply be sent with the TC bits of the return path LSP set to the value specified in this TLV. The Reply TC TLV is not limited to the Reply Mode specified in this document (Reply via Specified Path) but may be used in all the other Reply Modes as well. The format of Reply TC TLV is as follows:
回复TOS字节TLV[RFC4379]由echo请求的发起人使用，请求发送回复，并将IP头TOS字节设置为TLV中指定的值。类似地，在本文档中，定义了一个新的TLV，Reply TC TLV，echo请求的发起人可以使用它来请求发送一个echo应答，并将返回路径LSP的TC位设置为该TLV中指定的值。回复TC TLV不限于本文档中指定的回复模式（通过指定路径回复），也可用于所有其他回复模式。答复TC 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply TC TLV type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | MUST be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply TC TLV type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | MUST be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Reply TC TLV
图7：答复TC TLV
The Reply TC TLV Type field is 2 octets in length, and the type value is 22.
应答TC TLV类型字段的长度为2个八位字节，类型值为22。
The Length field is 2 octets in length, the value of length field is fixed 4 octets.
长度字段的长度为2个八位字节，长度字段的值固定为4个八位字节。
The procedures defined in this document currently only apply to "ping" mode. The "traceroute" mode is out of scope for this document.
本文件中定义的程序目前仅适用于“ping”模式。“跟踪路由”模式超出了本文档的范围。
In [RFC4379], the echo reply is used to report the LSP checking result to the LSP ping initiator. This document defines a new Reply Mode and a new TLV (Reply Path TLV) that enable the LSP ping initiator to specify or constrain the return path of the echo reply. Similarly, the behavior of echo reply is extended to detect the requested return path by looking at a specified path FEC TLV. This enables LSP ping to detect failures in both directions of a path with a single operation; of course, this cuts in half the operational steps required to verify the end-to-end bidirectional connectivity and integrity of an LSP.
在[RFC4379]中，回送应答用于向LSP ping启动器报告LSP检查结果。本文档定义了一个新的回复模式和一个新的TLV（回复路径TLV），使LSP ping启动器能够指定或约束回显回复的返回路径。类似地，通过查看指定的路径FEC TLV，echo reply的行为被扩展以检测请求的返回路径。这使得LSP ping能够通过单个操作检测路径的两个方向上的故障；当然，这将验证LSP的端到端双向连接和完整性所需的操作步骤减少了一半。
When the return path is an MPLS path, the echo reply MUST carry the FEC Stack information in a Reply Path TLV to test the return MPLS LSP path. The destination IP address of the echo reply message MUST never be used in a forwarding decision. To avoid this possibility the destination IP address of the echo reply message that is transmitted along the specified return path MUST be set to numbers from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6, and the IP Time to Live (TTL) MUST be set 1, and the TTL in the outermost label MUST be set to 255.
当返回路径为MPLS路径时，回送回复必须在回复路径TLV中携带FEC堆栈信息，以测试返回的MPLS LSP路径。回送回复消息的目标IP地址决不能用于转发决策。为了避免这种可能性，必须将沿指定返回路径传输的回送回复消息的目标IP地址设置为范围127/8（IPv4）或0:0:0:0:FFFF:127.0.0.0/104（IPv6）的数字，并且IP生存时间（TTL）必须设置为1，最外层标签中的TTL必须设置为255。
When the return path is a pure IP forwarding path, the procedures defined in [RFC4379] (the destination IP address is copied from the source IP address) apply unchanged.
当返回路径是纯IP转发路径时，[RFC4379]（目标IP地址从源IP地址复制）中定义的过程将不加更改地应用。
When sending an echo request, in addition to the rules and procedures defined in Section 4.3 of [RFC4379], the Reply Mode of the echo request MUST be set to "Reply via Specified Path", and a Reply Path TLV MUST be carried in the echo request message correspondingly. The Reply Path TLV includes one or several reply path sub-TLV(s) to identify the return path(s) the egress LSR should use for its reply.
发送回送请求时，除了[RFC4379]第4.3节中定义的规则和程序外，回送请求的回复模式必须设置为“通过指定路径回复”，回送请求消息中必须相应携带回复路径TLV。应答路径TLV包括一个或多个应答路径子TLV，以标识出口LSR应用于其应答的返回路径。
For a bidirectional LSP, since the ingress LSR and egress LSR of a bidirectional LSP are aware of the relationship between the forward and backward direction LSPs, only the B bit SHOULD be set in the Reply Path TLV. If the operator wants the echo reply to be sent along a path other than the reverse direction of the bidirectional LSP, the A bit SHOULD be set or another FEC sub-TLV SHOULD be carried in the Reply Path TLV instead, and the B bit MUST be clear.
对于双向LSP，由于双向LSP的入口LSR和出口LSR知道前向和后向LSP之间的关系，因此仅应在应答路径TLV中设置B比特。如果操作员希望沿双向LSP反向以外的路径发送回波应答，则应设置a位或在应答路径TLV中携带另一FEC子TLV，且B位必须清除。
In some cases, operators may want to treat two unidirectional LSPs (one for each direction) as a pair. There may not be any binding relationship between the two LSPs. Using the mechanism defined in this document, operators can run LSP ping one time from one end to complete the failure detection on both unidirectional LSPs. To accomplish this, the echo request message MUST carry (in the Reply Path TLV) a FEC sub-TLV that belongs to the backward LSP.
在某些情况下，操作员可能希望将两个单向LSP（每个方向一个）视为一对。两个LSP之间可能没有任何绑定关系。使用本文档中定义的机制，操作员可以从一端运行LSP ping一次，以完成两个单向LSP上的故障检测。为了实现这一点，echo请求消息必须携带（在应答路径TLV中）属于后向LSP的FEC子TLV。
"Ping" mode processing, as defined in Section 4.4 of [RFC4379], applies in this document. In addition, when an echo request is received, if the egress LSR does not know the Reply Mode defined in this document, an echo reply with the return code set to "Malformed echo request received" and the Subcode set to zero will be send back to the ingress LSR according to the rules of [RFC4379]. If the egress LSR knows the Reply Mode, according to the Reply Path TLV, it SHOULD find and select the desired return path. If there is a matched path, an echo reply with a Reply Path TLV that identifies the return path SHOULD be sent back to the ingress LSR, the Reply Path return code SHOULD be set to "The echo reply was sent successfully using the specified Reply Path". If there is no such path, an echo reply with the Reply Path TLV SHOULD be sent back to the ingress LSR, the Reply Path return code SHOULD be set to the relevant code (defined in Section 4.2) for the real situation to reflect the result of Reply Path TLV processing and return path selection. For example, if the specified LSP is not found, the egress then chooses another LSP as the return path to send the echo reply, the Reply Path return code SHOULD be set to "The specified reply path was not found, the echo reply was sent via another LSP", and if the egress chooses an IP path to send the echo reply, the Reply Path return code SHOULD be set
[RFC4379]第4.4节中定义的“Ping”模式处理适用于本文件。此外，当接收到回送请求时，如果出口LSR不知道本文档中定义的回复模式，则根据[RFC4379]的规则，将返回代码设置为“收到格式错误的回送请求”且子代码设置为零的回送回复发送回入口LSR。如果出口LSR知道应答模式，根据应答路径TLV，它应该找到并选择所需的返回路径。如果存在匹配路径，则应将带有识别返回路径的回复路径TLV的回显回复发送回入口LSR，回复路径返回代码应设置为“使用指定的回复路径成功发送回显回复”。如果没有此类路径，则应将带有回复路径TLV的回音回复发送回入口LSR，回复路径返回代码应设置为真实情况下的相关代码（在第4.2节中定义），以反映回复路径TLV处理和返回路径选择的结果。例如，如果未找到指定的LSP，则出口选择另一个LSP作为发送回显回复的返回路径，回复路径返回码应设置为“未找到指定的回复路径，回显回复通过另一个LSP发送”，如果出口选择IP路径发送回显回复，应设置回复路径返回代码
to "The specified Reply Path was not found, the echo reply was sent via pure IP forwarding (non-MPLS) path". If there is an unknown sub-TLV in the received Reply Path TLV, the Reply Path return code SHOULD be set to "One or more of the sub-TLVs in the Reply Path TLV were not understood".
至“未找到指定的回复路径，回送回复通过纯IP转发（非MPLS）路径发送”。如果收到的回复路径TLV中存在未知的子TLV，则回复路径返回代码应设置为“回复路径TLV中的一个或多个子TLV未被理解”。
If the A bit of the Reply Path TLV in a received echo request message is set, the egress LSR SHOULD send the echo reply along a non-default return path.
如果已接收回显请求消息中的回复路径TLV的A位已设置，则出口LSR应沿非默认返回路径发送回显回复。
If the B bit of the Reply Path TLV in a received echo request message is set, the egress LSR SHOULD send the echo reply along the reverse direction of the bidirectional LSP.
如果设置了接收到的回显请求消息中的应答路径TLV的B位，则出口LSR应沿双向LSP的相反方向发送回显应答。
In addition, the FEC validate results of the forward path LSP SHOULD NOT affect the egress LSR continue to test return path LSP.
此外，前向路径LSP的FEC验证结果不应影响出口LSR继续测试返回路径LSP。
As described in [RFC4379], the echo reply message is a UDP packet, and it MUST be sent only in response to an MPLS echo request. The source IP address is a valid IP address of the replier, the source UDP port is the well-know UDP port for LSP ping.
如[RFC4379]所述，回送回复消息是UDP数据包，必须仅在响应MPLS回送请求时发送。源IP地址是应答器的有效IP地址，源UDP端口是众所周知的用于LSP ping的UDP端口。
When the return path is an MPLS LSP, the destination IP address of the echo reply message is copied from the destination IP address of the echo request, and the destination UDP port is copied from the source UDP port of the echo request. The IP TTL MUST be set to 1, the TTL in the outermost label MUST be set to 255.
当返回路径为MPLS LSP时，回显回复消息的目标IP地址从回显请求的目标IP地址复制，目标UDP端口从回显请求的源UDP端口复制。IP TTL必须设置为1，最外层标签中的TTL必须设置为255。
When the return path is a pure IP forwarding path, the same as defined in [RFC4379], the destination IP address and UDP port are copied from the source IP address and source UDP port of the echo request.
当返回路径是纯IP转发路径时（与[RFC4379]中的定义相同），目标IP地址和UDP端口将从echo请求的源IP地址和源UDP端口复制。
When sending the echo reply, a Reply Path TLV that identifies the return path MUST be carried, the Reply Path return code SHOULD be set to relevant code that reflects results about how the egress processes the Reply Path TLV in a previous received echo request message and return path selection. By carrying the Reply Path TLV in an echo reply, it gives the ingress LSR enough information about the reverse direction of the tested path to verify the consistency of the data plane against control plane. Thus, a single LSP ping could achieve both directions of a path test. If the return path is pure IP path, no sub-TLVs are carried in the Reply Path TLV.
发送回显回复时，必须携带标识返回路径的回复路径TLV，回复路径返回代码应设置为相关代码，以反映出出口在先前接收的回显请求消息和返回路径选择中如何处理回复路径TLV的结果。通过在回音应答中携带应答路径TLV，它向入口LSR提供有关测试路径反向的足够信息，以验证数据平面与控制平面的一致性。因此，单个LSP ping可以实现路径测试的两个方向。如果返回路径是纯IP路径，则应答路径TLV中不携带子TLV。
The rules and process defined in Section 4.6 of [RFC4379] apply here. When an echo reply is received, if the Reply Mode is "Reply via Specified Path" and the Reply Path return code is "The echo reply was sent successfully using the specified Reply Path", and if the return path is an MPLS LSP. The ingress LSR MUST perform FEC validation (based on the FEC Stack information of the return path carried in the Reply Path TLV) as an egress LSR does when receiving an echo request, the FEC validation process (relevant to "ping" mode) defined in Section 4.4.1 of [RFC4379] applies here.
[RFC4379]第4.6节中定义的规则和流程适用于此处。接收回显回复时，如果回复模式为“通过指定路径回复”，回复路径返回代码为“使用指定回复路径成功发送回显回复”，并且返回路径为MPLS LSP。入口LSR必须执行FEC验证（基于回复路径TLV中携带的返回路径的FEC堆栈信息），正如出口LSR在接收回显请求时所做的一样，[RFC4379]第4.4.1节中定义的FEC验证过程（与“ping”模式相关）适用于此。
When an echo reply is received with return code set to "Malformed echo request received" and the Subcode set to zero. It is possible that the egress LSR may not know the "Reply via Specified Path" Reply Mode, the operator may choose to re-perform another LSP ping by using one of the four Reply Modes defined [RFC4379].
接收回显回复时，返回代码设置为“收到格式错误的回显请求”，子代码设置为零。出口LSR可能不知道“通过指定路径回复”回复模式，操作员可以选择使用定义的四种回复模式之一重新执行另一个LSP ping[RFC4379]。
On receipt of an echo reply with Reply Path return code in the Reply Path TLV set to "The specified reply path was not found, ...", it means that the egress LSR could not find a matched return path as specified. Operators may choose to specify another LSP as the return path or use other methods to detect the path further.
在收到回复路径TLV中回复路径返回码设置为“未找到指定回复路径，…”的回音回复时，这意味着出口LSR无法找到指定的匹配返回路径。操作员可以选择指定另一个LSP作为返回路径，或使用其他方法进一步检测路径。
In some MPLS-TP deployment scenarios, IP addressing might not be available or the use of some form of non-IP encapsulation might be preferred. In such scenarios, the Non-IP encapsulation defined in [RFC6426] applies here. The LSP Ping Reply Mode in the echo request and echo reply is set to 5. The return path of the echo reply is as specified in the Reply Path TLV.
在某些MPLS-TP部署场景中，IP寻址可能不可用，或者可能首选使用某种形式的非IP封装。在这种情况下，[RFC6426]中定义的非IP封装适用于此处。echo请求和echo应答中的LSP Ping应答模式设置为5。回显回复的返回路径如回复路径TLV中所指定。
Security considerations discussed in [RFC4379] apply to this document.
[RFC4379]中讨论的安全注意事项适用于本文档。
In addition, the extensions defined in this document may be used for potential "proxying" attacks. For example, an echo request initiator may specify a return path that has a destination different from that of the initiator. But normally, such attacks will not happen in an MPLS domain where the initiators and receivers belong to the same domain. Even this, in order to prevent using the extension defined in this document for proxying any possible attacks, the return path LSP should have destination to the same node where the forward path is from. The receiver may drop the echo request when it cannot determine whether the return path LSP has the destination to the
此外，本文档中定义的扩展可用于潜在的“代理”攻击。例如，echo请求启动器可以指定一个返回路径，该路径的目的地与启动器的目的地不同。但通常情况下，此类攻击不会发生在发起方和接收方属于同一域的MPLS域中。即使如此，为了防止使用本文档中定义的扩展来代理任何可能的攻击，返回路径LSP的目的地应该与转发路径所在的节点相同。当接收器无法确定返回路径LSP是否具有到目标的目的地时，它可能会丢弃回显请求
initiator. That means, when sending echo request, the initiator should choose a proper source address according the specified return path LSP to help the receiver to make the decision.
发起者。这意味着，在发送回显请求时，发起方应根据指定的返回路径LSP选择适当的源地址，以帮助接收方做出决定。
IANA has assigned the value 21 for the Reply Path TLV and assigned the value 22 for Reply TC TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs" subregistry.
IANA已从“多协议标签交换体系结构（MPLS）标签交换路径（LSP）Ping参数”注册表“TLV”子区为应答路径TLV分配了值21，并为应答TC TLV分配了值22。
Value Meaning Reference
----- ------- ---------
21 Reply Path TLV this document (Section 4.2)
22 Reply TC TLV this document (Section 4.4)
Value Meaning Reference
----- ------- ---------
21 Reply Path TLV this document (Section 4.2)
22 Reply TC TLV this document (Section 4.4)
The sub-TLV space and assignments for the Reply Path TLV will be the same as that for the Target FEC Stack TLV. Sub-types for the Target FEC Stack TLV and the Reply Path TLV MUST be kept the same. Any new sub-type added to the Target FEC Stack TLV MUST apply to the Reply Path TLV as well.
应答路径TLV的子TLV空间和分配将与目标FEC堆栈TLV的子TLV空间和分配相同。目标FEC堆栈TLV和应答路径TLV的子类型必须保持相同。添加到目标FEC堆栈TLV的任何新子类型也必须应用于应答路径TLV。
IANA has assigned three new sub-TLV types from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV Types 1, 16, and 21" subregistry.
IANA已从“多协议标签交换体系结构（MPLS）标签交换路径（LSP）Ping参数-TLV”注册表中为TLV类型1、16和21分配了三个新的子TLV类型。
Sub-Type Sub-TLV Name Reference
------- ----------- ---------
26 IPv4 RSVP Tunnel this document (Section 4.3.1)
27 IPv6 RSVP Tunnel this document (Section 4.3.2)
28 Static Tunnel this document (Section 4.3.3)
Sub-Type Sub-TLV Name Reference
------- ----------- ---------
26 IPv4 RSVP Tunnel this document (Section 4.3.1)
27 IPv6 RSVP Tunnel this document (Section 4.3.2)
28 Static Tunnel this document (Section 4.3.3)
IANA has allocated (5 - Reply via Specified Path) from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, the "Reply Modes" subregistry.
IANA已从“多协议标签交换（MPLS）标签交换路径（LSPs）Ping参数”注册表“应答模式”子区分配（5-通过指定路径应答）。
Value Meaning Reference
----- ------- ----------
5 Reply via Specified Path this document (Section 4.1)
Value Meaning Reference
----- ------- ----------
5 Reply via Specified Path this document (Section 4.1)
IANA has created a new subregistry for the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" for Reply Path return codes.
IANA为应答路径返回码的“多协议标签交换（MPLS）标签交换路径（LSPs）Ping参数”创建了一个新的子区域。
This document (Section 4.2) defines the following return codes:
本文件（第4.2节）定义了以下返回代码：
Value Meaning
------ ----------------------
0x0000 No return code
0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood
0x0003 The echo reply was sent successfully using the
specified Reply Path
0x0004 The specified Reply Path was not found, the echo
reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS)
path
0x0006-0xfffb Unassigned
0xfffc-0xffff Reserved for Experimental Use
Value Meaning
------ ----------------------
0x0000 No return code
0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in the Reply Path TLV
were not understood
0x0003 The echo reply was sent successfully using the
specified Reply Path
0x0004 The specified Reply Path was not found, the echo
reply was sent via another LSP
0x0005 The specified Reply Path was not found, the echo
reply was sent via pure IP forwarding (non-MPLS)
path
0x0006-0xfffb Unassigned
0xfffc-0xffff Reserved for Experimental Use
The range of 0x0006-0xfffb is not allocated and reserved for future extensions and is allocated via Standard Action; the range of 0xfffc-0xffff is for Experimental Use.
0x0006-0xfffb的范围未分配并保留用于未来扩展，而是通过标准操作分配；0xfffc-0xffff的范围供实验使用。
The following individuals also contributed to this document:
以下个人也对本文件作出了贡献：
Ehud Doron Orckit-Corrigent EMail: ehudd@orckit.com
Ehud Doron Orkit更正电子邮件：ehudd@orckit.com
Ronen Solomon Orckit-Corrigent EMail: RonenS@orckit.com
Ronen Solomon Orkit更正电子邮件：RonenS@orckit.com
Ville Hallivuori Tellabs Sinimaentie 6 C FI-02630 Espoo, Finland EMail: ville.hallivuori@tellabs.com
Ville Hallivuori Tellabs Sinimaentie 6 C FI-02630 Espoo，芬兰电子邮件：Ville。hallivuori@tellabs.com
Xinchun Guo EMail: guoxinchun@huawei.com
郭新春电邮：guoxinchun@huawei.com
The authors would like to thank Adrian Farrel, Peter Ashwood-Smith, Sriganesh Kini, Gregory Mirsky, Eric Gray, Loa Andersson, Carlos Pignataro, and Tom Petch for their reviews, suggestions, and comments.
作者要感谢Adrian Farrel、Peter Ashwood Smith、Sriganesh Kini、Gregory Mirsky、Eric Gray、Loa Andersson、Carlos Pignataro和Tom Petch的评论、建议和评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370]Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 63702011年9月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.，Rekhter，Y.，和D.Papadimitriou，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[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月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654]Niven Jenkins，B.，Brungard，D.，Betts，M.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]Gray，E.，Bahadur，N.，Boutros，S.，和R.Aggarwal，“MPLS按需连接验证和路由跟踪”，RFC 6426，2011年11月。
Authors' Addresses
作者地址
Mach(Guoyi) Chen Huawei Technologies Co., Ltd Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Beijing 100095 China
中国北京市海淀区北青路156号华为校园Q14号马赫（国一）陈华为技术有限公司100095
EMail: mach.chen@huawei.com
EMail: mach.chen@huawei.com
Wei Cao Huawei Technologies Co., Ltd Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District Beijing 100095 China
中国北京市海淀区北青路156号华为校园Q14号威曹华为技术有限公司100095
EMail: wayne.caowei@huawei.com
EMail: wayne.caowei@huawei.com
So Ning Tata Communications
苏宁塔塔通讯
EMail: ning.so@tatacommunications.com
EMail: ning.so@tatacommunications.com
Frederic Jounay Orange CH 4 rue caudray 1020 Renens Switzerland
Frederic Jounay Orange CH 4 caudray路1020瑞士雷南
EMail: frederic.jounay@orange.ch
EMail: frederic.jounay@orange.ch
Simon Delord
西蒙·德洛德
EMail: Simon.delord@team.telstra.com
EMail: Simon.delord@team.telstra.com