Internet Engineering Task Force (IETF) S. Aldrin
Request for Comments: 7882 Google, Inc.
Category: Informational C. Pignataro
ISSN: 2070-1721 Cisco
G. Mirsky
Ericsson
N. Kumar
Cisco
July 2016
Internet Engineering Task Force (IETF) S. Aldrin
Request for Comments: 7882 Google, Inc.
Category: Informational C. Pignataro
ISSN: 2070-1721 Cisco
G. Mirsky
Ericsson
N. Kumar
Cisco
July 2016
Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases
无缝双向转发检测（S-BFD）用例
Abstract
摘要
This document describes various use cases for Seamless Bidirectional Forwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures.
本文档描述了无缝双向转发检测（S-BFD）的各种用例，并提供了协议机制允许简化转发故障检测的要求。
These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits of S-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.
这些用例支持S-BFD，S-BFD是使用BFD的简化机制，消除了大部分协商方面，加快了BFD会话的建立。S-BFD的好处包括快速资源调配，以及改进网络节点启动路径监视的控制和灵活性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7882.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7882.
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. Terminology ................................................3
2. Introduction to Seamless BFD ....................................4
3. Use Cases .......................................................5
3.1. Unidirectional Forwarding Path Validation ..................5
3.2. Validation of the Forwarding Path prior to
Switching Traffic ..........................................6
3.3. Centralized Traffic Engineering ............................7
3.4. BFD in Centralized Segment Routing .........................8
3.5. Efficient BFD Operation under Resource Constraints .........8
3.6. BFD for Anycast Addresses ..................................8
3.7. BFD Fault Isolation ........................................9
3.8. Multiple BFD Sessions to the Same Target Node ..............9
3.9. An MPLS BFD Session per ECMP Path .........................10
4. Detailed Requirements for Seamless BFD .........................11
5. Security Considerations ........................................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................13
Acknowledgements ..................................................15
Contributors ......................................................15
Authors' Addresses ................................................15
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Introduction to Seamless BFD ....................................4
3. Use Cases .......................................................5
3.1. Unidirectional Forwarding Path Validation ..................5
3.2. Validation of the Forwarding Path prior to
Switching Traffic ..........................................6
3.3. Centralized Traffic Engineering ............................7
3.4. BFD in Centralized Segment Routing .........................8
3.5. Efficient BFD Operation under Resource Constraints .........8
3.6. BFD for Anycast Addresses ..................................8
3.7. BFD Fault Isolation ........................................9
3.8. Multiple BFD Sessions to the Same Target Node ..............9
3.9. An MPLS BFD Session per ECMP Path .........................10
4. Detailed Requirements for Seamless BFD .........................11
5. Security Considerations ........................................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................13
Acknowledgements ..................................................15
Contributors ......................................................15
Authors' Addresses ................................................15
Bidirectional Forwarding Detection (BFD), as defined in [RFC5880], is a lightweight protocol used to detect forwarding failures. Various protocols, applications, and clients rely on BFD for failure detection. Even though the protocol is lightweight and simple, there are certain use cases where faster setup of sessions and faster continuity checks of the data-forwarding paths are necessary. This document identifies these use cases and consequent requirements, such that enhancements and extensions result in a Seamless BFD (S-BFD) protocol.
[RFC5880]中定义的双向转发检测（BFD）是一种用于检测转发故障的轻量级协议。各种协议、应用程序和客户端都依赖BFD进行故障检测。尽管该协议是轻量级和简单的，但在某些用例中，需要更快地设置会话和更快地检查数据转发路径的连续性。本文档确定了这些用例和随后的需求，从而增强和扩展了无缝BFD（S-BFD）协议。
BFD is a simple and lightweight "Hello" protocol to detect data-plane failures. With dynamic provisioning of forwarding paths on a large scale, establishing BFD sessions for each of those paths not only creates operational complexity but also causes undesirable delay in establishing or deleting sessions. The existing session establishment mechanism of the BFD protocol has to be enhanced in order to minimize the time for the session to come up to validate the forwarding path.
BFD是一个简单而轻量级的“Hello”协议，用于检测数据平面故障。通过大规模动态提供转发路径，为这些路径中的每一条建立BFD会话不仅会造成操作复杂性，而且还会在建立或删除会话时造成不必要的延迟。必须增强BFD协议的现有会话建立机制，以尽量减少会话出现以验证转发路径的时间。
This document specifically identifies various use cases and corresponding requirements in order to enhance BFD and other supporting protocols. Specifically, one key goal is removing the time delay (i.e., the "seam") between when a network node wants to perform a continuity test and when the node completes that continuity test. Consequently, "Seamless BFD" (S-BFD) has been chosen as the name for this mechanism.
本文件明确确定了各种用例和相应的需求，以增强BFD和其他支持协议。具体而言，一个关键目标是消除网络节点想要执行连续性测试和节点完成该连续性测试之间的时间延迟（即“接缝”）。因此，“无缝BFD”（S-BFD）被选为该机制的名称。
While the identified requirements could meet various use cases, it is outside the scope of this document to identify all of the possible and necessary requirements. Solutions related to the identified use cases and protocol-specific enhancements or proposals are outside the scope of this document as well. Protocol definitions to support these use cases can be found in [RFC7880] and [RFC7881].
虽然确定的需求可以满足各种用例，但确定所有可能的和必要的需求超出了本文档的范围。与已识别用例和特定于协议的增强或建议相关的解决方案也不在本文档的范围之内。支持这些用例的协议定义可以在[RFC7880]和[RFC7881]中找到。
The reader is expected to be familiar with the BFD [RFC5880], IP [RFC791] [RFC2460], MPLS [RFC3031], and Segment Routing [SR-ARCH] terms and protocol constructs.
读者应熟悉BFD[RFC5880]、IP[RFC791][RFC2460]、MPLS[RFC3031]和段路由[SR-ARCH]术语和协议结构。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
BFD, as defined in [RFC5880], requires two network nodes to exchange locally allocated discriminators. These discriminators enable the identification of the sender and the receiver of BFD packets over the particular session. Subsequently, BFD performs proactive continuity monitoring of the forwarding path between the two. Several specifications describe BFD's multiple deployment uses:
[RFC5880]中定义的BFD需要两个网络节点交换本地分配的鉴别器。这些鉴别器使得能够在特定会话上识别BFD分组的发送方和接收方。随后，BFD对两者之间的转发路径执行主动连续性监视。几个规范描述了BFD的多种部署用途：
o [RFC5881] defines BFD over IPv4 and IPv6 for single IP hops.
o [RFC5881]为单个IP跃点定义IPv4和IPv6上的BFD。
o [RFC5883] defines BFD over multi-hop paths.
o [RFC5883]定义多跳路径上的BFD。
o [RFC5884] defines BFD for MPLS Label Switched Paths (LSPs).
o [RFC5884]定义MPLS标签交换路径（LSP）的BFD。
o [RFC5885] defines BFD for MPLS Pseudowires (PWs).
o [RFC5885]定义MPLS伪线（PWs）的BFD。
Currently, BFD is best suited for verifying that two endpoints are mutually reachable or that an existing connection continues to be up and alive. In order for BFD to be able to initially verify that a connection is valid and that it connects the expected set of endpoints, it is necessary to provide each endpoint with the discriminators associated with the connection at each endpoint prior to initiating BFD sessions. The discriminators are used to verify that the connection is up and valid. Currently, the exchange of discriminators and the demultiplexing of the initial BFD packets are application dependent.
目前，BFD最适合于验证两个端点是否可以相互访问，或者现有连接是否继续处于活动状态。为了使BFD能够初步验证连接是否有效，以及它是否连接了预期的端点集，有必要在启动BFD会话之前向每个端点提供与每个端点处的连接相关联的鉴别器。鉴别器用于验证连接是否正常和有效。目前，鉴别器的交换和初始BFD数据包的解复用取决于应用程序。
If this information is already known to the endpoints of a potential BFD session, the initial handshake including an exchange of discriminators is unnecessary, and it is possible for the endpoints to begin BFD messaging seamlessly. A key objective of the S-BFD use cases described in this document is to avoid needing to exchange the initial packets before the BFD session can be established, with the goal of getting to the established state more quickly; in other words, the initial exchange of discriminator information is an unnecessary extra step that may be avoided for these cases.
如果潜在BFD会话的端点已经知道该信息，则不需要包括鉴别器交换的初始握手，并且端点可以无缝地开始BFD消息传递。本文档中描述的S-BFD用例的一个关键目标是避免在建立BFD会话之前需要交换初始数据包，目的是更快地达到建立状态；换句话说，鉴别器信息的初始交换是不必要的额外步骤，对于这些情况可以避免。
In a given scenario, an entity (such as an operator or a centralized controller) determines a set of network entities to which BFD sessions might need to be established. In traditional BFD, each of those network entities chooses a BFD Discriminator for each BFD session that the entity will participate in (see Section 6.3 of [RFC5880]). However, a key goal of S-BFD is to provide operational simplification. In this context, for S-BFD, each of those network entities is assigned one or more BFD Discriminators, and those network entities are allowed to use one Discriminator value for multiple sessions. Therefore, there may be only one or a few
在给定的场景中，实体（如操作员或集中控制器）确定可能需要建立BFD会话的一组网络实体。在传统的BFD中，这些网络实体中的每一个都为实体将参与的每个BFD会话选择一个BFD鉴别器（参见[RFC5880]第6.3节）。然而，S-BFD的一个关键目标是提供操作简化。在此上下文中，对于S-BFD，这些网络实体中的每一个被分配一个或多个BFD鉴别器，并且这些网络实体被允许对多个会话使用一个鉴别器值。因此，可能只有一个或几个
discriminators assigned to a node. These network entities will create an S-BFD listener session instance that listens for incoming BFD Control packets. When the mappings between specific network entities and their corresponding BFD Discriminators are known to other network nodes belonging to the same administrative domain, then, without having received any BFD packets from a particular target, a network entity in this network is able to send a BFD Control packet to the target's assigned discriminator in the Your Discriminator field. The target network node, upon reception of such a BFD Control packet, will transmit a response BFD Control packet back to the sender.
分配给节点的鉴别器。这些网络实体将创建一个S-BFD侦听器会话实例，用于侦听传入的BFD控制数据包。当属于同一管理域的其他网络节点知道特定网络实体及其相应BFD鉴别器之间的映射时，则在没有从特定目标接收任何BFD分组的情况下，此网络中的网络实体能够将BFD控制数据包发送到目标的“您的鉴别器”字段中指定的鉴别器。目标网络节点在接收到这样的BFD控制分组时，将向发送方发送响应BFD控制分组。
As per the BFD protocol [RFC5880], BFD sessions are established using a handshake mechanism prior to validating the forwarding path. This section outlines some use cases where the existing mechanism may not be able to satisfy the requirements identified. In addition, some of the use cases also stress the need for expedited BFD session establishment while preserving the benefits of forwarding failure detection using existing BFD mechanisms. Both of these high-level goals result in the S-BFD use cases outlined in this document.
根据BFD协议[RFC5880]，在验证转发路径之前，使用握手机制建立BFD会话。本节概述了现有机制可能无法满足确定需求的一些用例。此外，一些用例还强调需要快速建立BFD会话，同时保留使用现有BFD机制进行转发故障检测的好处。这两个高层次目标都导致了本文档中概述的S-BFD用例。
Even though bidirectional verification of forwarding paths is useful, there are scenarios where verification is only required in one direction between a pair of nodes. One such case is when a static route uses BFD to validate reachability to the next-hop IP router. In this case, the static route is established from one network entity to another. The requirement in this case is only to validate the forwarding path for that statically established unidirectional path. Validation of the forwarding path in the direction of the target entity to the originating entity is not required in this scenario. Many LSPs have the same unidirectional characteristics and unidirectional validation requirements. Such LSPs are common in Segment Routing and LDP-based MPLS networks. A final example is when a unidirectional tunnel uses BFD to validate the reachability of an egress node.
尽管转发路径的双向验证很有用，但在某些情况下，验证只需要在一对节点之间的一个方向上进行。其中一种情况是静态路由使用BFD验证下一跳IP路由器的可达性。在这种情况下，建立从一个网络实体到另一个网络实体的静态路由。这种情况下的要求只是验证静态建立的单向路径的转发路径。在此场景中，不需要验证目标实体到原始实体的转发路径。许多LSP具有相同的单向特性和单向验证要求。这种LSP在段路由和基于LDP的MPLS网络中很常见。最后一个例子是单向隧道使用BFD验证出口节点的可达性。
Additionally, validation of the unidirectional path has operational implications. If traditional BFD is to be used, the target network entity, as well as an initiator, has to be provisioned, even though reverse-path validation with the BFD session is not required. However, in the case of unidirectional BFD, there is no need for provisioning on the target network entity -- only on the source entity.
此外，单向路径的验证具有操作含义。如果要使用传统BFD，则必须提供目标网络实体以及启动器，即使不需要BFD会话的反向路径验证。但是，在单向BFD的情况下，不需要在目标网络实体上进行配置——只需要在源实体上进行配置。
In this use case, a BFD session could be established in a single direction. When the target network entity receives the packet, it identifies the packet as BFD in an application-specific manner (for example, a destination UDP port number). Subsequently, the BFD module processes the packet, using the Your Discriminator value as context. Then, the network entity sends a response to the originator. This does not necessitate the requirement for establishment of a bidirectional session; hence, the two-way handshake to exchange discriminators is not needed. The target node does not need to know the My Discriminator value of the source node.
在这个用例中，可以在单个方向上建立BFD会话。当目标网络实体接收到数据包时，它以特定于应用程序的方式（例如，目标UDP端口号）将数据包标识为BFD。随后，BFD模块使用您的鉴别器值作为上下文处理数据包。然后，网络实体向发起人发送响应。这不需要建立双向会话；因此，不需要双向握手来交换鉴别器。目标节点不需要知道源节点的My Discriminator值。
Thus, in this use case a requirement for BFD is to enable session establishment from the source network entity to the target network entity without the need to have a session (and state) for the reverse direction. Further, another requirement is that the BFD response from the target back to the sender can take any (in-band or out-of-band) path. The BFD module in the target network entity (for the BFD session), upon receipt of a BFD packet, starts processing the BFD packet based on the discriminator received. The source network entity can therefore establish a unidirectional BFD session without the bidirectional handshake and exchange of discriminators for session establishment.
因此，在此用例中，BFD的要求是启用从源网络实体到目标网络实体的会话建立，而不需要反向会话（和状态）。此外，另一个要求是，从目标返回发送方的BFD响应可以采用任何（带内或带外）路径。目标网络实体（用于BFD会话）中的BFD模块在接收到BFD分组后，根据接收到的鉴别器开始处理BFD分组。因此，源网络实体可以建立单向BFD会话，而无需双向握手和交换用于会话建立的鉴别器。
In this use case, BFD is used to verify reachability before sending traffic via a path/LSP. This comes at a cost: traffic is prevented from using the path/LSP until BFD is able to validate reachability; this could take seconds due to BFD session bring-up sequences [RFC5880], LSP Ping bootstrapping [RFC5884], etc. This use case would be better supported by eliminating the need for the initial BFD session negotiation.
在这个用例中，BFD用于在通过path/LSP发送流量之前验证可达性。这是有代价的：在BFD能够验证可达性之前，阻止流量使用path/LSP；由于BFD会话启动序列[RFC5880]、LSP Ping引导[RFC5884]等原因，这可能需要几秒钟。通过消除初始BFD会话协商的需要，可以更好地支持此用例。
All it takes to be able to send BFD packets to a target and for the target to properly demultiplex these packets is for the source network entities to know what Discriminator values will be used for the session. This is also the case for S-BFD: the three-way handshake mechanism is eliminated during the bootstrapping of BFD sessions. However, this information is required at each entity to verify that BFD messages are being received from the expected endpoints; hence, the handshake mechanism serves no purpose. Elimination of the unnecessary handshake mechanism allows for faster reachability validation of BFD provisioned paths/LSPs.
能够向目标发送BFD数据包以及目标正确解复用这些数据包所需要的只是源网络实体知道会话将使用什么鉴别器值。S-BFD也是如此：在BFD会话的引导过程中，三方握手机制被消除。但是，每个实体都需要此信息来验证是否从预期端点接收到BFD消息；因此，握手机制没有任何作用。消除不必要的握手机制可以更快地验证BFD配置的路径/LSP的可达性。
In addition, it is expected that some MPLS technologies will require traffic-engineered LSPs to be created dynamically, perhaps driven by external applications, as, for example, in Software-Defined Networking (SDN). It will be desirable to perform BFD validation as soon as the LSPs are created, so as to use them.
此外，预计一些MPLS技术将要求动态创建流量工程LSP，可能由外部应用程序驱动，例如在软件定义网络（SDN）中。希望在创建LSP后立即执行BFD验证，以便使用它们。
In order to support this use case, an S-BFD session is established without the need for session negotiation and exchange of discriminators.
为了支持这个用例，建立了一个S-BFD会话，而不需要会话协商和鉴别器交换。
Various technologies in the SDN domain that involve controller-based networks have evolved such that the intelligence, traditionally placed in a distributed and dynamic control plane, is separated from the networking entities themselves; instead, it resides in a (logically) centralized place. There are various controllers that perform the function of establishing forwarding paths for the data flow. Traffic engineering is one important function, where the path of the traffic flow is engineered, depending upon various attributes and constraints of the traffic paths as well as the network state.
SDN领域中涉及基于控制器的网络的各种技术已经发展，使得传统上放置在分布式动态控制平面中的智能与网络实体本身分离；相反，它位于（逻辑上）集中的位置。有各种控制器执行为数据流建立转发路径的功能。交通工程是一项重要的功能，根据交通路径的各种属性和约束以及网络状态，对交通流的路径进行工程。
When the intelligence of the network resides in a centralized entity, the ability to manage and maintain the dynamic network, and its multiple data paths and node reachability, becomes a challenge. One way to ensure that the forwarding paths are valid and working is done by validation using BFD. When traffic-engineered tunnels are created, it is operationally critical to ensure that the forwarding paths are working, prior to switching the traffic onto the engineered tunnels. In the absence of distributed control-plane protocols, it may be desirable to verify any arbitrary forwarding path in the network. With tunnels being engineered by a centralized entity, when the network state changes, traffic has to be switched with minimum latency and without black-holing of the data.
当网络的智能驻留在一个集中的实体中时，管理和维护动态网络的能力以及其多数据路径和节点可达性就成为一个挑战。确保转发路径有效和工作的一种方法是使用BFD进行验证。创建流量工程隧道时，在将流量切换到工程隧道之前，确保转发路径正常工作在操作上至关重要。在没有分布式控制平面协议的情况下，可能需要验证网络中的任何任意转发路径。由于隧道是由一个集中的实体设计的，当网络状态发生变化时，必须以最小的延迟切换流量，并且不存在数据的黑洞。
It is highly desirable in this centralized traffic-engineering use case that the traditional BFD session establishment and validation of the forwarding path do not become a bottleneck. If the controller or other centralized entity is able to very rapidly verify the forwarding path of a traffic-engineered tunnel, it could steer the traffic onto the traffic-engineered tunnel very quickly, thus minimizing adverse effects on a service. This is even more useful and necessary when the scale of the network and the number of traffic-engineered tunnels grow.
在这种集中式流量工程用例中，非常希望传统的BFD会话建立和转发路径验证不会成为瓶颈。如果控制器或其他集中实体能够非常快速地验证流量工程隧道的转发路径，则它可以非常快速地将流量引导到流量工程隧道上，从而将对服务的不利影响降至最低。当网络规模和交通工程隧道数量增加时，这一点更加有用和必要。
The cost associated with the time required for BFD session negotiation and establishment of BFD sessions to identify valid paths is very high when providing network redundancy is a critical issue.
当提供网络冗余是一个关键问题时，BFD会话协商和建立BFD会话以识别有效路径所需的时间成本非常高。
A monitoring technique for a Segment Routing network based on a centralized controller is described in [SR-MPLS]. Specific Operations, Administration, and Maintenance (OAM) requirements for Segment Routing are captured in [SR-OAM-REQS]. In validating this use case, one of the requirements is to ensure that the BFD packet's behavior is according to the monitoring specified for the segment and that the packet is U-turned at the expected node. This criterion ensures the continuity check to the adjacent Segment Identifier.
[SR-MPLS]中描述了基于集中式控制器的分段路由网络的监控技术。段路由的具体操作、管理和维护（OAM）要求见[SR-OAM-REQS]。在验证该用例时，要求之一是确保BFD数据包的行为符合为该段指定的监控，并且该数据包在预期节点处掉头。该标准确保对相邻段标识符进行连续性检查。
To support this use case, the operational requirement is for BFD, initiated from a centralized controller, to perform liveness detection for any given segment in its domain.
为了支持这个用例，操作需求是由集中式控制器启动的BFD对其域中的任何给定段执行活动性检测。
When BFD sessions are being set up, torn down, or modified (i.e., when parameters such as intervals and multipliers are being modified), BFD requires additional packets, other than scheduled packet transmissions, to complete the negotiation procedures (i.e., Poll (P) bits and Final (F) bits; see Section 4.1 of [RFC5880]). There are scenarios where network resources are constrained: a node may require BFD to monitor a very large number of paths, or BFD may need to operate in low-powered and traffic-sensitive networks; these include microwave systems, low-powered nanocells, and others. In these scenarios, it is desirable for BFD to slow down, speed up, stop, or resume at will and with a minimal number of additional BFD packets exchanged to modify the session or establish a new one.
当设置、拆除或修改BFD会话时（即，当修改间隔和乘数等参数时），BFD需要额外的数据包，而不是计划的数据包传输，以完成协商过程（即轮询（P）位和最终（F）位；参见[RFC5880]第4.1节）。存在网络资源受限的场景：节点可能需要BFD监控大量路径，或者BFD可能需要在低功耗和流量敏感的网络中运行；这些包括微波系统、低功率纳米电池等。在这些场景中，BFD需要随意减速、加速、停止或恢复，并且需要交换最少数量的额外BFD数据包来修改会话或建立新会话。
The established BFD session parameters, and such attributes as transmission interval and receiver interval, need to be modifiable without changing the state of the session.
在不改变会话状态的情况下，需要修改已建立的BFD会话参数以及传输间隔和接收器间隔等属性。
The BFD protocol requires two endpoints to host BFD sessions, both sending packets to each other. This BFD model does not fit well with anycast address monitoring, as BFD packets transmitted from a network node to an anycast address will reach only one of potentially many network nodes hosting the anycast address.
BFD协议需要两个端点来承载BFD会话，这两个端点都向对方发送数据包。此BFD模型不适合选播地址监控，因为从网络节点传输到选播地址的BFD数据包将仅到达承载选播地址的潜在多个网络节点中的一个。
This use case verifies that a source node can send a packet to an anycast address and that the target node to which the packet is delivered can send a response packet to the source node. Traditional BFD cannot fulfill this requirement, since it does not provide for a
该用例验证源节点可以向选播地址发送数据包，并且数据包被发送到的目标节点可以向源节点发送响应数据包。传统的BFD不能满足这一要求，因为它不提供
set of BFD agents to collectively form one endpoint of a BFD session. The concept of a "target listener" in S-BFD fulfills this requirement.
一组BFD代理，共同构成BFD会话的一个端点。S-BFD中的“目标侦听器”概念满足这一要求。
To support this use case, the BFD sender transmits BFD packets, which are received by any of the nodes hosting the anycast address to which the BFD packets are being sent. The anycast target that receives the BFD packet responds. This use case does not imply BFD session establishment with every node hosting the anycast address. Consequently, in this anycast use case, target nodes that do not happen to receive any of the BFD packets do not need to maintain any state, and the source node does not need to maintain separate state for each target node.
为了支持这种用例，BFD发送方发送BFD包，BFD包由承载BFD包被发送到的选播地址的任何节点接收。接收BFD数据包的选播目标响应。此用例并不意味着与承载选播地址的每个节点建立BFD会话。因此，在该选播用例中，不碰巧接收任何BFD分组的目标节点不需要保持任何状态，并且源节点不需要为每个目标节点保持单独的状态。
BFD for multi-hop paths [RFC5883] and BFD for MPLS LSPs [RFC5884] perform end-to-end validation, traversing multiple network nodes. BFD has been designed to declare a failure to receive some number of consecutive packets. This failure can be caused by a fault anywhere along these paths. Fast failure detection allows for rapid fault detection and consequent rapid path recovery procedures. However, operators often have to follow up, manually or automatically, to attempt to identify and localize the fault that caused BFD sessions to fail (i.e., fault isolation). If Equal-Cost Multipath (ECMP) is used, the usage of other tools to isolate the fault (e.g., traceroute) may cause the packets to traverse a different path through the network. In addition, the longer it takes from the time of BFD session failure to the time that fault isolation begins, the more likely the fault will not be isolated (e.g., a fault may be corrected via rerouting or some other means during that time). If BFD had built-in fault-isolation capability, fault isolation would be triggered when the fault was first detected. This embedded fault isolation would be more effective (i.e., faults would be detected sooner) if those BFD fault-isolation packets were load-balanced in the same way as the BFD packets that were dropped.
多跳路径的BFD[RFC5883]和MPLS LSP的BFD[RFC5884]执行端到端验证，遍历多个网络节点。BFD被设计为声明接收某些连续数据包失败。此故障可能由这些路径上的任何位置的故障引起。快速故障检测允许快速故障检测和随后的快速路径恢复程序。但是，操作员通常必须手动或自动跟踪，以尝试识别和定位导致BFD会话失败的故障（即故障隔离）。如果使用等成本多路径（ECMP），则使用其他工具隔离故障（例如，跟踪路由）可能会导致数据包穿过网络的不同路径。此外，从BFD会话失败到故障隔离开始的时间越长，故障就越有可能无法隔离（例如，在此期间可通过重新路由或其他方式纠正故障）。如果BFD具有内置故障隔离功能，则故障隔离将在首次检测到故障时触发。如果这些BFD故障隔离数据包以与丢弃的BFD数据包相同的方式进行负载平衡，则这种嵌入式故障隔离将更加有效（即，故障将更快地被检测到）。
This use case describes S-BFD fault-isolation capabilities, utilizing a TTL field (e.g., as described in Section 5.1.1 of [RFC7881]) or using fields that indicate status.
本用例描述了S-BFD故障隔离能力，使用TTL字段（如[RFC7881]第5.1.1节所述）或使用指示状态的字段。
BFD is capable of providing very fast failure detection, as relevant network nodes continuously transmit BFD packets at the negotiated rate. If BFD packet transmission is interrupted, even for a very short period of time, BFD can declare a failure irrespective of path liveness. On a system where BFD is running, it is possible for
BFD能够提供非常快速的故障检测，因为相关网络节点以协商速率连续传输BFD数据包。如果BFD数据包传输中断，即使在很短的时间内，BFD也可以宣布失败，而不管路径是否活跃。在运行BFD的系统上，可以
certain events to (intentionally or unintentionally) cause a brief interruption of BFD packet transmissions. With distributed architectures of BFD implementations, this case can be prevented. This use case is for an S-BFD node running multiple BFD sessions to the same target node, with those sessions hosted on different system modules (e.g., in different CPU instances). This can reduce false failures, resulting in a more stable network.
某些事件（有意或无意）导致BFD数据包传输短暂中断。使用BFD实现的分布式体系结构，可以防止这种情况。此用例适用于S-BFD节点运行多个BFD会话到同一目标节点，这些会话托管在不同的系统模块上（例如，在不同的CPU实例中）。这可以减少错误故障，从而使网络更加稳定。
To support this use case, a mapping between the multiple discriminators on a single system and the specific entity within that system is required.
为了支持这个用例，需要在单个系统上的多个鉴别器和该系统中的特定实体之间进行映射。
BFD for MPLS LSPs, defined in [RFC5884], describes procedures for running BFD as an LSP in-band continuity check mechanism by using MPLS Echo Request messages [RFC4379] to bootstrap the BFD session on the target (i.e., egress) node. Section 4 of [RFC5884] also describes the possibility of running multiple BFD sessions per alternative of LSPs. [RFC7726] further clarifies the procedures, for both ingress and egress nodes, regarding how to bootstrap, maintain, and remove multiple BFD sessions for the same <MPLS LSP, FEC> tuple ("FEC" means Forwarding Equivalence Class). However, this mechanism still requires the use of MPLS LSP Ping for bootstrapping, round trips for initialization, and keeping state at the receiver.
[RFC5884]中定义的MPLS LSP的BFD描述了通过使用MPLS回送请求消息[RFC4379]在目标（即出口）节点上引导BFD会话，将BFD作为LSP带内连续性检查机制运行的过程。[RFC5884]第4节还描述了每个LSP备选方案运行多个BFD会话的可能性。[RFC7726]进一步阐明了入口和出口节点关于如何为同一<MPLS LSP，FEC>元组引导、维护和删除多个BFD会话的过程（“FEC”表示转发等价类）。然而，这种机制仍然需要使用MPLS LSP Ping进行引导，使用往返进行初始化，并在接收器处保持状态。
In the presence of ECMP within an MPLS LSP, it may be desirable to run in-band monitoring that exercises every path of this ECMP. Otherwise, there will be scenarios where an in-band BFD session remains up through one path but traffic is black-holing over another path. A BFD session per ECMP path of an LSP requires the definition of procedures that update [RFC5884] in terms of how to bootstrap and maintain the correct set of BFD sessions on the egress node. However, for traditional BFD, that requires the constant use of MPLS Echo Request messages to create and delete BFD sessions on the egress node when ECMP paths and/or corresponding load-balance hash keys change. If a BFD session over any paths of the LSP can be instantiated, stopped, and resumed without requiring additional procedures for bootstrapping via an MPLS Echo Request message, it would greatly simplify both implementations and operations and would benefit network devices, as less processing would be required by them.
在MPLS LSP中存在ECMP的情况下，可能需要运行执行该ECMP的每条路径的带内监视。否则，将出现带内BFD会话在一条路径上保持打开，但在另一条路径上流量为黑洞的情况。LSP的每个ECMP路径的BFD会话需要定义更新[RFC5884]的过程，以了解如何在出口节点上引导和维护正确的BFD会话集。然而，对于传统的BFD，当ECMP路径和/或相应的负载平衡散列键发生变化时，需要不断使用MPLS回显请求消息在出口节点上创建和删除BFD会话。如果可以实例化、停止和恢复LSP任何路径上的BFD会话，而无需通过MPLS回送请求消息执行额外的引导过程，那么这将大大简化实现和操作，并有利于网络设备，因为它们需要的处理更少。
To support this requirement, multiple S-BFD sessions need to be established over different ECMP paths between the same pair of source and target nodes.
为了支持这一需求，需要在同一对源节点和目标节点之间的不同ECMP路径上建立多个S-BFD会话。
REQ 1: Upon receipt of an S-BFD packet, a target network entity (for the S-BFD session) MUST process the packet based on the discriminator received in the BFD packet. If the S-BFD context is found, the target network entity MUST be able to send a response.
REQ 1：收到S-BFD数据包后，目标网络实体（用于S-BFD会话）必须根据BFD数据包中接收到的鉴别器处理该数据包。如果找到S-BFD上下文，则目标网络实体必须能够发送响应。
REQ 2: The source network entity MUST be able to establish a unidirectional S-BFD session without the bidirectional handshake of discriminators for session establishment.
REQ 2：源网络实体必须能够建立单向S-BFD会话，而不需要鉴别器的双向握手来建立会话。
REQ 3: The S-BFD session MUST be able to be established without the need for the exchange of discriminators during session negotiation.
请求3：在会话协商期间，必须能够在不需要交换鉴别器的情况下建立S-BFD会话。
REQ 4: In a Segment Routed network, S-BFD MUST be able to perform liveness detection initiated from a centralized controller for any given segment in its domain.
REQ 4：在段路由网络中，S-BFD必须能够对其域中的任何给定段执行由中央控制器启动的活动性检测。
REQ 5: The established S-BFD session parameters and attributes, such as transmission interval and reception interval, MUST be modifiable without changing the state of the session.
REQ 5：建立的S-BFD会话参数和属性，如传输间隔和接收间隔，必须在不改变会话状态的情况下进行修改。
REQ 6: An S-BFD source network entity MUST be able to send Control packets to an anycast address. These packets are received and processed by any node hosting the anycast address. The S-BFD entity MUST be able to receive responses to S-BFD Control packets from any of these anycast nodes, without establishing a separate S-BFD session with every node hosting the anycast address.
请求6：S-BFD源网络实体必须能够向选播地址发送控制数据包。这些数据包由承载选播地址的任何节点接收和处理。S-BFD实体必须能够从这些选播节点中的任何一个接收对S-BFD控制数据包的响应，而无需与承载选播地址的每个节点建立单独的S-BFD会话。
REQ 7: S-BFD SHOULD support fault-isolation capability, which MAY be triggered when a fault is encountered.
要求7:S-BFD应支持故障隔离功能，当遇到故障时，可能会触发该功能。
REQ 8: S-BFD SHOULD be able to establish multiple sessions between the same pair of source and target nodes. This requirement enables but does not guarantee the ability to monitor divergent paths in ECMP environments. It also provides resiliency in distributed router architectures. The mapping between BFD Discriminators and particular entities (e.g., ECMP paths, line cards) is out of scope for the S-BFD protocol.
请求8:S-BFD应该能够在同一对源节点和目标节点之间建立多个会话。这一要求允许但不保证在ECMP环境中监控不同路径的能力。它还为分布式路由器体系结构提供了弹性。BFD鉴别器和特定实体（如ECMP路径、线路卡）之间的映射不在S-BFD协议的范围内。
REQ 9: The S-BFD protocol MUST provide mechanisms for loop detection and prevention, protecting against malicious attacks attempting to create packet loops.
REQ 9:S-BFD协议必须提供循环检测和预防机制，防止试图创建数据包循环的恶意攻击。
REQ 10: S-BFD MUST incorporate robust security protections against impersonators, malicious actors, and various active and passive attacks. The simple and accelerated establishment of an S-BFD session should not negatively affect security.
要求10:S-BFD必须包含针对冒名顶替者、恶意参与者和各种主动和被动攻击的强大安全保护。简单而快速地建立S-BFD会话不应对安全产生负面影响。
This document details use cases for S-BFD and identifies various associated requirements. Some of these requirements are security related. The use cases described herein do not expose a system to abuse or additional security risks. Since some negotiation aspects are eliminated, a misconfiguration can result in S-BFD packets being sent to an incorrect node. If this receiving node runs S-BFD, the packet will be discarded due to discriminator mismatch. If the node does not run S-BFD, the packet will be naturally discarded.
本文件详细说明了S-BFD的用例，并确定了各种相关需求。其中一些要求与安全相关。本文描述的用例不会使系统暴露于滥用或附加安全风险。由于消除了某些协商方面，错误配置可能会导致S-BFD数据包被发送到不正确的节点。如果此接收节点运行S-BFD，则由于鉴别器不匹配，数据包将被丢弃。如果节点不运行S-BFD，数据包将自然丢弃。
The proposed new protocols, extensions, and enhancements for S-BFD supporting these use cases and realizing these requirements will address associated security considerations. S-BFD should not have reduced security capabilities as compared to traditional BFD.
为支持这些用例并实现这些需求的S-BFD提出的新协议、扩展和增强将解决相关的安全问题。与传统BFD相比，S-BFD的安全性能不应降低。
[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>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 5880，DOI 10.17487/RFC5880，2010年6月<http://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, <http://www.rfc-editor.org/info/rfc5881>.
[RFC5881]Katz，D.和D.Ward，“IPv4和IPv6（单跳）的双向转发检测（BFD）”，RFC 5881，DOI 10.17487/RFC5881，2010年6月<http://www.rfc-editor.org/info/rfc5881>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, <http://www.rfc-editor.org/info/rfc5883>.
[RFC5883]Katz，D.和D.Ward，“多跳路径的双向转发检测（BFD）”，RFC 5883，DOI 10.17487/RFC5883，2010年6月<http://www.rfc-editor.org/info/rfc5883>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, <http://www.rfc-editor.org/info/rfc5884>.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 5884，DOI 10.17487/RFC5884，2010年6月<http://www.rfc-editor.org/info/rfc5884>.
[RFC5885] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, <http://www.rfc-editor.org/info/rfc5885>.
[RFC5885]Nadeau，T.，Ed.，和C.Pignataro，Ed.，“用于伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，RFC 5885，DOI 10.17487/RFC5885，2010年6月<http://www.rfc-editor.org/info/rfc5885>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC7911981年9月<http://www.rfc-editor.org/info/rfc791>.
[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>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <http://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<http://www.rfc-editor.org/info/rfc3031>.
[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>.
[RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. Aldrin, "Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, DOI 10.17487/RFC7726, January 2016, <http://www.rfc-editor.org/info/rfc7726>.
[RFC7726]Govindan，V.，Rajaraman，K.，Mirsky，G.，Akiya，N.，和S.Aldrin，“为MPLS标签交换路径（LSP）建立BFD会话的澄清程序”，RFC 7726，DOI 10.17487/RFC7726，2016年1月<http://www.rfc-editor.org/info/rfc7726>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, <http://www.rfc-editor.org/info/rfc7880>.
[RFC7880]Pignataro，C.，Ward，D.，Akiya，N.，Bhatia，M.，和S.Pallagati，“无缝双向转发检测（S-BFD）”，RFC 7880，DOI 10.17487/RFC78802016年7月<http://www.rfc-editor.org/info/rfc7880>.
[RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, <http://www.rfc-editor.org/info/rfc7881>.
[RFC7881]Pignataro，C.，Ward，D.，和N.Akiya，“IPv4，IPv6和MPLS的无缝双向转发检测（S-BFD）”，RFC 7881，DOI 10.17487/RFC7881，2016年7月<http://www.rfc-editor.org/info/rfc7881>.
[SR-ARCH] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-09, July 2016.
[SR-ARCH]Filsfils，C.，Ed.，Previdi，S.，Ed.，Decarene，B.，Litkowski，S.，和R.Shakir，“分段布线架构”，正在进行的工作，草案-ietf-spring-Segment-Routing-092016年7月。
[SR-MPLS] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Dataplane Monitoring System", Work in Progress, draft-ietf-spring-oam-usecase-03, April 2016.
[SR-MPLS]Geib，R.，Ed.，Filsfils，C.，Pignataro，C.，Ed.，和N.Kumar，“可扩展和拓扑感知的MPLS数据平面监控系统”，正在进行的工作，草稿-ietf-spring-oam-usecase-032016年4月。
[SR-OAM-REQS] Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., and S. Litkowski, "OAM Requirements for Segment Routing Network", Work in Progress, draft-ietf-spring-sr-oam-requirement-02, July 2016.
[SR-OAM-REQS]Kumar，N.，Pignataro，C.，Akiya，N.，Geib，R.，Mirsky，G.，和S.Litkowski，“分段路由网络的OAM要求”，在建工程，草案-ietf-spring-SR-OAM-requirement-022016年7月。
Acknowledgements
致谢
The authors would like to thank Tobias Gondrom and Eric Gray for their insightful and useful comments. The authors appreciate the thorough review and comments provided by Dale R. Worley.
作者要感谢Tobias Gondrom和Eric Gray，感谢他们的见解和有用的评论。作者感谢Dale R.Worley提供的全面审查和评论。
Contributors
贡献者
The following are key contributors to this document:
以下是本文件的主要贡献者：
Manav Bhatia, Ionos Networks Satoru Matsushima, Softbank Glenn Hayden, ATT Santosh P K Mach Chen, Huawei Nobo Akiya, Big Switch Networks
Manav Bhatia、Ionos Networks Satoru Matsushima、软银Glenn Hayden、ATT Santosh P K Mach Chen、华为Nobo Akiya、大交换机网络
Authors' Addresses
作者地址
Sam Aldrin Google, Inc.
山姆·奥尔德林谷歌公司。
Email: aldrin.ietf@gmail.com
Email: aldrin.ietf@gmail.com
Carlos Pignataro Cisco Systems, Inc.
卡洛斯·皮格纳塔罗思科系统公司。
Email: cpignata@cisco.com
Email: cpignata@cisco.com
Greg Mirsky Ericsson
格雷格·米尔斯基·爱立信
Email: gregory.mirsky@ericsson.com
Email: gregory.mirsky@ericsson.com
Nagendra Kumar Cisco Systems, Inc.
纳贡德拉·库马尔思科系统公司。
Email: naikumar@cisco.com
Email: naikumar@cisco.com