Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 7746 Juniper Networks
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
M. Conn
D. Pacella
L. Tomotaki
Verizon
January 2016
Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 7746 Juniper Networks
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
M. Conn
D. Pacella
L. Tomotaki
Verizon
January 2016
Label Switched Path (LSP) Self-Ping
标签交换路径（LSP）自Ping
Abstract
摘要
When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.
当实施某些RSVP-TE优化时，入口标签交换路由器（LSRs）可以在所有下游节点上安装转发状态之前接收RSVP RESV消息。根据RSVP-TE规范，入口LSR一收到RESV消息就可以通过标签交换路径（LSP）转发流量。但是，如果入口LSR在所有下游节点上安装转发状态之前通过LSP转发流量，则流量可能会丢失。
This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.
本文档介绍LSP自ping。当入口LSR接收到RESV消息时，它可以调用LSP自ping过程，以确保在所有下游节点上安装了转发状态。
LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.
LSP自ping是一种新的协议。它不是LSP Ping的扩展。尽管LSP Ping和LSP Self Ping的名称相似，但它们都是为一个独特的目的而设计的。每个协议在自己的UDP端口上侦听并执行自己的过程。
LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.
LSP自ping是一种非常轻量级的机制。它不会在中转或出口LSR上消耗控制平面资源。
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. 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/rfc7746.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7746.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 6
4. LSP Self-Ping Procedures . . . . . . . . . . . . . . . . . . 7
5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Rejected Approaches . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 6
4. LSP Self-Ping Procedures . . . . . . . . . . . . . . . . . . 7
5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Rejected Approaches . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Ingress Label Switching Routers (LSRs) use RSVP-TE [RFC3209] to establish MPLS Label Switched Paths (LSPs). The following paragraphs describe RSVP-TE procedures.
入口标签交换路由器（LSR）使用RSVP-TE[RFC3209]建立MPLS标签交换路径（LSP）。以下段落描述了RSVP-TE程序。
The ingress LSR calculates a path between itself and an egress LSR. The calculated path can be either strictly or loosely routed. Having calculated a path, the ingress LSR constructs an RSVP PATH message. The PATH message includes an Explicit Route Object (ERO) that represents the path between the ingress and egress LSRs.
入口LSR计算其自身和出口LSR之间的路径。计算出的路径可以是严格路由，也可以是松散路由。计算路径后，入口LSR构造RSVP路径消息。路径消息包括表示入口和出口LSR之间的路径的显式路由对象（ERO）。
The ingress LSR forwards the PATH message towards the egress LSR, following the path defined by the ERO. Each transit LSR that receives the PATH message executes admission control procedures. If the transit LSR admits the LSP, it sends the PATH message downstream, to the next node in the ERO.
入口LSR按照ERO定义的路径将路径消息转发到出口LSR。接收路径消息的每个传输LSR都执行准入控制过程。如果运输LSR允许LSP，它会向下游发送PATH消息到ERO中的下一个节点。
When the egress LSR receives the PATH message, it binds a label to the LSP. The label can be implicit null, explicit null, or non-null. The egress LSR then installs forwarding state (if necessary) and constructs an RSVP RESV message. The RESV message contains a Label Object that includes the label that has been bound to the LSP.
当出口LSR接收到PATH消息时，它将标签绑定到LSP。标签可以是隐式null、显式null或非null。出口LSR然后安装转发状态（如有必要）并构造RSVP RESV消息。RESV消息包含一个标签对象，其中包含已绑定到LSP的标签。
The egress LSR sends the RESV message upstream towards the ingress LSR. The RESV message visits the same transit LSRs that the PATH message visited, in reverse order. Each transit LSR binds a label to the LSP, updates its forwarding state, and updates the RESV message. As a result, the Label Object in the RESV message contains the label that has been bound to the LSP most recently. Finally, the transit LSR sends the RESV message upstream, along the reverse path of the LSP.
出口LSR向入口LSR向上游发送RESV消息。RESV消息访问的传输LSR与PATH消息访问的传输LSR相反。每个传输LSR将标签绑定到LSP，更新其转发状态，并更新RESV消息。因此，RESV消息中的Label对象包含最近绑定到LSP的标签。最后，传输LSR沿着LSP的反向路径向上游发送RESV消息。
When the ingress LSR receives the RESV message, it installs forwarding state. Once the ingress LSR installs forwarding state, it can forward traffic through the LSP.
当入口LSR接收到RESV消息时，它将安装转发状态。一旦入口LSR安装转发状态，它就可以通过LSP转发流量。
Referring to any LSR, RFC 3209 says, "The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message." However, RFC 3209 does not strictly require this behavior.
关于任何LSR，RFC 3209说，“在发送Resv消息之前，节点应该准备转发带有指定标签的数据包。”然而，RFC 3209并不严格要求这种行为。
Some implementations optimize the above-described procedure by allowing LSRs to send RESV messages before installing forwarding state [RFC6383]. This optimization is desirable, because it allows LSRs to install forwarding state in parallel, thus accelerating the process of LSP signaling and setup. However, this optimization creates a race condition. When the ingress LSR receives a RESV message, some downstream LSRs may have not yet installed forwarding
一些实现通过允许LSR在安装转发状态[RFC6383]之前发送RESV消息来优化上述过程。这种优化是可取的，因为它允许LSR并行安装转发状态，从而加快LSP信令和设置过程。但是，这种优化会产生竞争条件。当入口LSR接收到RESV消息时，一些下游LSR可能尚未安装转发
state. If the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.
状态如果入口LSR在所有下游节点上安装转发状态之前通过LSP转发流量，则流量可能会丢失。
This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to verify that forwarding state has been installed on all downstream nodes. By verifying the installation of downstream forwarding state, the ingress LSR eliminates this particular cause of traffic loss.
本文档介绍LSP自ping。当入口LSR接收到RESV消息时，它可以调用LSP自ping过程来验证转发状态是否已安装在所有下游节点上。通过验证下游转发状态的安装，入口LSR消除了造成流量损失的这一特殊原因。
LSP Self-ping is a new protocol. It is not an extension of LSP Ping [RFC4379]. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.
LSP自ping是一种新的协议。它不是LSP Ping[RFC4379]的扩展。尽管LSP Ping和LSP Self Ping的名称相似，但它们都是为一个独特的目的而设计的。每个协议在自己的UDP端口上侦听并执行自己的过程。
LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.
LSP自ping是一种非常轻量级的机制。它不会在中转或出口LSR上消耗控制平面资源。
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]中所述进行解释。
LSP Self-ping is applicable in the following scenario:
LSP自ping适用于以下场景：
o The ingress LSR signals a point-to-point LSP.
o 入口LSR向点对点LSP发送信号。
o The ingress LSR receives a RESV message.
o 入口LSR接收RESV消息。
o The RESV message indicates that all downstream nodes have begun the process of forwarding state installation.
o RESV消息表示所有下游节点都已开始转发状态安装过程。
o The RESV message does not guarantee that all downstream nodes have completed the process of forwarding state installation.
o RESV消息并不保证所有下游节点都已完成转发状态安装过程。
o The ingress LSR needs to confirm that all downstream nodes have completed the process for forwarding state installation.
o 入口LSR需要确认所有下游节点已完成转发状态安装过程。
o The ingress LSR does not need to confirm the correctness of downstream forwarding state, because there is a very high likelihood that downstream forwarding state is correct.
o 入口LSR不需要确认下游转发状态的正确性，因为下游转发状态正确的可能性非常高。
o Control-plane resources on the egress LSR may be scarce.
o 出口LSR上的控制平面资源可能稀缺。
o The need to conserve control-plane resources on the egress LSR outweighs the need to determine whether downstream forwarding state is correct.
o 保护出口LSR上的控制平面资源的需要超过确定下游转发状态是否正确的需要。
Unlike LSP Ping and S-BFD [S-BFD], LSP Self-ping is not a general-purpose MPLS OAM mechanism. It cannot reliably determine whether downstream forwarding state is correct. For example, if a downstream LSR installs a forwarding state that causes an LSP to terminate at the wrong node, LSP Self-ping will not detect an error. In another example, if a downstream LSR erroneously forwards a packet without an MPLS label, LSP Self-ping will not detect an error.
与LSP Ping和S-BFD[S-BFD]不同，LSP自Ping不是通用的MPLS OAM机制。它无法可靠地确定下游转发状态是否正确。例如，如果下游LSR安装的转发状态导致LSP在错误节点终止，则LSP自ping将不会检测到错误。在另一示例中，如果下游LSR错误地转发没有MPLS标签的分组，那么LSP自ping将不会检测到错误。
Furthermore, LSP Self-ping fails when either of the following conditions are true:
此外，当以下任一条件为真时，LSP自ping失败：
o The LSP under test is signaled by the Label Distribution Protocol (LDP) Independent Mode [RFC5036].
o 被测LSP由标签分发协议（LDP）独立模式[RFC5036]发出信号。
o Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on links that connect the ingress LSR to the egress LSR.
o 反向路径转发（RPF）[RFC3704]过滤器在连接入口LSR和出口LSR的链路上启用。
While LSP Ping and S-BFD are general-purpose OAM mechanisms, they are not applicable in the above-described scenario because:
虽然LSP Ping和S-BFD是通用OAM机制，但它们不适用于上述场景，因为：
o LSP Ping consumes control-plane resources on the egress LSR.
o LSP Ping消耗出口LSR上的控制平面资源。
o An S-BFD implementation either consumes control-plane resources on the egress LSR or requires special support for S-BFD on the forwarding plane.
o S-BFD实现要么消耗出口LSR上的控制平面资源，要么需要对转发平面上的S-BFD提供特殊支持。
By contrast, LSP Self-ping requires nothing from the egress LSR beyond the ability to forward an IP datagram.
相比之下，LSP自ping不需要来自出口LSR的任何东西，只需要转发IP数据报。
LSP Self-ping's purpose is to determine whether forwarding state has been installed on all downstream LSRs. Its primary constraint is to minimize its impact on egress LSR performance. This functionality is valuable during network convergence events that impact a large number of LSPs.
LSP自我ping的目的是确定是否在所有下游LSR上安装了转发状态。其主要约束是最小化其对出口LSR性能的影响。在影响大量LSP的网络融合事件期间，此功能非常有用。
Therefore, LSP Self-ping is applicable in the scenario described above, where the LSP is signaled by RSVP, RPF is not enabled, and the need to conserve control-plane resources on the egress LSR outweighs the need to determine whether downstream forwarding state is correct.
因此，LSP自ping适用于上述场景，其中LSP由RSVP发信号，RPF未启用，并且保护出口LSR上的控制平面资源的需要超过确定下游转发状态是否正确的需要。
The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC768] packet that encapsulates a session ID. If the RSVP messages used to establish the LSP under test were delivered over IPv4 [RFC791], the UDP datagram MUST be encapsulated in an IPv4 header. If the RSVP messages used to establish the LSP were delivered over IPv6 [RFC2460], the UDP datagram MUST be encapsulated in an IPv6 header.
LSP自ping消息是一个用户数据报协议（UDP）[RFC768]数据包，它封装了会话ID。如果用于建立被测LSP的RSVP消息是通过IPv4[RFC791]传递的，则UDP数据报必须封装在IPv4报头中。如果用于建立LSP的RSVP消息是通过IPv6[RFC2460]传递的，则UDP数据报必须封装在IPv6报头中。
In either case:
在任何一种情况下：
o The IP Source Address MAY be configurable. By default, it MUST be the address of the egress LSR.
o IP源地址可以配置。默认情况下，它必须是出口LSR的地址。
o The IP Destination Address MUST be the address of the ingress LSR.
o IP目标地址必须是入口LSR的地址。
o The IP Time to Live (TTL) / Hop Count MAY be configurable. By default, it MUST be 255.
o IP生存时间（TTL）/跳数可以配置。默认情况下，它必须是255。
o The IP DSCP (Differentiated Services Code Point) MAY be configurable. By default, it MUST be CS6 (110000) [RFC4594].
o IP DSCP（区分服务代码点）可以配置。默认情况下，它必须是CS6（110000）[RFC4594]。
o The UDP Source Port MUST be selected from the dynamic range (49152-65535) [RFC6335].
o UDP源端口必须从动态范围（49152-65535）[RFC6335]中选择。
o The UDP Destination Port MUST be lsp-self-ping (8503) [IANA.PORTS]
o UDP目标端口必须是lsp自ping（8503）[IANA.PORTS]
UDP packet contents have the following format:
UDP数据包内容具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-ID |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-ID |
| (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Self-Ping Message
LSP自Ping消息
The Session-ID is a 64-bit field that associates an LSP Self-ping message with an LSP Self-ping session.
会话ID是一个64位字段，它将LSP自ping消息与LSP自ping会话相关联。
In order to verify that an LSP is ready to carry traffic, the ingress LSR creates a short-lived LSP Self-ping session. All session state is maintained locally on the ingress LSR. Session state includes the following information:
为了验证LSP是否已准备好承载流量，入口LSR创建一个短期LSP自ping会话。所有会话状态都在入口LSR上本地维护。会话状态包括以下信息：
o Session-ID: A 64-bit number that identifies the LSP Self-ping session.
o 会话ID：标识LSP自ping会话的64位数字。
o Retry Counter: The maximum number of times that the ingress LSR probes the LSP before terminating the LSP Self-ping session. The initial value of this variable is determined by configuration.
o 重试计数器：入口LSR在终止LSP自ping会话之前探测LSP的最大次数。此变量的初始值由配置决定。
o Retry Timer: The number of milliseconds that the LSR waits after probing the LSP. The initial value of this variable is determined by configuration.
o 重试计时器：LSR在探测LSP后等待的毫秒数。此变量的初始值由配置决定。
o Status: A boolean variable indicating the completion status of the LSP Self-ping session. The initial value of this variable is FALSE.
o Status：一个布尔变量，指示LSP自ping会话的完成状态。此变量的初始值为FALSE。
Implementations MAY represent the above-mentioned information in any format that is convenient to them.
实现可以以任何方便的格式表示上述信息。
The ingress LSR executes the following procedure until Status equals TRUE or Retry Counter equals zero:
入口LSR执行以下过程，直到状态等于真或重试计数器等于零：
o Format a LSP Self-ping message.
o 格式化LSP自ping消息。
o Set the Session-ID in the LSP Self-ping message to the Session-ID mentioned above.
o 将LSP自ping消息中的会话ID设置为上述会话ID。
o Send the LSP Self-ping message through the LSP under test.
o 通过被测LSP发送LSP自ping消息。
o Set a timer to expire in Retry Timer milliseconds.
o 将计时器设置为在重试计时器毫秒内过期。
o Wait until either an LSP Self-ping message associated with the session returns or the timer expires. If an LSP Self-ping message associated with the session returns, set Status to TRUE. Otherwise, decrement the Retry Counter. Optionally, increase the value of Retry Timer according to an appropriate back-off algorithm.
o 等待与会话关联的LSP自ping消息返回或计时器过期。如果与会话关联的LSP自ping消息返回，请将Status设置为TRUE。否则，减小重试计数器。或者，根据适当的退避算法增加重试计时器的值。
In the process described above, the ingress LSR addresses an LSP Self-ping message to itself and forwards that message through the LSP under test. If forwarding state has been installed on all downstream LSRs, the egress LSR receives the LSP Self-ping message and
在上述过程中，入口LSR向自身寻址LSP自ping消息，并通过被测LSP转发该消息。如果转发状态已安装在所有下游LSR上，则出口LSR接收LSP自ping消息，并
determines that it is addressed to the ingress LSR. So, the egress LSR forwards the LSP Self-ping message back to the ingress LSR, exactly as it would forward any other IP packet.
确定它被寻址到入口LSR。因此，出口LSR将LSP自ping消息转发回入口LSR，就像它转发任何其他IP分组一样。
The LSP Self-ping message can arrive at the egress LSR with or without an MPLS header, depending on whether the LSP under test executes penultimate hop-popping procedures. If the LSP Self-ping message arrives at the egress LSR with an MPLS header, the egress LSR removes that header.
LSP自ping消息可以到达出口LSR，有或没有MPLS报头，这取决于被测LSP是否执行倒数第二跳弹出过程。如果LSP自ping消息到达带有MPLS报头的出口LSR，则出口LSR移除该报头。
If the egress LSR's most preferred route to the ingress LSR is through an LSP, the egress LSR forwards the LSP Self-ping message through that LSP. However, if the egress LSR's most preferred route to the ingress LSR is not through an LSP, the egress LSR forwards the LSP Self-ping message without MPLS encapsulation.
如果出口LSR到入口LSR的最优选路由是通过LSP，则出口LSR通过该LSP转发LSP自ping消息。然而，如果出口LSR到入口LSR的最优选路由不是通过LSP，则出口LSR在没有MPLS封装的情况下转发LSP自ping消息。
When an LSP Self-ping session terminates, it returns its completion status to the invoking protocol. For example, if RSVP-TE invokes LSP Self-ping as part of the LSP setup procedure, LSP Self-ping returns its completion status to RSVP-TE.
当LSP自ping会话终止时，它将其完成状态返回给调用协议。例如，如果RSVP-TE调用LSP自ping作为LSP设置过程的一部分，则LSP自ping将其完成状态返回给RSVP-TE。
A bidirectional LSP has an active side and a passive side. The active side calculates the ERO and signals the LSP in the forward direction. The passive side reverses the ERO and signals the LSP in the reverse direction.
双向LSP具有主动侧和被动侧。主动侧计算ERO并向前进方向的LSP发送信号。被动侧反转ERO并向LSP发送反向信号。
When LSP Self-ping is applied to a bidirectional LSP:
当LSP自ping应用于双向LSP时：
o The active side calculates the ERO, signals the LSP, and runs LSP Self-ping.
o 主动端计算ERO，向LSP发送信号，并运行LSP自ping。
o The Passive side reverses the ERO, signals the LSP, and runs another instance of LSP Self-ping.
o 被动端反转ERO，向LSP发送信号，并运行另一个LSP自ping实例。
o Neither side forwards traffic through the LSP until local LSP Self-ping returns TRUE.
o 在本地LSP自ping返回TRUE之前，任何一方都不会通过LSP转发流量。
The two LSP Self-ping sessions mentioned above are independent of one another. They are not required to have the same Session-ID. Each endpoint can forward traffic through the LSP as soon as its local LSP Self-ping returns TRUE. Endpoints are not required to wait until both LSP Self-ping sessions have returned TRUE.
上述两个LSP自ping会话彼此独立。它们不需要具有相同的会话ID。只要本地LSP自ping返回TRUE，每个端点都可以通过LSP转发流量。端点不需要等待两个LSP自ping会话都返回TRUE。
IANA has assigned UDP Port Number 8503 [IANA.PORTS] for use by MPLS LSP Self-Ping.
IANA已分配UDP端口号8503[IANA.PORTS]供MPLS LSP自Ping使用。
LSP Self-ping messages are easily forged. Therefore, an attacker can send the ingress LSR a forged LSP Self-ping message, causing the ingress LSR to terminate the LSP Self-ping session prematurely. In order to mitigate these threats, operators SHOULD filter LSP Self-ping packets at the edges of the MPLS signaling domain. Furthermore, implementations SHOULD NOT assign Session-IDs in a predictable manner. In order to avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) [NIST-CSPRNG].
LSP自ping消息很容易伪造。因此，攻击者可以向入口LSR发送伪造的LSP自ping消息，导致入口LSR提前终止LSP自ping会话。为了缓解这些威胁，运营商应该在MPLS信令域的边缘过滤LSP自ping数据包。此外，实现不应以可预测的方式分配会话ID。为了避免可预测性，实现可以利用加密安全的伪随机数生成器（CSPRNG）[NIST-CSPRNG]。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 3704，DOI 10.17487/RFC3704，2004年3月<http://www.rfc-editor.org/info/rfc3704>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，DOI 10.17487/RFC4379，2006年2月<http://www.rfc-editor.org/info/rfc4379>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[IANA.PORTS] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers>.
[IANA.PORTS]IANA，“服务名称和传输协议端口号注册表”<http://www.iana.org/assignments/ 服务名称端口号>。
[NIST-CSPRNG] NIST, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90A, January 2012.
[NIST-CSPRNG]NIST，“使用确定性随机位生成器生成随机数的建议”，NIST特别出版物800-90A，2012年1月。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <http://www.rfc-editor.org/info/rfc4594>.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 4594，DOI 10.17487/RFC4594，2006年8月<http://www.rfc-editor.org/info/rfc4594>.
[RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September 2011, <http://www.rfc-editor.org/info/rfc6383>.
[RFC6383]Shiomoto，K.和A.Farrel，“关于何时开始在使用RSVP-TE建立的标签交换路径上安全发送数据的建议”，RFC 6383，DOI 10.17487/RFC6383，2011年9月<http://www.rfc-editor.org/info/rfc6383>.
[S-BFD] Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. Networks, "Seamless Bidirectional Forwarding Detection (S-BFD)", Work in Progress, draft-ietf-bfd-seamless-base-05, June 2015.
[S-BFD]Akiya，N.，Pignataro，C.，Ward，D.，Bhatia，M.，和J.Networks，“无缝双向转发检测（S-BFD）”，正在进行的工作，草案-ietf-BFD-无缝-base-052015年6月。
In a rejected approach, the ingress LSR uses LSP Ping to verify LSP readiness. This approach was rejected for the following reasons.
在拒绝方法中，入口LSR使用LSP Ping来验证LSP就绪性。由于以下原因，该方法被拒绝。
While an ingress LSR can control its control-plane overhead due to LSP Ping, an egress LSR has no such control. This is because each ingress LSR can, on its own, control the rate of the LSP Ping originated by the LSR, while an egress LSR must respond to all the LSP Pings originated by various ingresses. Furthermore, when an MPLS Echo Request reaches an egress LSR, it is sent to the control plane of the egress LSR; this makes egress LSR processing overhead of LSP Ping well above the overhead of its data plane (MPLS/IP forwarding). These factors make LSP Ping problematic as a tool for detecting LSP readiness to carry traffic when dealing with a large number of LSPs.
虽然入口LSR可以由于LSP Ping而控制其控制平面开销，但出口LSR没有这种控制。这是因为每个入口LSR可以自己控制由LSR发起的LSP Ping的速率，而出口LSR必须响应由各种入口发起的所有LSP Ping。此外，当MPLS回波请求到达出口LSR时，它被发送到出口LSR的控制平面；这使得LSP Ping的出口LSR处理开销远高于其数据平面（MPLS/IP转发）的开销。在处理大量LSP时，这些因素使得LSP Ping作为检测LSP是否准备好承载流量的工具存在问题。
By contrast, LSP Self-ping does not consume any control-plane resources at the egress LSR, and it relies solely on the data plane of the egress LSR, making it more suitable as a tool for checking LSP readiness when dealing with a large number of LSPs.
相比之下，LSP自ping不消耗出口LSR处的任何控制平面资源，并且它仅依赖出口LSR的数据平面，使得它更适合作为在处理大量LSP时检查LSP就绪性的工具。
In another rejected approach, the ingress LSR does not verify LSP readiness. Instead, it sets a timer when it receives an RSVP RESV message and does not forward traffic through the LSP until the timer expires. This approach was rejected because it is impossible to determine the optimal setting for this timer. If the timer value is set too low, it does not prevent black-holing. If the timer value is set too high, it slows down the process of LSP signaling and setup.
在另一种被拒绝的方法中，入口LSR不验证LSP就绪性。相反，它在接收到RSVP RESV消息时设置计时器，并且在计时器过期之前不会通过LSP转发流量。此方法被拒绝，因为无法确定此计时器的最佳设置。如果定时器值设置得太低，则不会阻止黑洞。如果定时器值设置过高，则会减慢LSP信令和设置过程。
Moreover, the above-mentioned timer is configured on a per-router basis. However, its optimum value is determined by a network-wide behavior. Therefore, changes in the network could require changes to the value of the timer, making the optimal setting of this timer a moving target.
此外，在每个路由器的基础上配置上述定时器。然而，它的最佳值是由网络范围内的行为决定的。因此，网络中的更改可能需要更改计时器的值，从而使此计时器的最佳设置成为移动目标。
Acknowledgements
致谢
Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg Mirsky, and Nobo Akiya for their contributions to this document.
感谢亚科夫·雷克特、拉维·辛格、埃里克·罗森、埃里克·奥斯本、格雷格·米尔斯基和Nobo Akiya对本文件的贡献。
Contributors
贡献者
The following individuals contributed significantly to this document:
以下个人对本文件作出了重大贡献：
Mark Wygant Verizon mark.wygant@verizon.com
马克·威甘特·威瑞森·马克。wygant@verizon.com
Ravi Torvi Juniper Networks rtorvi@juniper.net
拉维·托维·杜松网络rtorvi@juniper.net
Authors' Addresses
作者地址
Ron Bonica Juniper Networks
Ron Bonica Juniper网络
Email: rbonica@juniper.net
Email: rbonica@juniper.net
Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Ina Minei Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
Email: inaminei@google.com
Email: inaminei@google.com
Michael Conn Verizon
迈克尔康涅狄格威瑞森
Email: meconn26@gmail.com
Email: meconn26@gmail.com
Dante Pacella Verizon
Dante Pacella Verizon
Email: dante.j.pacella@verizon.com
Email: dante.j.pacella@verizon.com
Luis Tomotaki Verizon
路易斯·托莫塔基·威瑞森
Email: luis.tomotaki@verizon.com
Email: luis.tomotaki@verizon.com