Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 8562 Juniper Networks
Updates: 5880 D. Ward
Category: Standards Track Cisco Systems
ISSN: 2070-1721 S. Pallagatti, Ed.
VMware
G. Mirsky, Ed.
ZTE Corp.
April 2019
Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 8562 Juniper Networks
Updates: 5880 D. Ward
Category: Standards Track Cisco Systems
ISSN: 2070-1721 S. Pallagatti, Ed.
VMware
G. Mirsky, Ed.
ZTE Corp.
April 2019
Bidirectional Forwarding Detection (BFD) for Multipoint Networks
多点网络的双向转发检测（BFD）
Abstract
摘要
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks.
本文档描述了双向转发检测（BFD）协议在多点和多播网络中的扩展。
This document updates RFC 5880.
本文档更新了RFC 5880。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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 https://www.rfc-editor.org/info/rfc8562.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8562.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 6
5.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Session-Failure Semantics . . . . . . . . . . . . . . . . 6
5.4. State Variables . . . . . . . . . . . . . . . . . . . . . 6
5.4.1. New State Variable Values . . . . . . . . . . . . . . 6
5.4.2. State Variable Initialization and Maintenance . . . . 7
5.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 7
5.6. Session Establishment . . . . . . . . . . . . . . . . . . 8
5.7. Discriminators and Packet Demultiplexing . . . . . . . . 8
5.8. Packet Consumption on Tails . . . . . . . . . . . . . . . 9
5.9. Bringing Up and Shutting Down Multipoint BFD Service . . 9
5.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 10
5.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 10
5.12. State Maintenance for Down/AdminDown Sessions . . . . . . 11
5.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 11
5.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 11
5.13. Base Specification Text Replacement . . . . . . . . . . . 11
5.13.1. Reception of BFD Control Packets . . . . . . . . . . 12
5.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 15
5.13.3. Transmitting BFD Control Packets . . . . . . . . . . 16
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 6
5.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Session-Failure Semantics . . . . . . . . . . . . . . . . 6
5.4. State Variables . . . . . . . . . . . . . . . . . . . . . 6
5.4.1. New State Variable Values . . . . . . . . . . . . . . 6
5.4.2. State Variable Initialization and Maintenance . . . . 7
5.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 7
5.6. Session Establishment . . . . . . . . . . . . . . . . . . 8
5.7. Discriminators and Packet Demultiplexing . . . . . . . . 8
5.8. Packet Consumption on Tails . . . . . . . . . . . . . . . 9
5.9. Bringing Up and Shutting Down Multipoint BFD Service . . 9
5.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 10
5.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 10
5.12. State Maintenance for Down/AdminDown Sessions . . . . . . 11
5.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 11
5.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 11
5.13. Base Specification Text Replacement . . . . . . . . . . . 11
5.13.1. Reception of BFD Control Packets . . . . . . . . . . 12
5.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 15
5.13.3. Transmitting BFD Control Packets . . . . . . . . . . 16
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] specifies a method for verifying unicast connectivity between a pair of systems. This document updates [RFC5880] by defining a new method for using BFD. This new method provides verification of multipoint or multicast connectivity between a multipoint sender (the "head") and a set of one or more multipoint receivers (the "tails").
双向转发检测（BFD）协议[RFC5880]规定了验证一对系统之间单播连接的方法。本文档通过定义使用BFD的新方法来更新[RFC5880]。这种新方法提供了多点发送器（“头”）和一组或多个多点接收器（“尾”）之间的多点或多播连接验证。
As multipoint transmissions are inherently unidirectional, this mechanism purports only to verify this unidirectional connectivity. Although this seems in conflict with the "Bidirectional" in BFD, the protocol is capable of supporting this use case. Use of BFD in Demand mode allows a tail to monitor the availability of a multipoint path even without the existence of some kind of a return path to the head. As an option, if a return path from a tail to the head exists, the tail may notify the head of the lack of multipoint connectivity. Details of tail notification to the head are outside the scope of this document and are discussed in [RFC8563].
由于多点传输本质上是单向的，因此该机制旨在验证这种单向连接。尽管这似乎与BFD中的“双向”冲突，但该协议能够支持该用例。在需求模式下使用BFD允许尾部监控多点路径的可用性，即使头部不存在某种返回路径。作为一种选择，如果存在从尾部到头部的返回路径，则尾部可能会通知头部缺少多点连接。向负责人发送尾部通知的详细信息不在本文件的范围内，并在[RFC8563]中讨论。
This application of BFD allows for the tails to detect a lack of connectivity from the head. For some applications, such detection of the failure at the tail is useful, for example, the use of multipoint BFD to enable fast failure detection and faster failover in multicast VPN as described in [MVPN-FAILOVER]. Due to its unidirectional nature, virtually all options and timing parameters are controlled by the head.
BFD的这种应用允许尾部检测头部的连通性不足。对于某些应用程序，这种尾部故障检测非常有用，例如，使用多点BFD在多播VPN中实现快速故障检测和快速故障切换，如[MVPN-failover]中所述。由于其单向性，几乎所有选项和定时参数都由磁头控制。
Throughout this document, the term "multipoint" is defined as a mechanism by which one or more systems receive packets sent by a single sender. This specifically includes such things as IP multicast and point-to-multipoint MPLS.
在本文件中，术语“多点”定义为一个或多个系统接收单个发送方发送的数据包的机制。这具体包括IP多播和点对多点MPLS。
The term "connectivity" in this document is not being used in the context of connectivity verification in a transport network but as an alternative to "continuity", i.e., the existence of a forwarding path between the sender and the receiver.
本文件中的术语“连接性”不用于传输网络中的连接性验证，而是作为“连续性”的替代，即发送方和接收方之间存在转发路径。
This document effectively updates and extends the base BFD specification [RFC5880].
本文件有效地更新和扩展了基本BFD规范[RFC5880]。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The primary goal of this mechanism is to allow tails to rapidly detect the fact that multipoint connectivity from the head has failed.
该机制的主要目标是允许TAIL快速检测来自头部的多点连接失败的事实。
Another goal is for the mechanism to work on any multicast technology.
另一个目标是使该机制能够在任何多播技术上工作。
A further goal is to support multiple, overlapping point-to-multipoint paths, as well as multipoint-to-multipoint paths, and to allow point-to-point BFD sessions to operate simultaneously among the systems participating in multipoint BFD.
进一步的目标是支持多个重叠的点对多点路径以及多点对多点路径，并允许点对点BFD会话在参与多点BFD的系统之间同时运行。
It is not a goal for this protocol to verify point-to-point bidirectional connectivity between the head and any tail. This can be done independently (and with no penalty in protocol overhead) by using point-to-point BFD.
该协议的目标不是验证头部和任何尾部之间的点对点双向连接。这可以通过使用点对点BFD独立完成（并且不会对协议开销造成任何损失）。
The heart of this protocol is the periodic transmission of BFD Control packets along a multipoint path, from the head to all tails on the path. The contents of the BFD packets provide the means for the tails to calculate the Detection Time for path failure. If no BFD Control packets are received by a tail for a Detection Time, the tail declares that the path has failed. For some applications, this is the only mechanism necessary; the head can remain ignorant of the status of connectivity to the tails.
该协议的核心是BFD控制数据包在多点路径上的周期性传输，从路径的头部到所有尾部。BFD包的内容为尾部提供了计算路径故障检测时间的方法。如果尾部在检测时间内未接收到BFD控制数据包，则尾部会声明路径已失败。对于某些应用，这是唯一必要的机制；头部可以不知道尾部的连接状态。
The head of a multipoint BFD session may wish to be alerted to the tails' connectivity (or lack thereof). Details of how the head keeps track of tails and how tails alert their connectivity to the head are outside the scope of this document and are discussed in [RFC8563].
多点BFD会话的头部可能希望收到尾部连接（或缺乏连接）的警报。头部如何跟踪尾部以及尾部如何提醒其与头部的连接的详细信息不在本文档的范围内，并在[RFC8563]中讨论。
Although this document describes a single head and a set of tails spanned by a single multipoint path, the protocol is capable of supporting (and discriminating between) more than one multipoint path at both heads and tails, as described in Sections 5.7 and 5.13.2. Furthermore, the same head and tail may share multiple multipoint paths, and a multipoint path may have multiple heads.
尽管本文件描述了由单个多点路径跨越的单个头部和一组尾部，但如第5.7节和第5.13.2节所述，协议能够在头部和尾部支持（并区分）多个多点路径。此外，相同的头部和尾部可以共享多个多点路径，并且多点路径可以具有多个头部。
This section describes the operation of Multipoint BFD in detail.
本节详细介绍了多点BFD的操作。
Multipoint BFD Control packets (packets sent by the head over a multipoint path) are explicitly marked as such, via the setting of the Multipoint (M) bit [RFC5880]. This means that multipoint BFD does not depend on the recipient of a packet to know whether the packet was received over a multipoint path. This can be useful in scenarios where this information may not be available to the recipient.
多点BFD控制数据包（由头部通过多点路径发送的数据包）通过设置多点（M）位[RFC5880]明确标记为这样。这意味着多点BFD不依赖于数据包的接收者来知道数据包是否通过多点路径接收。这在收件人可能无法获得此信息的情况下非常有用。
Multipoint BFD is modeled as a set of sessions of different types. The elements of procedure differ slightly for each type.
多点BFD被建模为一组不同类型的会话。每种类型的程序要素略有不同。
The head has a session of type MultipointHead, as defined in Section 5.4.1, that is bound to a multipoint path. Multipoint BFD Control packets are sent by this session over the multipoint path, and no BFD Control packets are received by it.
如第5.4.1节所述，磁头有一个多点AD类型的会话，该会话绑定到多点路径。此会话通过多点路径发送多点BFD控制数据包，但未接收任何BFD控制数据包。
Each tail has a session of type MultipointTail, as defined in Section 5.4.1, associated with a multipoint path. These sessions receive BFD Control packets from the head over the multipoint path.
如第5.4.1节所定义，每个尾部都有一个与多点路径相关的多点尾部类型的会话。这些会话通过多点路径从头部接收BFD控制数据包。
The semantics of session failure is subtle enough to warrant further explanation.
会话失败的语义非常微妙，值得进一步解释。
MultipointHead sessions cannot fail (since they are controlled administratively).
多线程会话不能失败（因为它们受管理控制）。
If a MultipointTail session fails, it means that the tail definitely has lost contact with the head (or the head has been administratively disabled), and the tail may use mechanisms other than BFD, e.g., logging or NETCONF [RFC6241], to send a notification to the user.
如果多点tail会话失败，则意味着tail肯定与头部失去了联系（或者头部已被管理性禁用），并且tail可以使用BFD以外的机制，例如日志记录或NETCONF[RFC6241]，向用户发送通知。
Multipoint BFD introduces some new state variables and modifies the usage of a few existing ones.
多点BFD引入了一些新的状态变量，并修改了一些现有状态变量的用法。
A number of new values of the state variable bfd.SessionType are added to the base BFD [RFC5880] and base Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] specifications in support of multipoint BFD.
状态变量bfd.SessionType的许多新值添加到基本bfd[RFC5880]和基本无缝双向转发检测（S-bfd）[RFC7880]规范中，以支持多点bfd。
bfd.SessionType
bfd.SessionType
The type of this session as defined in [RFC7880]. Newly added values are:
[RFC7880]中定义的此会话的类型。新增值为：
PointToPoint: Classic point-to-point BFD, as described in [RFC5880].
点到点：经典的点到点BFD，如[RFC5880]所述。
MultipointHead: A session on the head responsible for the periodic transmission of multipoint BFD Control packets along the multipoint path.
MultipointHead：头部的一个会话，负责沿多点路径定期传输多点BFD控制数据包。
MultipointTail: A multipoint session on a tail.
多点尾部：尾部上的多点会话。
This variable MUST be initialized to the appropriate type when the session is created.
创建会话时，必须将此变量初始化为适当的类型。
Some state variables defined in Section 6.8.1 of [RFC5880] need to be initialized or manipulated differently depending on the session type.
[RFC5880]第6.8.1节中定义的一些状态变量需要根据会话类型进行不同的初始化或操作。
bfd.RequiredMinRxInterval
bfd.RequiredMinRxInterval
This variable MUST be initialized to zero for session type MultipointHead.
对于会话类型MultipoInHead，此变量必须初始化为零。
bfd.DemandMode
需求模式
This variable MUST be initialized to 1 for session type MultipointHead and MUST be initialized to zero for session type MultipointTail.
对于会话类型MultipointTail，此变量必须初始化为1；对于会话类型MultipointTail，此变量必须初始化为零。
There are slight differences in how the BFD state machine works in the multipoint application. In particular, since there is a many-to-one mapping, three-way handshakes for session establishment and teardown are neither possible nor appropriate. As such, there is no Init state. Sessions of type MultipointHead MUST NOT send BFD Control packets with the State field being set to INIT, and those packets MUST be ignored on receipt.
BFD状态机在多点应用程序中的工作方式略有不同。特别是，由于存在多对一映射，会话建立和拆卸的三方握手既不可能也不合适。因此，不存在Init状态。MultipointHead类型的会话不能发送状态字段设置为INIT的BFD控制数据包，并且在收到这些数据包时必须忽略这些数据包。
The following diagram provides an overview of the state machine for session type MultipointTail. The notation on each arc represents the state of the remote system (as received in the State field in the BFD Control packet) or indicates the expiration of the Detection Timer.
下图概述了会话类型MultipointTail的状态机。每个arc上的符号表示远程系统的状态（在BFD控制数据包的状态字段中接收）或指示检测计时器的过期。
DOWN, ADMIN DOWN,
+------+ TIMER +------+
+----| |<---------------------| |----+
DOWN,| | DOWN | | UP | |UP
ADMIN DOWN,+--->| |--------------------->| |<---+
TIMER +------+ UP +------+
DOWN, ADMIN DOWN,
+------+ TIMER +------+
+----| |<---------------------| |----+
DOWN,| | DOWN | | UP | |UP
ADMIN DOWN,+--->| |--------------------->| |<---+
TIMER +------+ UP +------+
Sessions of type MultipointHead never receive packets and have no Detection Timer; as such, all state transitions are administratively driven.
AD类型的会话从不接收数据包，也没有检测计时器；因此，所有状态转换都是由管理驱动的。
Unlike point-to-point BFD, multipoint BFD provides a form of the discovery mechanism that enables tails to discover the head. The minimum amount of a priori information required both on the head and tails is the binding to the multipoint path over which BFD is running. The head transmits multipoint BFD packets on that path, and the tails listen for BFD packets on that path. All other information can be determined dynamically.
与点对点BFD不同，多点BFD提供了一种发现机制，使尾部能够发现头部。头部和尾部所需的最小先验信息量是绑定到运行BFD的多点路径。头部在该路径上传输多点BFD数据包，尾部在该路径上侦听BFD数据包。所有其他信息都可以动态确定。
A session of type MultipointHead is created for each multipoint path over which the head wishes to run BFD. This session runs in the Active role, per Section 6.1 of [RFC5880]. Except when administratively terminating BFD service, this session is always in state Up and always operates in Demand mode. No received packets are ever demultiplexed to the MultipointHead session. In this sense, it is a degenerate form of a session.
为头部希望在其上运行BFD的每个多点路径创建MultipointHead类型的会话。根据[RFC5880]第6.1节，此会话以活动角色运行。除非以管理方式终止BFD服务，否则此会话始终处于启动状态，并且始终以请求模式运行。从未将接收到的数据包解复用到MultiPinterAD会话。从这个意义上讲，这是一种退化的会话形式。
Sessions on the tail MAY be established dynamically, based on the receipt of a multipoint BFD Control packet from the head, and are of type MultipointTail. Tail sessions always take the Passive role, per Section 6.1 of [RFC5880].
基于从头部接收到多点BFD控制数据包，可以动态地建立尾部上的会话，会话类型为MultipointTail。根据[RFC5880]第6.1节，尾会话始终扮演被动角色。
The use of discriminators is somewhat different in multipoint BFD than in point-to-point BFD.
鉴别器在多点BFD和点对点BFD中的使用有所不同。
The head sends multipoint BFD Control packets over the multipoint path via the MultipointHead session with My Discriminator set to a value bound to the multipoint path and with Your Discriminator set to zero.
头部通过MultiPointInHead会话通过多点路径发送多点BFD控制数据包，将我的鉴别器设置为绑定到多点路径的值，并将您的鉴别器设置为零。
IP and MPLS multipoint tails MUST demultiplex BFD packets based on a combination of the source address, My Discriminator, and the identity of the multipoint path that the multipoint BFD Control packet was received from. Together they uniquely identify the head of the
IP和MPLS多点尾部必须根据源地址、我的鉴别器和接收多点BFD控制数据包的多点路径标识的组合来解复用BFD数据包。它们一起唯一地识别了大脑的头部
multipoint path. Bootstrapping a BFD session to multipoint MPLS Label Switched Path (LSP) may use the control plane, e.g., as described in [MVPN-FAILOVER], and is outside the scope of this document.
多点路径。将BFD会话引导到多点MPLS标签交换路径（LSP）可能会使用控制平面，如[MVPN-FAILOVER]中所述，并且不在本文档的范围内。
Note that, unlike point-to-point sessions, the My Discriminator value on the MultipointHead session MUST NOT be changed during the life of a session. This is a side effect of the more complex demultiplexing scheme.
请注意，与点对点会话不同，在会话的生命周期内，不得更改MultiPineTad会话上的“我的鉴别器”值。这是更复杂的解复用方案的副作用。
BFD packets received on tails for an IP multicast group MUST be consumed by tails and MUST NOT be forwarded to receivers. Nodes with the BFD session of type MultipointTail MUST identify packets received on an IP multipoint path as a BFD Control packet if the destination UDP port value equals 3784.
IP多播组在尾部接收的BFD数据包必须由尾部使用，并且不得转发给接收方。如果目标UDP端口值等于3784，则具有MultipointTail类型BFD会话的节点必须将在IP多点路径上接收的数据包标识为BFD控制数据包。
For multipoint LSPs, when IP/UDP encapsulation of BFD Control packets is used, MultipointTail MUST expect destination UDP port 3784. The destination IP address of a BFD Control packet MUST be in the 127.0.0.0/8 range for IPv4 or in the 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6. The use of these destination addresses is consistent with the explanations and usage in [RFC8029]. Packets identified as BFD packets MUST be consumed by MultipointTail and demultiplexed as described in Section 5.13.2. Use of other types of encapsulation of the BFD control message over multipoint LSP is outside the scope of this document.
对于多点LSP，当使用BFD控制数据包的IP/UDP封装时，MultipointTail必须预期目标UDP端口3784。BFD控制数据包的目标IP地址对于IPv4必须在127.0.0.0/8范围内，对于IPv6必须在0:0:0:0:0:FFFF:7F00:0/104范围内。这些目标地址的使用与[RFC8029]中的说明和用法一致。标识为BFD数据包的数据包必须由MultipointTail使用，并按照第5.13.2节的说明进行解复用。在多点LSP上使用其他类型的BFD控制消息封装超出了本文档的范围。
Because there is no three-way handshake in multipoint BFD, a newly started head (that does not have any previous state information available) SHOULD start with bfd.SessionState set to Down, and bfd.RequiredMinRxInterval MUST be set to zero in the MultipointHead session. The session SHOULD remain in this state for a time equal to (bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that all MultipointTail sessions are reset (so long as the restarted head is using the same or a larger value of bfd.DesiredMinTxInterval than it did previously).
因为在多点BFD中没有三向握手，所以新启动的磁头（没有任何以前的状态信息可用）应该在BFD.SessionState设置为Down的情况下启动，并且在多点BFD会话中BFD.RequiredMinRxInterval必须设置为零。会话应保持此状态的时间等于（bfd.DesiredMinTxInterval*bfd.DetectMult）。这将确保重置所有多点尾会话（只要重新启动的磁头使用与以前相同或更大的bfd.DesiredMinTxInterval值）。
Multipoint BFD service is brought up by administratively setting bfd.SessionState to Up in the MultipointHead session.
多点BFD服务是通过管理方式将多点BFD会话中的BFD.SessionState设置为up来启动的。
The head of a multipoint BFD session may wish to shut down its BFD service in a controlled fashion. This is desirable because the tails need not wait for a Detection Time prior to declaring the multipoint session to be down (and taking whatever action is necessary in that case).
多点BFD会话的负责人可能希望以受控方式关闭其BFD服务。这是可取的，因为尾部不需要在宣布多点会话关闭（并在这种情况下采取任何必要的措施）之前等待检测时间。
To shut down a multipoint session in a controlled fashion, the head MUST administratively set bfd.SessionState in the MultipointHead session to either Down or AdminDown and SHOULD set bfd.RequiredMinRxInterval to zero. The session SHOULD send BFD Control packets in this state for a period equal to (bfd.DesiredMinTxInterval * bfd.DetectMult). Alternatively, the head MAY stop transmitting BFD Control packets and not send any more BFD Control packets with the new state (Down or AdminDown). Tails will declare the multipoint session down only after the Detection Time interval runs out.
若要以受控方式关闭多点会话，标头必须以管理方式将多点会话中的bfd.SessionState设置为down或AdminDown，并应将bfd.RequiredMinRxInterval设置为零。会话应在此状态下发送BFD控制数据包，发送时间等于（BFD.DesiredMinTxInterval*BFD.DetectMult）。或者，头部可以停止发送BFD控制分组，并且不再发送任何具有新状态（Down或AdminDown）的BFD控制分组。只有在检测时间间隔结束后，Tails才会宣布多点会话关闭。
Because of the one-to-many mapping, a session of type MultipointHead SHOULD NOT initiate a Poll Sequence in conjunction with timer value changes. However, to indicate a change in the packets, a MultipointHead session MUST send packets with the P bit set. A MultipointTail session MUST NOT reply if the packet has the M and P bits set and bfd.RequiredMinRxInterval set to zero. Because the Poll Sequence is not used, the tail cannot negotiate down MultpointHead's transmit interval. If the value of Desired Min TX Interval in the BFD Control packet received by MultipointTail is too high (that determination may change in time based on the current environment), it must be handled by the implementation and may be controlled by local policy, e.g., close the MultipointTail session.
由于一对多映射，MultipointHead类型的会话不应在计时器值更改的同时启动轮询序列。然而，为了指示数据包中的变化，多线程会话必须发送设置了P位的数据包。如果数据包设置了M和P位，并且bfd.RequiredMinRxInterval设置为零，则多点尾会话不得应答。由于未使用轮询序列，尾部无法向下协商多点头的传输间隔。如果MultipointTail接收到的BFD控制数据包中所需的Min TX Interval值过高（该确定可能会根据当前环境在时间上发生变化），则它必须由实现来处理，并且可以由本地策略来控制，例如，关闭MultipointTail会话。
The MultipointHead, when changing the transmit interval to a higher value, MUST send BFD Control packets with the P bit set at the old transmit interval before using the higher value in order to avoid false detection timeouts at the tails. A MultipointHead session MAY also wait some amount of time before making the changes to the transmit interval (through configuration).
当将传输间隔更改为更大的值时，在使用更大的值之前，MultiPinterAD必须发送在旧传输间隔设置了P位的BFD控制数据包，以避免尾部出现错误检测超时。在更改传输间隔（通过配置）之前，多线程会话也可能会等待一段时间。
Change in the value of bfd.RequiredMinRxInterval is outside the scope of this document and is discussed in [RFC8563].
bfd.RequiredMinRxInterval值的更改不在本文件范围内，并在[RFC8563]中讨论。
Multipoint BFD is inherently asymmetric. As such, each session type has a different approach to Detection Times.
多点BFD本质上是不对称的。因此，每种会话类型都有不同的检测时间方法。
Since MultipointHead sessions never receive packets, they do not calculate a Detection Time.
由于多线程会话从不接收数据包，因此它们不计算检测时间。
MultipointTail sessions cannot influence the transmission rate of the MultipointHead session using the Required Min Rx Interval field because of its one-to-many nature. As such, the Detection Time calculation for a MultipointTail session does not use bfd.RequiredMinRxInterval. The Detection Time is calculated as the product of the last received values of Desired Min TX Interval and Detect Mult.
由于多点尾会话的一对多性质，因此它不能使用所需的最小Rx间隔字段影响多点尾会话的传输速率。因此，多点尾会话的检测时间计算不使用bfd.RequiredMinRxInterval。检测时间计算为所需最小发送间隔和检测倍数的最后接收值的乘积。
The value of bfd.DetectMult may be changed at any time on any session type.
bfd.DetectMult的值可以在任何会话类型上随时更改。
The length of time the session state is kept after the session goes down determines how long the session will continue to send BFD Control packets (since no packets can be sent after the session is destroyed).
会话停止后会话状态保持的时间长度决定会话将继续发送BFD控制数据包的时间（因为在会话被破坏后不能发送数据包）。
When a MultipointHead session transitions to states Down or AdminDown, the state SHOULD be maintained for a period equal to (bfd.DesiredMinTxInterval * bfd.DetectMult) to ensure that the tails more quickly detect the session going down (by continuing to transmit BFD Control packets with the new state).
当多线程会话转换为状态Down或AdminDown时，该状态应保持等于（bfd.DesiredIntxinterval*bfd.DetectMult）的一段时间，以确保尾部能够更快地检测到会话正在关闭（通过继续传输具有新状态的bfd控制数据包）。
MultipointTail sessions MAY be destroyed immediately upon leaving Up state, since the tail will transmit no packets.
多点尾会话可能在离开Up状态时立即被破坏，因为尾不会传输任何数据包。
Otherwise, MultipointTail sessions SHOULD be maintained as long as BFD Control packets are being received by it (which by definition will indicate that the head is not Up).
否则，只要BFD控制数据包被它接收到，就应该保持多点尾会话（根据定义，这将表明头部没有向上）。
The following sections are meant to replace the corresponding sections in the base specification [RFC5880] to support BFD for multipoint networks while not changing processing for point-to-point BFD.
以下章节旨在取代基本规范[RFC5880]中的相应章节，以支持多点网络的BFD，同时不改变点对点BFD的处理。
The following procedure replaces Section 6.8.6 of [RFC5880] entirely.
以下程序完全取代[RFC5880]第6.8.6节。
When a BFD Control packet is received, the following procedure MUST be followed, in the order specified. If the packet is discarded according to these rules, processing of the packet MUST cease at that point.
当收到BFD控制数据包时，必须按照指定的顺序执行以下程序。如果根据这些规则丢弃数据包，则数据包的处理必须在该点停止。
If the version number is not correct (1), the packet MUST be discarded.
如果版本号不正确（1），则必须丢弃数据包。
If the Length field is less than the minimum correct value (24 if the A bit is clear, or 26 if the A bit is set), the packet MUST be discarded.
如果长度字段小于最小正确值（A位清除时为24，A位设置时为26），则必须丢弃数据包。
If the Length field is greater than the payload of the encapsulating protocol, the packet MUST be discarded.
如果长度字段大于封装协议的有效负载，则必须丢弃该数据包。
If the Detect Mult field is zero, the packet MUST be discarded.
如果Detect Mult字段为零，则必须丢弃该数据包。
If the My Discriminator field is zero, the packet MUST be discarded.
如果My鉴别器字段为零，则必须丢弃数据包。
Demultiplex the packet to a session according to Section 5.13.2. The result is either a session of the proper type, or the packet is discarded (and packet processing MUST cease).
根据第5.13.2节将数据包解复用到会话。结果要么是正确类型的会话，要么丢弃数据包（数据包处理必须停止）。
If the A bit is set and no authentication is in use (bfd.AuthType is zero), the packet MUST be discarded.
如果设置了A位且未使用身份验证（bfd.AuthType为零），则必须丢弃该数据包。
If the A bit is clear and authentication is in use (bfd.AuthType is nonzero), the packet MUST be discarded.
如果A位已清除且正在使用身份验证（bfd.AuthType为非零），则必须丢弃该数据包。
If the A bit is set, the packet MUST be authenticated under the rules of Section 6.7 of [RFC5880], based on the authentication type in use (bfd.AuthType). This may cause the packet to be discarded.
如果设置了A位，则必须根据[RFC5880]第6.7节的规则，基于使用的身份验证类型（bfd.AuthType），对数据包进行身份验证。这可能导致数据包被丢弃。
Set bfd.RemoteDiscr to the value of My Discriminator.
将bfd.RemoteDiscr设置为我的鉴别器的值。
Set bfd.RemoteState to the value of the State (Sta) field.
将bfd.RemoteState设置为状态（Sta）字段的值。
Set bfd.RemoteDemandMode to the value of the Demand (D) bit.
将bfd.RemoteDemandMode设置为需求（D）位的值。
Set bfd.RemoteMinRxInterval to the value of Required Min RX Interval.
将bfd.RemoteMinRxInterval设置为所需的最小接收间隔值。
If the Required Min Echo RX Interval field is zero, the transmission of Echo packets, if any, MUST cease.
如果所需的最小回波接收间隔字段为零，则必须停止回波数据包（如果有）的传输。
If a Poll Sequence is being transmitted by the local system and the Final (F) bit in the received packet is set, the Poll Sequence MUST be terminated.
如果本地系统正在传输轮询序列，并且设置了接收数据包中的最后（F）位，则必须终止轮询序列。
If bfd.SessionType is PointToPoint, update the transmit interval as described in Section 6.8.2 of [RFC5880].
如果bfd.SessionType为PointToPoint，则按照[RFC5880]第6.8.2节所述更新传输间隔。
If bfd.SessionType is PointToPoint, update the Detection Time as described in Section 6.8.4 of [RFC5880].
如果bfd.SessionType为PointToPoint，则按照[RFC5880]第6.8.4节所述更新检测时间。
Else
其他的
If bfd.SessionType is MultipointTail, then update the Detection Time as the product of the last received values of Desired Min TX Interval and Detect Mult, as described in Section 5.11 of this specification.
如果bfd.SessionType为MultipointTail，则按照本规范第5.11节所述，将检测时间更新为所需最小发送间隔和检测Mult的最后接收值的乘积。
If bfd.SessionState is AdminDown
如果bfd.SessionState为AdminDown
Discard the packet
丢弃包
If the received State is AdminDown
如果接收到的状态为AdminDown
If bfd.SessionState is not Down
如果bfd.SessionState未关闭
Set bfd.LocalDiag to 3 (Neighbor signaled session down)
将bfd.LocalDiag设置为3（邻居信号会话关闭）
Set bfd.SessionState to Down
将bfd.SessionState设置为Down
Else
其他的
If bfd.SessionState is Down
如果bfd.SessionState已关闭
If bfd.SessionType is PointToPoint
如果bfd.SessionType是PointToPoint
If received State is Down
如果接收状态为“关闭”
Set bfd.SessionState to Init
将bfd.SessionState设置为Init
Else if received State is Init
否则，如果接收状态为Init
Set bfd.SessionState to Up
将bfd.SessionState设置为Up
Else (bfd.SessionType is not PointToPoint)
Else（bfd.SessionType不是PointToPoint）
If received State is Up
如果接收状态为“上”
Set bfd.SessionState to Up
将bfd.SessionState设置为Up
Else if bfd.SessionState is Init
否则，如果bfd.SessionState为Init
If received State is Init or Up
如果接收状态为Init或Up
Set bfd.SessionState to Up
将bfd.SessionState设置为Up
Else (bfd.SessionState is Up)
否则（bfd.SessionState已启动）
If received State is Down
如果接收状态为“关闭”
Set bfd.LocalDiag to 3 (Neighbor signaled session down)
将bfd.LocalDiag设置为3（邻居信号会话关闭）
Set bfd.SessionState to Down
将bfd.SessionState设置为Down
Check to see if Demand mode should become active or not (see [RFC5880], Section 6.6).
检查需求模式是否应激活（参见[RFC5880]，第6.6节）。
If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and bfd.RemoteSessionState is Up, Demand mode is active on the remote system and the local system MUST cease the periodic transmission of BFD Control packets (see Section 5.13.3).
如果bfd.RemoteDemandMode为1，bfd.SessionState为Up，bfd.RemoteSessionState为Up，则远程系统上的请求模式处于活动状态，本地系统必须停止定期传输bfd控制数据包（见第5.13.3节）。
If bfd.RemoteDemandMode is zero, bfd.SessionState is not Up, or bfd.RemoteSessionState is not Up, Demand mode is not active on the remote system and the local system MUST send periodic BFD Control packets (see Section 5.13.3).
如果bfd.RemoteDemandMode为零，bfd.SessionState未启动，或bfd.RemoteSessionState未启动，则远程系统上的请求模式未激活，本地系统必须定期发送bfd控制数据包（见第5.13.3节）。
If the Poll (P) bit is set, and bfd.SessionType is PointToPoint, send a BFD Control packet to the remote system with the Poll (P) bit clear, and the Final (F) bit set (see Section 5.13.3).
如果设置了轮询（P）位，且bfd.SessionType为PointToPoint，则向远程系统发送bfd控制数据包，清除轮询（P）位，并设置最终（F）位（见第5.13.3节）。
If the packet was not discarded, it has been received for purposes of the Detection Time expiration rules in Section 6.8.4 of [RFC5880].
如果未丢弃数据包，则根据[RFC5880]第6.8.4节中的检测时间到期规则，已收到该数据包。
This section is part of the replacement for Section 6.8.6 of [RFC5880]; it is separated for clarity.
本节是[RFC5880]第6.8.6节替换内容的一部分；为了清楚起见，它是分开的。
If the Multipoint (M) bit is set
如果设置了多点（M）位
If the Your Discriminator field is nonzero, the packet MUST be discarded.
如果您的鉴别器字段为非零，则必须丢弃该数据包。
Select a session based on the source address, My Discriminator, and the identity of the multipoint path on which the multipoint BFD Control packet was received.
根据源地址、我的鉴别器和接收多点BFD控制数据包的多点路径的标识选择会话。
If a session is found, and bfd.SessionType is not MultipointTail, the packet MUST be discarded.
如果找到会话，并且bfd.SessionType不是MultipointTail，则必须丢弃该数据包。
Else
其他的
If a session is not found, a new session of type MultipointTail MAY be created, or the packet MAY be discarded. This choice can be controlled by the local policy, e.g., by setting a maximum number of MultipointTail sessions. Use of the local policy and the exact mechanism of it are outside the scope of this specification.
如果未找到会话，则可能会创建类型为MultipointTail的新会话，或者丢弃数据包。此选择可由本地策略控制，例如，通过设置多点尾会话的最大数量。本地策略的使用及其确切机制不在本规范的范围内。
Else (Multipoint (M) bit is clear)
Else（多点（M）位清除）
If the Your Discriminator field is nonzero
如果您的鉴别器字段为非零
Select a session based on the value of Your Discriminator. If no session is found, the packet MUST be discarded.
根据鉴别器的值选择会话。如果找不到会话，则必须丢弃数据包。
Else (Your Discriminator is zero)
Else（您的鉴别器为零）
If the State field is not Down or AdminDown, the packet MUST be discarded.
如果State字段不是Down或AdminDown，则必须丢弃数据包。
Otherwise, the session MUST be selected based on some combination of other fields, possibly including source addressing information, the My Discriminator field, and the interface over which the packet was received. The exact method of selection is application specific and is thus outside the scope of this specification.
否则，必须基于其他字段的某些组合来选择会话，可能包括源寻址信息、我的鉴别器字段和接收数据包的接口。具体的选择方法因应用而异，因此不在本规范的范围内。
If a matching session is found, and bfd.SessionType is not PointToPoint, the packet MUST be discarded.
如果找到匹配的会话，并且bfd.SessionType不是PointToPoint，则必须丢弃该数据包。
If a matching session is not found, a new session of type PointToPoint MAY be created, or the packet MAY be discarded. This choice MAY be controlled by a local policy and is outside the scope of this specification.
如果未找到匹配的会话，则可能会创建PointToPoint类型的新会话，或者丢弃数据包。此选择可能由本地策略控制，不在本规范的范围内。
If the State field is Init and bfd.SessionType is not PointToPoint, the packet MUST be discarded.
如果State字段为Init且bfd.SessionType不是PointToPoint，则必须丢弃该数据包。
The following procedure replaces Section 6.8.7 of [RFC5880] entirely.
以下程序完全取代[RFC5880]第6.8.7节。
With the exceptions listed in the remainder of this section, a system MUST NOT transmit BFD Control packets at an interval less than the larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less applied jitter (see below). In other words, the system reporting the slower rate determines the transmission rate.
除本节剩余部分列出的例外情况外，系统传输BFD控制数据包的间隔不得小于BFD.DesiredMinxinterval和BFD.RemoteMinRxInterval中的较大值，也不得小于应用的抖动（见下文）。换句话说，报告较慢速率的系统确定传输速率。
The periodic transmission of BFD Control packets MUST be jittered on a per-packet basis by up to 25%; that is, the interval MUST be reduced by a random value of 0 to 25%, in order to avoid self-synchronization with other systems on the same subnetwork. Thus, the average interval between packets will be roughly 12.5% less than that negotiated.
BFD控制数据包的周期性传输必须在每个数据包的基础上抖动高达25%；也就是说，间隔必须减少0到25%的随机值，以避免与同一子网上的其他系统自同步。因此，数据包之间的平均间隔将比协商的间隔大约少12.5%。
If bfd.DetectMult is equal to 1, the interval between transmitted BFD Control packets MUST be no more than 90% of the negotiated transmission interval and MUST be no less than 75% of the negotiated transmission interval. This is to ensure that, on the remote system, the calculated Detection Time does not pass prior to the receipt of the next BFD Control packet.
如果bfd.DetectMult等于1，则传输的bfd控制数据包之间的间隔不得超过协商传输间隔的90%，且不得小于协商传输间隔的75%。这是为了确保在远程系统上，在接收下一个BFD控制数据包之前，计算出的检测时间不会过去。
A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr is zero and the system is taking the Passive role.
如果BFD.RemoteDiscr为零且系统处于被动角色，则系统不得传输任何BFD控制数据包。
A system MUST NOT transmit any BFD Control packets if bfd.SessionType is MultipointTail.
如果BFD.SessionType为MultipointTail，则系统不得传输任何BFD控制数据包。
A system MUST NOT periodically transmit BFD Control packets if Demand mode is active on the remote system (bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and bfd.RemoteSessionState is Up), and a Poll Sequence is not being transmitted.
如果远程系统上的请求模式处于活动状态（BFD.RemoteDemandMode为1，BFD.SessionState为启动，BFD.RemoteSessionState为启动），并且未传输轮询序列，则系统不得定期发送BFD控制数据包。
A system MUST NOT periodically transmit BFD Control packets if bfd.RemoteMinRxInterval is zero.
如果BFD.RemoteMinRxInterval为零，则系统不得定期发送BFD控制数据包。
If bfd.SessionType is MultipointHead, the transmit interval MUST be set to bfd.DesiredMinTxInterval (this should happen automatically, as bfd.RemoteMinRxInterval will be zero).
如果bfd.SessionType为multipleinthead，则传输间隔必须设置为bfd.DesiredMinTxInterval（这应该自动发生，因为bfd.RemoteMinRxInterval将为零）。
If bfd.SessionType is not MultipointHead, the transmit interval MUST be recalculated whenever bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval changes, and is equal to the greater of those two values. See Sections 6.8.2 and 6.8.3 of [RFC5880] for details on transmit timers.
如果bfd.SessionType不是multipleinthead，则每当bfd.desiredMinrXinterval更改时，或每当bfd.RemoteMinRxInterval更改时，必须重新计算传输间隔，并且该间隔等于这两个值中的较大值。有关传输定时器的详细信息，请参见[RFC5880]第6.8.2节和第6.8.3节。
A system MUST NOT set the Demand (D) bit if bfd.SessionType is MultipointTail.
如果bfd.SessionType为MultipointTail，则系统不得设置需求（D）位。
A system MUST NOT set the Demand (D) bit if bfd.SessionType is PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and bfd.RemoteSessionState is Up.
如果bfd.SessionType为PointToPoint，则系统不得设置Demand（D）位，除非bfd.DemandMode为1、bfd.SessionState为Up且bfd.RemoteSessionState为Up。
If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control packet SHOULD be transmitted during the interval between periodic Control packet transmissions when the contents of that packet would differ from that in the previously transmitted packet (other than the Poll (P) and Final (F) bits) in order to more rapidly communicate a change in state.
如果bfd.SessionType是PointToPoint或multipointoinad，则应在周期性控制数据包传输之间的间隔期间传输bfd控制数据包，此时该数据包的内容将不同于先前传输的数据包中的内容（轮询（P）和最终（F）位除外）为了更快速地传达状态的变化。
The contents of transmitted BFD Control packets MUST be set as follows:
传输的BFD控制数据包的内容必须设置如下：
Version
版本
Set to the current version number (1).
设置为当前版本号（1）。
Diagnostic (Diag)
诊断（Diag）
Set to bfd.LocalDiag.
设置为bfd.LocalDiag。
State (Sta)
州（Sta）
Set to the value indicated by bfd.SessionState.
设置为bfd.SessionState指示的值。
Poll (P)
投票（P）
Set to 1 if the local system is sending a Poll Sequence or is a session of type MultipointHead soliciting the identities of the tails, or zero if not.
如果本地系统正在发送轮询序列，或者是请求尾部标识的MultiPineTad类型的会话，则设置为1，否则设置为零。
Final (F)
决赛（F）
Set to 1 if the local system is responding to a BFD Control packet received with the Poll (P) bit set, or zero if not.
如果本地系统响应以轮询（P）位设置接收的BFD控制数据包，则设置为1，否则设置为零。
Control Plane Independent (C)
控制平面独立（C）
Set to 1 if the local system's BFD implementation is independent of the control plane (it can continue to function through a disruption of the control plane).
如果本地系统的BFD实现独立于控制平面，则设置为1（它可以通过控制平面中断继续工作）。
Authentication Present (A)
认证存在（A）
Set to 1 if authentication is in use in this session (bfd.AuthType is nonzero), or zero if not.
如果此会话中正在使用身份验证，则设置为1（bfd.AuthType为非零），否则设置为零。
Demand (D)
需求（D）
Set to bfd.DemandMode if bfd.SessionState is Up and bfd.RemoteSessionState is Up. Set to 1 if bfd.SessionType is MultipointHead. Otherwise, it is set to zero.
如果bfd.SessionState已启动且bfd.RemoteSessionState已启动，则设置为bfd.DemandMode。如果bfd.SessionType为multipleinthead，则设置为1。否则，它将设置为零。
Multipoint (M)
多点（M）
Set to 1 if bfd.SessionType is MultipointHead. Otherwise, it is set to zero.
如果bfd.SessionType为multipleinthead，则设置为1。否则，它将设置为零。
Detect Mult
探测骡子
Set to bfd.DetectMult.
设置为bfd.DetectMult。
Length
长
Set to the appropriate length, based on the fixed header length (24) plus any Authentication Section.
根据固定标头长度（24）加上任何身份验证部分，设置为适当的长度。
My Discriminator
我的鉴别器
Set to bfd.LocalDiscr.
设置为bfd.LocalDiscr。
Your Discriminator
你的鉴别器
Set to bfd.RemoteDiscr.
设置为bfd.RemoteDiscr。
Desired Min TX Interval
所需最小发送间隔
Set to bfd.DesiredMinTxInterval.
设置为bfd.DesiredMinTxInterval。
Required Min RX Interval
所需最小接收间隔
Set to bfd.RequiredMinRxInterval.
设置为bfd.RequiredMinRxInterval。
Required Min Echo RX Interval
所需最小回波接收间隔
Set to zero if bfd.SessionType is MultipointHead or MultipointTail. Otherwise, set to the minimum required Echo packet receive interval for this session. If this field is set to zero, the local system is unwilling or unable to loop back BFD Echo packets to the remote system, and the remote system will not send Echo packets.
如果bfd.SessionType是MultipointHead或MultipointTail，则设置为零。否则，设置为该会话所需的最小回显数据包接收间隔。如果此字段设置为零，则本地系统不愿意或无法将BFD回送数据包回送至远程系统，远程系统将不发送回送数据包。
Authentication Section
认证部分
Included and set according to the rules in Section 6.7 of [RFC5880] if authentication is in use (bfd.AuthType is nonzero). Otherwise, this section is not present.
如果正在使用身份验证（bfd.AuthType为非零），则根据[RFC5880]第6.7节中的规则包括和设置。否则，本节不存在。
As a foreword, although congestion can occur because of a number of factors, it should be noted that high transmission rates are by themselves subject to creating congestion either along the path or at the tail end(s). As such, as stated in [RFC5883]:
作为前言，尽管由于许多因素可能会出现拥塞，但应注意的是，高传输速率本身会在路径沿线或末端造成拥塞。因此，如[RFC5883]所述：
it is required that the operator correctly provision the rates at which BFD is transmitted to avoid congestion (e.g link, I/O, CPU) and false failure detection.
要求操作员正确规定BFD的传输速率，以避免拥塞（例如链路、I/O、CPU）和错误故障检测。
Use of BFD in multipoint networks, as specified in this document, over multiple hops requires consideration of the mechanisms to react to network congestion. Requirements stated in Section 7 of the BFD base specification [RFC5880] equally apply to BFD in multipoint networks and are repeated here:
如本文件所述，在多点网络中使用BFD时，需要考虑对网络拥塞作出反应的机制。BFD基本规范[RFC5880]第7节中规定的要求同样适用于多点网络中的BFD，此处重复：
When BFD is used across multiple hops, a congestion control mechanism MUST be implemented, and when congestion is detected, the BFD implementation MUST reduce the amount of traffic it generates.
当跨多个跃点使用BFD时，必须实现拥塞控制机制，当检测到拥塞时，BFD实现必须减少其产生的流量。
The mechanism to control the load of BFD traffic MAY use BFD's configuration interface to control BFD state variable bfd.DesiredMinTxInterval. However, such a control loop does not form part of the BFD protocol itself, and its specification is thus outside the scope of this document.
控制BFD流量负载的机制可以使用BFD的配置接口来控制BFD状态变量BFD.DesiredMinTxInterval。然而，这种控制回路本身并不构成BFD协议的一部分，因此其规范不在本文件的范围内。
Additional considerations apply to BFD in multipoint networks, as specified in this document. Indeed, because a tail does not transmit any BFD Control packets to the head of the BFD session, such a head node has no BFD-based mechanism and thus is not aware of the state of the session at the tail. In the absence of any other mechanism, the head of the session could thus continue to send packets towards the tail(s) even though a link failure has happened. In such a scenario, when it is required for the head of the session to be aware of the state of the tail of the session, it is RECOMMENDED to implement the extension described in [RFC8563].
如本文件所述，其他注意事项适用于多点网络中的BFD。实际上，由于尾部不向BFD会话的头部发送任何BFD控制分组，因此这样的头部节点没有基于BFD的机制，因此不知道尾部会话的状态。在没有任何其他机制的情况下，会话的头部因此可以继续向尾部发送数据包，即使发生了链路故障。在这种情况下，当需要会话头知道会话尾的状态时，建议实现[RFC8563]中描述的扩展。
This document has no IANA actions.
本文档没有IANA操作。
The same security considerations as those described in [RFC5880] apply to this document. Additionally, implementations that create MultpointTail sessions dynamically upon receipt of multipoint BFD Control packets MUST implement protective measures to prevent an infinite number of MultipointTail sessions from being created. Below are some points to consider in such implementations.
[RFC5880]中所述的安全注意事项同样适用于本文件。此外，在收到多点BFD控制数据包后动态创建多点尾会话的实现必须实施保护措施，以防止创建无限多点尾会话。下面是在这些实现中要考虑的一些要点。
If a multipoint BFD Control packet did not arrive on a multicast path (e.g., on the expected interface, with the expected MPLS label, etc.), a MultipointTail session should not be created.
如果多点BFD控制数据包未到达多播路径（例如，在预期接口上，具有预期MPLS标签等），则不应创建多点尾部会话。
If redundant streams are expected for a given multicast stream, the implementations should not create more MultipointTail sessions than the number of streams. Additionally, when the number of MultipointTail sessions exceeds the number of expected streams, the implementation should generate an alarm to users to indicate the anomaly.
如果给定多播流需要冗余流，则实现不应创建超过流数量的多点尾会话。此外，当多点尾会话的数量超过预期流的数量时，实现应向用户生成警报以指示异常。
The implementation should have a reasonable upper bound on the number of MultipointHead sessions that can be created, with the upper bound potentially being computed based on the load these would generate.
实现应该对可以创建的多线程会话的数量有一个合理的上限，该上限可能是根据这些会话将产生的负载来计算的。
The implementation should have a reasonable upper bound on the number of MultipointTail sessions that can be created, with the upper bound potentially being computed based on the number of multicast streams that the system is expecting.
实现应该对可以创建的多点尾会话的数量有一个合理的上限，该上限可能基于系统期望的多播流的数量进行计算。
If authentication is in use, the head and all tails may be configured to have a common authentication key in order for the tails to validate multipoint BFD Control packets.
如果正在使用认证，则可以将头部和所有尾部配置为具有公共认证密钥，以便尾部验证多点BFD控制分组。
Shared keys in multipoint scenarios allow any tail to spoof the head from the viewpoint of any other tail. For this reason, using shared keys to authenticate BFD Control packets in multipoint scenarios is a significant security exposure unless all tails can be trusted not to spoof the head. Otherwise, asymmetric message authentication would be needed, e.g., protocols that use Timed Efficient Stream Loss-Tolerant Authentication (TESLA) as described in [RFC4082]. Applicability of the asymmetric message authentication to BFD for multipoint networks is outside the scope of this specification and is for further study.
多点场景中的共享密钥允许任何尾巴从任何其他尾巴的角度欺骗头部。因此，在多点场景中使用共享密钥对BFD控制数据包进行身份验证是一个重大的安全风险，除非可以信任所有尾部不会欺骗头部。否则，将需要非对称消息认证，例如，如[RFC4082]中所述，使用定时高效流丢失容忍认证（TESLA）的协议。非对称消息认证对多点网络BFD的适用性不在本规范的范围内，有待进一步研究。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <https://www.rfc-editor.org/info/rfc5880>.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 5880，DOI 10.17487/RFC5880，2010年6月<https://www.rfc-editor.org/info/rfc5880>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc7880>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[RFC8029]Kompella，K.，Swallow，G.，Pignataro，C.，Ed.，Kumar，N.，Aldrin，S.，和M.Chen，“检测多协议标签交换（MPLS）数据平面故障”，RFC 8029，DOI 10.17487/RFC8029，2017年3月<https://www.rfc-editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[MVPN-FAILOVER] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., "Multicast VPN fast upstream failover", Work in Progress, draft-ietf-bess-mvpn-fast-failover-05, February 2019.
[MVPN-FAILOVER]Morin，T.，Ed.，Kebler，R.，Ed.，和G.Mirsky，Ed.，“多播VPN快速上游故障切换”，正在进行的工作，草稿-ietf-bess-MVPN-fast-FAILOVER-052019年2月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, June 2005, <https://www.rfc-editor.org/info/rfc4082>.
[RFC4082]Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 4082，DOI 10.17487/RFC4082，2005年6月<https://www.rfc-editor.org/info/rfc4082>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, <https://www.rfc-editor.org/info/rfc5883>.
[RFC5883]Katz，D.和D.Ward，“多跳路径的双向转发检测（BFD）”，RFC 5883，DOI 10.17487/RFC5883，2010年6月<https://www.rfc-editor.org/info/rfc5883>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<https://www.rfc-editor.org/info/rfc6241>.
[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) Multipoint Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, <https://www.rfc-editor.org/info/rfc8563>.
[RFC8563]Katz，D.，Ward，D.，Pallagatti，S.，Ed.，和G.Mirsky，Ed.，“双向转发检测（BFD）多点活动尾”，RFC 8563，DOI 10.17487/RFC8563，2019年4月<https://www.rfc-editor.org/info/rfc8563>.
Acknowledgments
致谢
The authors would like to thank Nobo Akiya, Vengada Prasad Govindan, Jeff Haas, Wim Henderickx, Gregory Mirsky, and Mingui Zhang who have greatly contributed to this document.
作者要感谢Nobo Akiya、Vengada Prasad Govindan、Jeff Haas、Wim Henderickx、Gregory Mirsky和Mingui Zhang，他们对本文件做出了巨大贡献。
Contributors
贡献者
Rahul Aggarwal of Juniper Networks and George Swallow of Cisco Systems provided the initial idea for this specification and contributed to its development.
Juniper Networks的Rahul Aggarwal和Cisco Systems的George Swallow为该规范提供了最初的想法，并为其开发做出了贡献。
Authors' Addresses
作者地址
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, California 94089-1206 United States of America
Dave Katz Juniper Networks美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089-1206
Email: dkatz@juniper.net
Email: dkatz@juniper.net
Dave Ward Cisco Systems 170 West Tasman Dr. San Jose, California 95134 United States of America
Dave Ward Cisco Systems 170 West Tasman Dr.San Jose，California 95134美利坚合众国
Email: wardd@cisco.com
Email: wardd@cisco.com
Santosh Pallagatti (editor) VMware
桑托什·帕拉加蒂（编辑）VMware
Email: santosh.pallagatti@gmail.com
Email: santosh.pallagatti@gmail.com
Greg Mirsky (editor) ZTE Corp.
格雷格·米尔斯基（编辑）中兴通讯公司。
Email: gregimirsky@gmail.com
Email: gregimirsky@gmail.com