Internet Engineering Task Force (IETF) S. Boutros
Request for Comments: 7394 S. Sivabalan
Category: Standards Track G. Swallow
ISSN: 2070-1721 S. Saxena
Cisco Systems
V. Manral
Ionos Networks
S. Aldrin
Huawei Technologies, Inc.
November 2014
Internet Engineering Task Force (IETF) S. Boutros
Request for Comments: 7394 S. Sivabalan
Category: Standards Track G. Swallow
ISSN: 2070-1721 S. Saxena
Cisco Systems
V. Manral
Ionos Networks
S. Aldrin
Huawei Technologies, Inc.
November 2014
Definition of Time to Live TLV for LSP-Ping Mechanisms
LSP Ping机制的生存时间TLV定义
Abstract
摘要
LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment Pseudowire (MS-PW) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of the MS-PW and/or bidirectional co-routed LSP. This document defines a TLV to address this shortcoming.
LSP Ping是MPLS网络中广泛部署的操作、管理和维护（OAM）机制。然而，在本形式中，该机制不足以验证来自MS-PW和/或双向共路由LSP路径上的任何节点的多段伪线（MS-PW）和/或双向共路由标签交换路径（LSP）的段的连接性。本文档定义了一个TLV来解决此缺陷。
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/rfc7394.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7394.
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 ....................................................2
2. Terminology .....................................................3
3. Time To Live TLV ................................................4
3.1. TTL TLV Format .............................................4
3.2. Usage ......................................................4
4. Operation .......................................................5
4.1. Traceroute Mode ............................................6
4.2. Error Scenario .............................................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................7
7. References ......................................................7
7.1. Normative References .......................................7
Acknowledgements ...................................................7
Contributors .......................................................7
Authors' Addresses .................................................8
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Time To Live TLV ................................................4
3.1. TTL TLV Format .............................................4
3.2. Usage ......................................................4
4. Operation .......................................................5
4.1. Traceroute Mode ............................................6
4.2. Error Scenario .............................................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................7
7. References ......................................................7
7.1. Normative References .......................................7
Acknowledgements ...................................................7
Contributors .......................................................7
Authors' Addresses .................................................8
An MS-PW may span across multiple service provider networks. In order to allow Service Providers (SPs) to verify segments of such MS-PWs from any node on the path of the MS-PW, any node along the path of the MS-PW, should be able to originate an MPLS Echo Request packet to any other node along the path of the MS-PW and receive the corresponding MPLS Echo Reply. If the originator of the MPLS Echo Request is at the end of a MS-PW, the receiver of the request can send the reply back to the sender without knowing the hop-count distance of the originator. The reply will be intercepted by the originator regardless of the TTL value on the reply packet. But, if the originator is not at the end of the MS-PW, the receiver of the MPLS Echo Request may need to know how many hops away the originator
MS-PW可以跨越多个服务提供商网络。为了允许服务提供商（SP）从MS-PW路径上的任何节点验证此类MS-PW的段，MS-PW路径上的任何节点都应该能够向MS-PW路径上的任何其他节点发起MPLS回送请求包，并接收相应的MPLS回送回复。如果MPLS回显请求的发起人位于MS-PW的末尾，则请求的接收方可以将应答发送回发送方，而不知道发起人的跳数距离。无论回复数据包上的TTL值如何，发起者都会截获回复。但是，如果发端人不在MS-PW的末尾，MPLS回送请求的接收器可能需要知道发端人离开了多少跳
of the MPLS Echo Request is so that it can set the TTL value on the MPLS header for the MPLS Echo Reply to be intercepted at the originator node.
MPLS回显请求的类型是，它可以在MPLS报头上设置TTL值，以便在发起方节点上拦截MPLS回显回复。
In MPLS networks, for bidirectional co-routed LSPs, if it is desired to verify connectivity from any intermediate node Label Switching Router (LSR) on the LSP to the any other LSR on the LSP the receiver may need to know the TTL to send the MPLS Echo Reply with, so as the packet is intercepted by the originator node.
在MPLS网络中，对于双向共路由LSP，如果需要验证从LSP上的任何中间节点标签交换路由器（LSR）到LSP上的任何其他LSR的连接，则接收机可能需要知道TTL以发送MPLS回音应答，以便数据包被发端节点截获。
A new optional TTL TLV is defined in this document. This TLV will be added by the originator of the MPLS Echo Request to inform the receiver how many hops away the originator is on the path of the MS-PW or bidirectional LSP.
本文档中定义了一个新的可选TTL TLV。该TLV将由MPLS回波请求的发起者添加，以通知接收器发起者在MS-PW或双向LSP路径上的跳数。
This mechanism only works if the MPLS Echo Reply is sent down the co-routed LSP; hence, the scope of this TTL TLV is currently limited to MS-PW or bidirectional co-routed MPLS LSPs. The presence of the TLV implies the use of the return path of the co-routed LSP, if the return path is any other mechanism, then the TLV in the MPLS Echo Request MUST be ignored.
此机制仅在MPLS回送回复沿共路由LSP向下发送时有效；因此，该TTL TLV的范围目前仅限于MS-PW或双向共路由MPLS LSP。TLV的存在意味着使用共同路由LSP的返回路径，如果返回路径是任何其他机制，则必须忽略MPLS回显请求中的TLV。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
LSR: Label Switching Router
标签交换路由器
MPLS-TP: MPLS Transport Profile
MPLS-TP:MPLS传输配置文件
MS-PW: Multi-Segment Pseudowire
MS-PW：多段伪导线
PW: Pseudowire
伪线
TLV: Type Length Value
TLV：类型长度值
TTL: Time To Live
TTL：生命的时刻
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32769 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32769 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Time To Live TLV Format
图1：实时TLV格式
The TTL TLV has the format shown in Figure 1.
TTL TLV的格式如图1所示。
Value
价值
The value of the TTL as specified by this TLV
此TLV指定的TTL值
Flags
旗帜
The Flags field is a bit vector with the following format:
Flags字段是具有以下格式的位向量：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One flag is defined for now, the R flag. The rest of the flags are Reserved - MUST be zero (MBZ) when sending and ignored on receipt.
现在定义了一个标志，R标志。其余标志保留-发送时必须为零（MBZ），接收时忽略。
The R flag (Reply TTL) is set signify that the value is meant to be used as the TTL for the reply packet. Other bits may be defined later to enhance the scope of this TLV.
设置R标志（应答TTL）表示该值将用作应答数据包的TTL。稍后可定义其他位以增强该TLV的范围。
The TTL TLV MAY be included in the MPLS Echo Request by the originator of the request.
TTL TLV可由请求的发起人包括在MPLS回送请求中。
If the TTL TLV is present and the receiver does not understand TTL TLVs, it will simply ignore the TLV, as is the case for all optional TLVs. If the TTL TLV is not present or is not processed by the receiver, any determination of the TTL value used in the MPLS label on the LSP-Ping echo reply is beyond the scope of this document.
如果存在TTL TLV，并且接收器不理解TTL TLV，它将简单地忽略TLV，就像所有可选TLV一样。如果TTL TLV不存在或未由接收器处理，则LSP Ping echo回复上MPLS标签中使用的TTL值的任何确定都超出了本文档的范围。
If the TTL TLV is present and the receiver understands TTL TLVs, one of the following two conditions apply:
如果TTL TLV存在且接收器理解TTL TLV，则以下两个条件之一适用：
o If the TTL TLV value field is zero, the LSP-Ping echo request packet SHOULD be dropped.
o 如果TTL TLV值字段为零，则应丢弃LSP Ping回显请求数据包。
o Otherwise, the receiver MUST use the TTL value specified in the TTL TLV when it creates the MPLS header of the MPLS Echo Reply. The TTL value in the TTL TLV takes precedence over any TTL value determined by other means, such as from the Switching Point TLV in the MS-PW. This precedence will aid the originator of the LSP-Ping echo request in analyzing the return path.
o 否则，接收器在创建MPLS回送应答的MPLS报头时，必须使用TTL TLV中指定的TTL值。TTL TLV中的TTL值优先于通过其他方式（例如从MS-PW中的开关点TLV）确定的任何TTL值。此优先级将有助于LSP Ping echo请求的发起人分析返回路径。
In this section, we explain a use case for the TTL TLV with an MPLS MS-PW.
在本节中，我们将解释一个使用MPLS MS-PW的TTL TLV用例。
<------------------MS-PW --------------------->
<------------------MS-PW --------------------->
A B C D E
o -------- o -------- o --------- o --------- o
---MPLS Echo Request--->
<--MPLS Echo Reply------
A B C D E
o -------- o -------- o --------- o --------- o
---MPLS Echo Request--->
<--MPLS Echo Reply------
Figure 2: Use-Case with MS-PWs
图2：MS PWs的用例
Let us assume an MS-PW going through LSRs A, B, C, D, and E. Furthermore, assume that an operator wants to perform a connectivity check between B and D, from B. Thus, an MPLS Echo Request with the TTL TLV is originated from B and sent towards D. The MPLS Echo Request packet contains the FEC of the PW Segment between C and D. The value field of the TTL TLV and the TTL field of the MPLS label are set to 2, the choice of the value 2 will be based on the operator input requesting the MPLS Echo Request or from the optional LDP switching point TLV. The MPLS Echo Request is intercepted at D because of TTL expiry. D detects the TTL TLV in the request and uses the TTL value (i.e., 2) specified in the TLV on the MPLS label of the MPLS Echo Reply. The MPLS Echo Reply will be intercepted by B because of TTL expiry.
让我们假设一个MS-PW通过LSR A、B、C、D和E。此外，假设一个操作员希望从B执行B和D之间的连接检查。因此，带有TTL TLV的MPLS回显请求从B发起并发送到D。MPLS回显请求包包含C和D之间PW段的FEC。TTL TLV的值字段和MPLS标签的TTL字段设置为2，值2的选择将基于请求MPLS回波请求或来自可选LDP交换点TLV的操作员输入。由于TTL过期，MPLS回显请求在D处被截获。D检测请求中的TTL TLV，并在MPLS回送应答的MPLS标签上使用TLV中指定的TTL值（即2）。由于TTL过期，MPLS回显回复将被B截获。
The same operation will apply when we have a co-routed bidirectional LSP and we want to check connectivity from an intermediate LSR "B" to another LSR "D".
当我们有一个共同路由的双向LSP并且我们想要检查从中间LSR“B”到另一个LSR“D”的连接时，同样的操作也将适用。
In traceroute mode, the TTL value in the TLV is set to 1 for the first Echo Request, then to 2 for the next, and so on. This is similar to the TTL values used for the label set on the packet.
在跟踪路由模式下，TLV中的TTL值对于第一个回显请求设置为1，然后对于下一个回显请求设置为2，依此类推。这类似于用于数据包上标签集的TTL值。
It is possible that the MPLS Echo Request packet was intercepted before the intended destination for reasons other than label TTL expiry. This could be due to network faults, misconfiguration, or other reasons. In such cases, if the return TTL is set to the value specified in the TTL TLV, then the echo response packet will continue beyond the originating node. This becomes a security issue.
MPLS回送请求数据包可能是由于标签TTL过期以外的原因而在预期目的地之前被截获的。这可能是由于网络故障、配置错误或其他原因造成的。在这种情况下，如果将返回TTL设置为TTL TLV中指定的值，则回波响应数据包将继续超出发起节点。这成为一个安全问题。
To prevent this, the label TTL value used in the MPLS Echo Reply packet MUST be modified by deducting the incoming label TTL on the received packet from TTL TLV value. If the MPLS Echo Request packet is punted to the CPU before the incoming label TTL is deducted, then another 1 MUST be added. In other words:
为了防止这种情况，必须通过从TTL TLV值中减去接收到的数据包上的传入标签TTL来修改MPLS回送回复数据包中使用的标签TTL值。如果在扣除传入标签TTL之前将MPLS回显请求数据包推送到CPU，则必须再添加一个1。换言之：
Return TTL Value on the MPLS Echo Reply packet = (TTL TLV Value) -
(Incoming Label TTL) + 1
Return TTL Value on the MPLS Echo Reply packet = (TTL TLV Value) -
(Incoming Label TTL) + 1
This document allows the setting of the TTL value in the MPLS Label of an MPLS Echo Reply, so that it can be intercepted by an intermediate device. This can cause a device to get a lot of LSP-Ping packets that get redirected to the CPU.
本文档允许在MPLS回送应答的MPLS标签中设置TTL值，以便中间设备可以拦截该值。这会导致设备获取大量LSP Ping数据包，这些数据包被重定向到CPU。
However, the same is possible even without the changes mentioned in this document. A device should rate limit the LSP-Ping packets redirected to the CPU so that the CPU is not overwhelmed.
但是，即使没有本文档中提到的更改，也可以进行相同的操作。设备应该对重定向到CPU的LSP Ping数据包进行速率限制，以使CPU不会过载。
The recommendation in the Security Considerations of [RFC4379] applies, to check the source address of the MPLS Echo Request; however, the source address can now be any node along the LSP path.
[RFC4379]的安全注意事项中的建议适用于检查MPLS回送请求的源地址；但是，源地址现在可以是LSP路径上的任何节点。
A faulty transit node changing the TTL TLV value could make the wrong node reply to the MPLS Echo Request, and/or the wrong node to receive the MPLS Echo Reply. An LSP trace may help identify the faulty transit node.
错误的传输节点更改TTL TLV值可能导致错误的节点回复MPLS回送请求，和/或错误的节点接收MPLS回送回复。LSP跟踪可能有助于识别故障的传输节点。
IANA has assigned a TLV type value to the following TLV from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "TLVs" subregistry.
IANA已从“TLV”子区中的“多协议标签交换（MPLS）标签交换路径（LSP）Ping参数”注册表为以下TLV分配了TLV类型值。
Time To Live TLV (see Section 3).
生存时间TLV（见第3节）。
IANA has allocated the value 32769.
IANA已分配值32769。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月<http://www.rfc-editor.org/info/rfc4379>.
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 50852007年12月<http://www.rfc-editor.org/info/rfc5085>.
Acknowledgements
致谢
The authors would like to thank Greg Mirsky for his comments.
作者要感谢格雷格·米尔斯基的评论。
Contributors
贡献者
Michael Wildt Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 United States EMail: mwildt@cisco.com
Michael Wildt Cisco Systems，Inc.美国马萨诸塞州伯斯堡马萨诸塞大道1414号邮编01719电子邮件：mwildt@cisco.com
Authors' Addresses
作者地址
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 United States EMail: sboutros@cisco.com
Sami Boutros Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3750号，邮编95134电子邮件：sboutros@cisco.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada EMail: msiva@cisco.com
Siva Sivabalan Cisco Systems，Inc.加拿大安大略省卡纳塔市创新大道2000号K2K 3E8电子邮件：msiva@cisco.com
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 United States EMail: swallow@cisco.com
George Swallow Cisco Systems，Inc.地址：美国马萨诸塞州Boxborough市比弗布鲁克路300号邮编：01719电子邮件：swallow@cisco.com
Shaleen Saxena Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 United States EMail: ssaxena@cisco.com
Shaleen Saxena Cisco Systems，Inc.美国马萨诸塞州博克斯堡马萨诸塞大道1414号邮编01719电子邮件：ssaxena@cisco.com
Vishwas Manral Ionos Networks 4100 Moorpark Ave, Suite 122 San Jose, CA 95117 United States EMail: vishwas@ionosnetworks.com
Vishwas Manral Ionos Networks 4100 Moorpark Ave，122号套房，加利福尼亚州圣何塞，美国95117电子邮件：vishwas@ionosnetworks.com
Sam Aldrin Huawei Technologies, Inc. 1188 Central Express Way, Santa Clara, CA 95051 United States EMail: aldrin.ietf@gmail.com
Sam Aldrin Huawei Technologies，Inc.美国加利福尼亚州圣克拉拉中央高速公路1188号，邮编95051电子邮件：Aldrin。ietf@gmail.com