Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5880 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5880 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Bidirectional Forwarding Detection (BFD)
双向转发检测（BFD）
Abstract
摘要
This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols.
本文档描述了一种协议，该协议旨在检测两个转发引擎（包括接口、数据链路）之间的双向路径中的故障，并尽可能检测转发引擎本身，潜在的延迟非常低。它独立于媒体、数据协议和路由协议运行。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5880.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5880.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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. Conventions Used in This Document ..........................4
2. Design ..........................................................4
3. Protocol Overview ...............................................5
3.1. Addressing and Session Establishment .......................5
3.2. Operating Modes ............................................5
4. BFD Control Packet Format .......................................7
4.1. Generic BFD Control Packet Format ..........................7
4.2. Simple Password Authentication Section Format .............11
4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
Section Format ............................................11
4.4. Keyed SHA1 and Meticulous Keyed SHA1
Authentication Section Format .............................13
5. BFD Echo Packet Format .........................................14
6. Elements of Procedure ..........................................14
6.1. Overview ..................................................14
6.2. BFD State Machine .........................................16
6.3. Demultiplexing and the Discriminator Fields ...............17
6.4. The Echo Function and Asymmetry ...........................18
6.5. The Poll Sequence .........................................19
6.6. Demand Mode ...............................................19
6.7. Authentication ............................................21
6.7.1. Enabling and Disabling Authentication ..............21
6.7.2. Simple Password Authentication .....................22
6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication ..23
6.7.4. Keyed SHA1 and Meticulous Keyed SHA1
Authentication .....................................25
6.8. Functional Specifics ......................................27
6.8.1. State Variables ....................................27
6.8.2. Timer Negotiation ..................................30
6.8.3. Timer Manipulation .................................31
6.8.4. Calculating the Detection Time .....................32
6.8.5. Detecting Failures with the Echo Function ..........33
6.8.6. Reception of BFD Control Packets ...................33
6.8.7. Transmitting BFD Control Packets ...................36
6.8.8. Reception of BFD Echo Packets ......................39
6.8.9. Transmission of BFD Echo Packets ...................39
6.8.10. Min Rx Interval Change ............................40
6.8.11. Min Tx Interval Change ............................40
6.8.12. Detect Multiplier Change ..........................40
6.8.13. Enabling or Disabling The Echo Function ...........40
6.8.14. Enabling or Disabling Demand Mode .................40
6.8.15. Forwarding Plane Reset ............................41
6.8.16. Administrative Control ............................41
6.8.17. Concatenated Paths ................................41
6.8.18. Holding Down Sessions .............................42
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Design ..........................................................4
3. Protocol Overview ...............................................5
3.1. Addressing and Session Establishment .......................5
3.2. Operating Modes ............................................5
4. BFD Control Packet Format .......................................7
4.1. Generic BFD Control Packet Format ..........................7
4.2. Simple Password Authentication Section Format .............11
4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication
Section Format ............................................11
4.4. Keyed SHA1 and Meticulous Keyed SHA1
Authentication Section Format .............................13
5. BFD Echo Packet Format .........................................14
6. Elements of Procedure ..........................................14
6.1. Overview ..................................................14
6.2. BFD State Machine .........................................16
6.3. Demultiplexing and the Discriminator Fields ...............17
6.4. The Echo Function and Asymmetry ...........................18
6.5. The Poll Sequence .........................................19
6.6. Demand Mode ...............................................19
6.7. Authentication ............................................21
6.7.1. Enabling and Disabling Authentication ..............21
6.7.2. Simple Password Authentication .....................22
6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication ..23
6.7.4. Keyed SHA1 and Meticulous Keyed SHA1
Authentication .....................................25
6.8. Functional Specifics ......................................27
6.8.1. State Variables ....................................27
6.8.2. Timer Negotiation ..................................30
6.8.3. Timer Manipulation .................................31
6.8.4. Calculating the Detection Time .....................32
6.8.5. Detecting Failures with the Echo Function ..........33
6.8.6. Reception of BFD Control Packets ...................33
6.8.7. Transmitting BFD Control Packets ...................36
6.8.8. Reception of BFD Echo Packets ......................39
6.8.9. Transmission of BFD Echo Packets ...................39
6.8.10. Min Rx Interval Change ............................40
6.8.11. Min Tx Interval Change ............................40
6.8.12. Detect Multiplier Change ..........................40
6.8.13. Enabling or Disabling The Echo Function ...........40
6.8.14. Enabling or Disabling Demand Mode .................40
6.8.15. Forwarding Plane Reset ............................41
6.8.16. Administrative Control ............................41
6.8.17. Concatenated Paths ................................41
6.8.18. Holding Down Sessions .............................42
7. Operational Considerations .....................................43
8. IANA Considerations ............................................44
9. Security Considerations ........................................45
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A. Backward Compatibility (Non-Normative) ................48
Appendix B. Contributors ..........................................48
Appendix C. Acknowledgments .......................................49
7. Operational Considerations .....................................43
8. IANA Considerations ............................................44
9. Security Considerations ........................................45
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A. Backward Compatibility (Non-Normative) ................48
Appendix B. Contributors ..........................................48
Appendix C. Acknowledgments .......................................49
An increasingly important feature of networking equipment is the rapid detection of communication failures between adjacent systems, in order to more quickly establish alternative paths. Detection can come fairly quickly in certain circumstances when data link hardware comes into play (such as Synchronous Optical Network (SONET) alarms). However, there are media that do not provide this kind of signaling (such as Ethernet), and some media may not detect certain kinds of failures in the path, for example, failing interfaces or forwarding engine components.
网络设备的一个日益重要的特征是快速检测相邻系统之间的通信故障，以便更快地建立替代路径。在某些情况下，当数据链路硬件发挥作用时（如同步光网络（SONET）报警），检测可以相当快地进行。但是，有些媒体不提供此类信令（如以太网），有些媒体可能检测不到路径中的某些故障，例如接口故障或转发引擎组件故障。
Networks use relatively slow "Hello" mechanisms, usually in routing protocols, to detect failures when there is no hardware signaling to help out. The time to detect failures ("Detection Times") available in the existing protocols are no better than a second, which is far too long for some applications and represents a great deal of lost data at gigabit rates. Furthermore, routing protocol Hellos are of no help when those routing protocols are not in use, and the semantics of detection are subtly different -- they detect a failure in the path between the two routing protocol engines.
网络使用相对较慢的“Hello”机制，通常在路由协议中，在没有硬件信令帮助的情况下检测故障。现有协议中可用的故障检测时间（“检测时间”）不超过一秒，这对于某些应用程序来说太长，并且以千兆速率表示大量数据丢失。此外，当这些路由协议未被使用时，路由协议hello也没有任何帮助，检测的语义也有细微的不同——它们检测两个路由协议引擎之间的路径中的故障。
The goal of Bidirectional Forwarding Detection (BFD) is to provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and, to the extent possible, the forwarding engines themselves.
双向转发检测（BFD）的目标是提供低开销、短时间的相邻转发引擎之间路径故障检测，包括接口、数据链路，以及尽可能的转发引擎本身。
An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of Detection Times and overhead, to avoid a proliferation of different methods.
另一个目标是提供一种单一的机制，该机制可用于任何媒体、任何协议层上的活动性检测，具有广泛的检测时间和开销，以避免不同方法的扩散。
This document specifies the details of the base protocol. The use of some mechanisms are application dependent and are specified in a separate series of application documents. These issues are so noted.
本文件规定了基本协议的详细信息。某些机制的使用取决于应用程序，并在一系列单独的应用程序文档中指定。这些问题都是值得注意的。
Note that many of the exact mechanisms are implementation dependent and will not affect interoperability, and are thus outside the scope of this specification. Those issues are so noted.
请注意，许多确切的机制依赖于实现，不会影响互操作性，因此不在本规范的范围内。这些问题是如此值得注意。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
BFD is designed to detect failures in communication with a forwarding plane next hop. It is intended to be implemented in some component of the forwarding engine of a system, in cases where the forwarding and control engines are separated. This not only binds the protocol more to the forwarding plane, but decouples the protocol from the fate of the routing protocol engine, making it useful in concert with various "graceful restart" mechanisms for those protocols. BFD may also be implemented in the control engine, though doing so may preclude the detection of some kinds of failures.
BFD设计用于检测下一跳与转发平面的通信故障。它旨在在转发引擎和控制引擎分离的情况下，在系统的转发引擎的某些组件中实现。这不仅将协议更多地绑定到转发平面，而且将协议与路由协议引擎的命运分离，使其与这些协议的各种“优雅重启”机制协同使用。BFD也可以在控制引擎中实现，尽管这样做可能会排除某些类型故障的检测。
BFD operates on top of any data protocol (network layer, link layer, tunnels, etc.) being forwarded between two systems. It is always run in a unicast, point-to-point mode. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. BFD may be running at multiple layers in a system. The context of the operation of any particular BFD session is bound to its encapsulation.
BFD在两个系统之间转发的任何数据协议（网络层、链路层、隧道等）之上运行。它始终以单播、点对点模式运行。BFD数据包作为适用于介质和网络的任何封装协议的有效载荷携带。BFD可以在系统中的多个层上运行。任何特定BFD会话的操作上下文都绑定到其封装。
BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS Label Switched Paths (LSPs), multihop routed paths, and unidirectional links (so long as there is some return path, of course). Multiple BFD sessions can be established between the same pair of systems when multiple paths between them are present in at least one direction, even if a lesser number of paths are available in the other direction (multiple parallel unidirectional links or MPLS LSPs, for example).
BFD可以在系统之间的任何类型的路径上提供故障检测，包括直接物理链路、虚拟电路、隧道、MPLS标签交换路径（LSP）、多跳路由路径和单向链路（当然，只要有一些返回路径）。当同一对系统之间在至少一个方向上存在多条路径时，即使在另一个方向上可用的路径数量较少（例如，多个并行单向链路或MPLS lsp），也可以在同一对系统之间建立多个BFD会话。
The BFD state machine implements a three-way handshake, both when establishing a BFD session and when tearing it down for any reason, to ensure that both systems are aware of the state change.
BFD状态机在建立BFD会话和出于任何原因中断BFD会话时实现三方握手，以确保两个系统都知道状态更改。
BFD can be abstracted as a simple service. The service primitives provided by BFD are to create, destroy, and modify a session, given the destination address and other parameters. BFD in return provides a signal to its clients indicating when the BFD session goes up or down.
BFD可以抽象为一个简单的服务。BFD提供的服务原语用于在给定目标地址和其他参数的情况下创建、销毁和修改会话。作为回报，BFD向其客户端提供一个信号，指示BFD会话何时启动或关闭。
BFD is a simple Hello protocol that, in many respects, is similar to the detection components of well-known routing protocols. A pair of systems transmit BFD packets periodically over each path between the two systems, and if a system stops receiving BFD packets for long enough, some component in that particular bidirectional path to the neighboring system is assumed to have failed. Under some conditions, systems may negotiate not to send periodic BFD packets in order to reduce overhead.
BFD是一个简单的Hello协议，在许多方面类似于著名路由协议的检测组件。一对系统在两个系统之间的每条路径上周期性地发送BFD分组，如果系统停止接收BFD分组足够长的时间，则假定到相邻系统的特定双向路径中的某个组件发生故障。在某些情况下，系统可能协商不发送周期性BFD数据包以减少开销。
A path is only declared to be operational when two-way communication has been established between systems, though this does not preclude the use of unidirectional links.
只有在系统之间建立了双向通信时，路径才被声明为可操作的，尽管这并不排除使用单向链路。
A separate BFD session is created for each communications path and data protocol in use between two systems.
为两个系统之间使用的每个通信路径和数据协议创建单独的BFD会话。
Each system estimates how quickly it can send and receive BFD packets in order to come to an agreement with its neighbor about how rapidly detection of failure will take place. These estimates can be modified in real time in order to adapt to unusual situations. This design also allows for fast systems on a shared medium with a slow system to be able to more rapidly detect failures between the fast systems while allowing the slow system to participate to the best of its ability.
每个系统都会估计其发送和接收BFD数据包的速度，以便与其邻居就故障检测的速度达成一致。这些估计值可以实时修改，以适应异常情况。这种设计还允许共享介质上的快速系统与慢速系统能够更快速地检测快速系统之间的故障，同时允许慢速系统尽其最大能力参与。
A BFD session is established based on the needs of the application that will be making use of it. It is up to the application to determine the need for BFD, and the addresses to use -- there is no discovery mechanism in BFD. For example, an OSPF [OSPF] implementation may request a BFD session to be established to a neighbor discovered using the OSPF Hello protocol.
BFD会话是根据将要使用它的应用程序的需求建立的。由应用程序决定是否需要BFD以及要使用的地址——BFD中没有发现机制。例如，OSPF[OSPF]实现可以请求向使用OSPF Hello协议发现的邻居建立BFD会话。
BFD has two operating modes that may be selected, as well as an additional function that can be used in combination with the two modes.
BFD有两种可选择的操作模式，以及一个可与两种模式结合使用的附加功能。
The primary mode is known as Asynchronous mode. In this mode, the systems periodically send BFD Control packets to one another, and if a number of those packets in a row are not received by the other system, the session is declared to be down.
主要模式称为异步模式。在此模式下，系统周期性地向彼此发送BFD控制数据包，并且如果一行中的许多数据包没有被另一个系统接收，则会话被声明为关闭。
The second mode is known as Demand mode. In this mode, it is assumed that a system has an independent way of verifying that it has connectivity to the other system. Once a BFD session is established, such a system may ask the other system to stop sending BFD Control packets, except when the system feels the need to verify connectivity explicitly, in which case a short sequence of BFD Control packets is exchanged, and then the far system quiesces. Demand mode may operate independently in each direction, or simultaneously.
第二种模式称为需求模式。在这种模式下，假设一个系统有一种独立的方式来验证它是否与另一个系统连接。一旦建立BFD会话，这样的系统可以要求另一个系统停止发送BFD控制分组，除非系统感觉需要明确地验证连接，在这种情况下，交换短序列的BFD控制分组，然后远端系统静止。需求模式可以在每个方向上独立运行，也可以同时运行。
An adjunct to both modes is the Echo function. When the Echo function is active, a stream of BFD Echo packets is transmitted in such a way as to have the other system loop them back through its forwarding path. If a number of packets of the echoed data stream are not received, the session is declared to be down. The Echo function may be used with either Asynchronous or Demand mode. Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode).
这两种模式的附属功能是回声功能。当Echo功能激活时，BFD Echo数据包流以使另一个系统通过其转发路径将其环回的方式传输。如果未接收到回送数据流的多个分组，则会话被声明为关闭。回声功能可用于异步或按需模式。由于Echo功能正在处理检测任务，控制数据包的周期传输速率可能会降低（在异步模式下）或完全消除（在请求模式下）。
Pure Asynchronous mode is advantageous in that it requires half as many packets to achieve a particular Detection Time as does the Echo function. It is also used when the Echo function cannot be supported for some reason.
纯异步模式的优势在于，它需要一半的数据包来实现特定的检测时间，就像回声功能一样。当由于某种原因无法支持回声功能时，也可使用该功能。
The Echo function has the advantage of truly testing only the forwarding path on the remote system. This may reduce round-trip jitter and thus allow more aggressive Detection Times, as well as potentially detecting some classes of failure that might not otherwise be detected.
Echo功能的优点是只真正测试远程系统上的转发路径。这可能会减少往返抖动，从而允许更积极的检测时间，以及可能检测到一些可能无法检测到的故障类别。
The Echo function may be enabled individually in each direction. It is enabled in a particular direction only when the system that loops the Echo packets back signals that it will allow it, and when the system that sends the Echo packets decides it wishes to.
回波功能可在每个方向上单独启用。只有当回送回回显数据包的系统发出允许回显的信号，并且发送回显数据包的系统决定允许回显时，才在特定方向启用回显。
Demand mode is useful in situations where the overhead of a periodic protocol might prove onerous, such as a system with a very large number of BFD sessions. It is also useful when the Echo function is being used symmetrically. Demand mode has the disadvantage that Detection Times are essentially driven by the heuristics of the system implementation and are not known to the BFD protocol. Demand
在周期性协议的开销可能非常繁重的情况下，需求模式非常有用，例如具有大量BFD会话的系统。当对称使用回声功能时，它也很有用。需求模式的缺点是检测时间基本上由系统实现的启发式算法驱动，BFD协议不知道。需要
mode may not be used when the path round-trip time is greater than the desired Detection Time, or the protocol will fail to work properly. See section 6.6 for more details.
当路径往返时间大于所需检测时间时，可能不使用模式，否则协议将无法正常工作。详见第6.6节。
BFD Control packets are sent in an encapsulation appropriate to the environment. The specific encapsulation is outside of the scope of this specification. See the appropriate application document for encapsulation details.
BFD控制数据包以适合环境的封装方式发送。具体封装不在本规范的范围内。有关封装的详细信息，请参阅相应的应用程序文档。
The BFD Control packet has a Mandatory Section and an optional Authentication Section. The format of the Authentication Section, if present, is dependent on the type of authentication in use.
BFD控制数据包有一个强制部分和一个可选的身份验证部分。身份验证部分的格式（如果存在）取决于使用的身份验证类型。
The Mandatory Section of a BFD Control packet has the following format:
BFD控制数据包的强制部分具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An optional Authentication Section MAY be present:
可能存在可选的身份验证部分：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Authentication Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Authentication Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (Vers)
版本（Vers）
The version number of the protocol. This document defines protocol version 1.
协议的版本号。本文件定义了协议版本1。
Diagnostic (Diag)
诊断（Diag）
A diagnostic code specifying the local system's reason for the last change in session state. Values are:
一种诊断代码，指定上次会话状态更改的本地系统原因。价值观是：
0 -- No Diagnostic 1 -- Control Detection Time Expired 2 -- Echo Function Failed 3 -- Neighbor Signaled Session Down 4 -- Forwarding Plane Reset 5 -- Path Down 6 -- Concatenated Path Down 7 -- Administratively Down 8 -- Reverse Concatenated Path Down 9-31 -- Reserved for future use
0--无诊断1--控制检测时间已过期2--回显功能失败3--邻居发出信号的会话中断4--转发平面重置5--路径中断6--级联路径中断7--管理中断8--反向级联路径中断9-31--保留供将来使用
This field allows remote systems to determine the reason that the previous session failed, for example.
例如，此字段允许远程系统确定上一个会话失败的原因。
State (Sta)
州（Sta）
The current BFD session state as seen by the transmitting system. Values are:
传输系统看到的当前BFD会话状态。价值观是：
0 -- AdminDown 1 -- Down 2 -- Init 3 -- Up
0—AdminDown 1—Down 2—Init 3—Up
Poll (P)
投票（P）
If set, the transmitting system is requesting verification of connectivity, or of a parameter change, and is expecting a packet with the Final (F) bit in reply. If clear, the transmitting system is not requesting verification.
如果设置，则传输系统请求验证连接性或参数更改，并期望得到带有最终（F）位的数据包作为应答。如果清除，则传输系统不请求验证。
Final (F)
决赛（F）
If set, the transmitting system is responding to a received BFD Control packet that had the Poll (P) bit set. If clear, the transmitting system is not responding to a Poll.
如果设置，则发送系统响应已设置轮询（P）位的接收BFD控制包。如果清除，则传输系统不响应轮询。
Control Plane Independent (C)
控制平面独立（C）
If set, the transmitting system's BFD implementation does not share fate with its control plane (in other words, BFD is implemented in the forwarding plane and can continue to function through disruptions in the control plane). If clear, the transmitting system's BFD implementation shares fate with its control plane.
如果设置，传输系统的BFD实现不会与其控制平面共享命运（换句话说，BFD在转发平面中实现，并且可以通过控制平面中的中断继续工作）。如果清除，传输系统的BFD实现与其控制平面共享命运。
The use of this bit is application dependent and is outside the scope of this specification. See specific application specifications for details.
此位的使用取决于应用程序，不在本规范的范围内。有关详细信息，请参阅具体的应用规范。
Authentication Present (A)
认证存在（A）
If set, the Authentication Section is present and the session is to be authenticated (see section 6.7 for details).
如果设置了，则验证部分存在，会话将被验证（有关详细信息，请参阅第6.7节）。
Demand (D)
需求（D）
If set, Demand mode is active in the transmitting system (the system wishes to operate in Demand mode, knows that the session is Up in both directions, and is directing the remote system to cease the periodic transmission of BFD Control packets). If clear, Demand mode is not active in the transmitting system.
如果设置，请求模式在传输系统中处于活动状态（系统希望在请求模式下运行，知道会话在两个方向上都已启动，并指示远程系统停止BFD控制数据包的定期传输）。如果清除，则传输系统中的需求模式未激活。
Multipoint (M)
多点（M）
This bit is reserved for future point-to-multipoint extensions to BFD. It MUST be zero on both transmit and receipt.
此位保留用于BFD的未来点对多点扩展。传输和接收时都必须为零。
Detect Mult
探测骡子
Detection time multiplier. The negotiated transmit interval, multiplied by this value, provides the Detection Time for the receiving system in Asynchronous mode.
检测时间乘数。协商发送间隔乘以该值，为异步模式下的接收系统提供检测时间。
Length
长
Length of the BFD Control packet, in bytes.
BFD控制数据包的长度，以字节为单位。
My Discriminator
我的鉴别器
A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems.
传输系统生成的唯一非零鉴别器值，用于在同一对系统之间解复用多个BFD会话。
Your Discriminator
你的鉴别器
The discriminator received from the corresponding remote system. This field reflects back the received value of My Discriminator, or is zero if that value is unknown.
从相应的远程系统接收的鉴别器。此字段反映我的鉴别器的接收值，如果该值未知，则为零。
Desired Min TX Interval
所需最小发送间隔
This is the minimum interval, in microseconds, that the local system would like to use when transmitting BFD Control packets, less any jitter applied (see section 6.8.2). The value zero is reserved.
这是本地系统在传输BFD控制数据包时希望使用的最小间隔（微秒），减去应用的任何抖动（见第6.8.2节）。保留值0。
Required Min RX Interval
所需最小接收间隔
This is the minimum interval, in microseconds, between received BFD Control packets that this system is capable of supporting, less any jitter applied by the sender (see section 6.8.2). If this value is zero, the transmitting system does not want the remote system to send any periodic BFD Control packets.
这是该系统能够支持的接收BFD控制数据包之间的最小间隔（以微秒为单位），减去发送方施加的任何抖动（见第6.8.2节）。如果该值为零，则传输系统不希望远程系统发送任何定期BFD控制数据包。
Required Min Echo RX Interval
所需最小回波接收间隔
This is the minimum interval, in microseconds, between received BFD Echo packets that this system is capable of supporting, less any jitter applied by the sender (see section 6.8.9). If this value is zero, the transmitting system does not support the receipt of BFD Echo packets.
这是该系统能够支持的接收BFD回波数据包之间的最小间隔（以微秒为单位），减去发送方施加的任何抖动（见第6.8.9节）。如果该值为零，则传输系统不支持接收BFD回波数据包。
Auth Type
验证类型
The authentication type in use, if the Authentication Present (A) bit is set.
如果设置了身份验证存在（A）位，则使用的身份验证类型。
0 - Reserved 1 - Simple Password 2 - Keyed MD5 3 - Meticulous Keyed MD5 4 - Keyed SHA1 5 - Meticulous Keyed SHA1 6-255 - Reserved for future use
0-保留1-简单密码2-键入MD5 3-精心键入MD5 4-精心键入SHA1 5-精心键入SHA1 6-255-保留供将来使用
Auth Len
授权书
The length, in bytes, of the authentication section, including the Auth Type and Auth Len fields.
身份验证部分的长度（字节），包括身份验证类型和身份验证长度字段。
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains 1 (Simple Password), the Authentication Section has the following format:
如果在标头中设置了身份验证存在（A）位，并且身份验证类型字段包含1（简单密码），则身份验证部分的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Password... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Password... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
验证类型
The Authentication Type, which in this case is 1 (Simple Password).
身份验证类型，在本例中为1（简单密码）。
Auth Len
授权书
The length of the Authentication Section, in bytes. For Simple Password authentication, the length is equal to the password length plus three.
身份验证部分的长度，以字节为单位。对于简单密码身份验证，长度等于密码长度加三。
Auth Key ID
身份验证密钥ID
The authentication key ID in use for this packet. This allows multiple keys to be active simultaneously.
用于此数据包的身份验证密钥ID。这允许同时激活多个键。
Password
暗语
The simple password in use on this session. The password is a binary string, and MUST be from 1 to 16 bytes in length. The password MUST be encoded and configured according to section 6.7.2.
此会话中使用的简单密码。密码是二进制字符串，长度必须为1到16字节。必须根据第6.7.2节对密码进行编码和配置。
The use of MD5-based authentication is strongly discouraged. However, it is documented here for compatibility with existing implementations.
强烈反对使用基于MD5的身份验证。然而，为了与现有的实现兼容，这里对其进行了说明。
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous Keyed MD5), the Authentication Section has the following format:
如果在报头中设置了身份验证存在（A）位，并且身份验证类型字段包含2（键控MD5）或3（键控MD5），则身份验证部分的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Digest... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Digest... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
验证类型
The Authentication Type, which in this case is 2 (Keyed MD5) or 3 (Meticulous Keyed MD5).
身份验证类型，在本例中为2（键控MD5）或3（键控MD5）。
Auth Len
授权书
The length of the Authentication Section, in bytes. For Keyed MD5 and Meticulous Keyed MD5 authentication, the length is 24.
身份验证部分的长度，以字节为单位。对于键控MD5和精细键控MD5身份验证，长度为24。
Auth Key ID
身份验证密钥ID
The authentication key ID in use for this packet. This allows multiple keys to be active simultaneously.
用于此数据包的身份验证密钥ID。这允许同时激活多个键。
Reserved
含蓄的
This byte MUST be set to zero on transmit, and ignored on receipt.
此字节在传输时必须设置为零，在接收时忽略。
Sequence Number
序列号
The sequence number for this packet. For Keyed MD5 Authentication, this value is incremented occasionally. For Meticulous Keyed MD5 Authentication, this value is incremented for each successive packet transmitted for a session. This provides protection against replay attacks.
此数据包的序列号。对于键控MD5身份验证，此值偶尔递增。对于精心设置密钥的MD5身份验证，对于为会话传输的每个连续数据包，该值都会增加。这可以防止重播攻击。
Auth Key/Digest
认证密钥/摘要
This field carries the 16-byte MD5 digest for the packet. When the digest is calculated, the shared MD5 key is stored in this field, padded to 16 bytes with trailing zero bytes if needed. The shared key MUST be encoded and configured to section 6.7.3.
此字段包含数据包的16字节MD5摘要。当计算摘要时，共享MD5密钥存储在该字段中，如果需要，用尾随零字节填充到16字节。共享密钥必须按照第6.7.3节进行编码和配置。
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1), the Authentication Section has the following format:
如果在报头中设置了认证存在（A）位，并且认证类型字段包含4（键控SHA1）或5（键控SHA1），则认证部分具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Hash... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Key/Hash... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
验证类型
The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1).
身份验证类型，在本例中为4（键控SHA1）或5（键控SHA1）。
Auth Len
授权书
The length of the Authentication Section, in bytes. For Keyed SHA1 and Meticulous Keyed SHA1 authentication, the length is 28.
身份验证部分的长度，以字节为单位。对于键控SHA1和精细键控SHA1身份验证，长度为28。
Auth Key ID
身份验证密钥ID
The authentication key ID in use for this packet. This allows multiple keys to be active simultaneously.
用于此数据包的身份验证密钥ID。这允许同时激活多个键。
Reserved
含蓄的
This byte MUST be set to zero on transmit and ignored on receipt.
此字节在传输时必须设置为零，在接收时必须忽略。
Sequence Number
序列号
The sequence number for this packet. For Keyed SHA1 Authentication, this value is incremented occasionally. For Meticulous Keyed SHA1 Authentication, this value is incremented for each successive packet transmitted for a session. This provides protection against replay attacks.
此数据包的序列号。对于键控SHA1身份验证，此值偶尔递增。对于精心设置密钥的SHA1身份验证，对于为会话传输的每个连续数据包，该值都会增加。这可以防止重播攻击。
Auth Key/Hash
验证密钥/哈希
This field carries the 20-byte SHA1 hash for the packet. When the hash is calculated, the shared SHA1 key is stored in this field, padded to a length of 20 bytes with trailing zero bytes if needed. The shared key MUST be encoded and configured to section 6.7.4.
此字段包含数据包的20字节SHA1散列。计算散列时，共享SHA1密钥存储在此字段中，如果需要，将其填充为20个字节的长度，并使用尾随的零字节。共享密钥必须按照第6.7.4节进行编码和配置。
BFD Echo packets are sent in an encapsulation appropriate to the environment. See the appropriate application documents for the specifics of particular environments.
BFD回波数据包以适合环境的封装方式发送。有关特定环境的详细信息，请参阅相应的应用程序文档。
The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received packet to the correct BFD session after it is looped back to the sender. The contents are otherwise outside the scope of this specification.
BFD回送数据包的有效载荷是本地问题，因为只有发送系统处理过内容。唯一的要求是包含足够的信息，以便在将接收到的数据包环回发送方后将其解复用到正确的BFD会话。内容不在本规范范围内。
Some form of authentication SHOULD be included, since Echo packets may be spoofed.
应该包括某种形式的身份验证，因为可能会伪造回显数据包。
This section discusses the normative requirements of the protocol in order to achieve interoperability. It is important for implementors to enforce only the requirements specified in this section, as misguided pedantry has been proven by experience to affect interoperability adversely.
本节讨论协议的规范性要求，以实现互操作性。对于实施者来说，重要的是只执行本节中指定的要求，因为经验证明，误导性的迂腐行为会对互操作性产生负面影响。
Remember that all references of the form "bfd.Xx" refer to internal state variables (defined in section 6.8.1), whereas all references to "the Xxx field" refer to fields in the protocol packets themselves (defined in section 4).
请记住，“bfd.Xx”形式的所有引用均指内部状态变量（定义见第6.8.1节），而“Xxx字段”的所有引用均指协议数据包中的字段（定义见第4节）。
A system may take either an Active role or a Passive role in session initialization. A system taking the Active role MUST send BFD Control packets for a particular session, regardless of whether it has received any BFD packets for that session. A system taking the Passive role MUST NOT begin sending BFD packets for a particular session until it has received a BFD packet for that session, and thus has learned the remote system's discriminator value. At least one system MUST take the Active role (possibly both). The role that a system takes is specific to the application of BFD, and is outside the scope of this specification.
系统在会话初始化中可以扮演主动角色，也可以扮演被动角色。担任活动角色的系统必须为特定会话发送BFD控制数据包，无论它是否已收到该会话的任何BFD数据包。担任被动角色的系统必须在收到特定会话的BFD数据包并因此了解到远程系统的鉴别器值之前，才能开始为特定会话发送BFD数据包。必须至少有一个系统担任主动角色（可能同时担任这两个角色）。系统所扮演的角色特定于BFD的应用，不在本规范的范围内。
A session begins with the periodic, slow transmission of BFD Control packets. When bidirectional communication is achieved, the BFD session becomes Up.
会话以周期性、缓慢地传输BFD控制数据包开始。当实现双向通信时，BFD会话将启动。
Once the BFD session is Up, a system can choose to start the Echo function if it desires and the other system signals that it will allow it. The rate of transmission of Control packets is typically kept low when the Echo function is active.
一旦BFD会话启动，系统可以根据需要选择启动回显功能，其他系统发出信号表示允许。当回声功能激活时，控制数据包的传输速率通常保持较低。
If the Echo function is not active, the transmission rate of Control packets may be increased to a level necessary to achieve the Detection Time requirements for the session.
如果回声功能未激活，则控制分组的传输速率可增加到达到会话的检测时间要求所需的水平。
Once the session is Up, a system may signal that it has entered Demand mode, and the transmission of BFD Control packets by the remote system ceases. Other means of implying connectivity are used to keep the session alive. If either system wishes to verify bidirectional connectivity, it can initiate a short exchange of BFD Control packets (a "Poll Sequence"; see section 6.5) to do so.
一旦会话启动，系统可能会发出信号，表示它已进入请求模式，远程系统停止传输BFD控制数据包。其他暗示连接的方法用于保持会话活动。如果任何一个系统希望验证双向连接，它可以启动BFD控制数据包的短交换（“轮询序列”；见第6.5节）。
If Demand mode is not active, and no Control packets are received in the calculated Detection Time (see section 6.8.4), the session is declared Down. This is signaled to the remote end via the State (Sta) field in outgoing packets.
如果请求模式未激活，并且在计算的检测时间内未收到任何控制数据包（参见第6.8.4节），则会话被宣布为关闭。这通过传出数据包中的状态（Sta）字段向远程端发送信号。
If sufficient Echo packets are lost, the session is declared Down in the same manner. See section 6.8.5.
如果丢失了足够多的回显数据包，会话将以相同的方式声明为关闭。见第6.8.5节。
If Demand mode is active and no appropriate Control packets are received in response to a Poll Sequence, the session is declared Down in the same manner. See section 6.6.
如果请求模式处于活动状态，并且没有收到响应轮询序列的适当控制数据包，则会话将以相同的方式声明为关闭。见第6.6节。
If the session goes Down, the transmission of Echo packets (if any) ceases, and the transmission of Control packets goes back to the slow rate.
如果会话中断，则回波数据包（如果有）的传输停止，控制数据包的传输返回低速率。
Once a session has been declared Down, it cannot come back up until the remote end first signals that it is down (by leaving the Up state), thus implementing a three-way handshake.
一旦会话被声明为关闭，它就无法恢复，直到远程端首先发出关闭信号（通过离开“打开”状态），从而实现三方握手。
A session MAY be kept administratively down by entering the AdminDown state and sending an explanatory diagnostic code in the Diagnostic field.
通过进入AdminDown状态并在diagnostic（诊断）字段中发送解释性诊断代码，可以管理性关闭会话。
The BFD state machine is quite straightforward. There are three states through which a session normally proceeds: two for establishing a session (Init and Up) and one for tearing down a session (Down). This allows a three-way handshake for both session establishment and session teardown (assuring that both systems are aware of all session state changes). A fourth state (AdminDown) exists so that a session can be administratively put down indefinitely.
BFD状态机非常简单。会话通常有三种状态进行：两种状态用于建立会话（Init和Up），另一种状态用于中断会话（down）。这允许会话建立和会话断开的三方握手（确保两个系统都知道所有会话状态更改）。第四种状态（AdminDown）的存在使得会话可以无限期地被管理性放下。
Each system communicates its session state in the State (Sta) field in the BFD Control packet, and that received state, in combination with the local session state, drives the state machine.
每个系统在BFD控制数据包的状态（Sta）字段中通信其会话状态，并且接收到的状态与本地会话状态一起驱动状态机。
Down state means that the session is down (or has just been created). A session remains in Down state until the remote system indicates that it agrees that the session is down by sending a BFD Control packet with the State field set to anything other than Up. If that packet signals Down state, the session advances to Init state; if that packet signals Init state, the session advances to Up state. Semantically, Down state indicates that the forwarding path is unavailable, and that appropriate actions should be taken by the applications monitoring the state of the BFD session. A system MAY hold a session in Down state indefinitely (by simply refusing to advance the session state). This may be done for operational or administrative reasons, among others.
Down状态表示会话已关闭（或刚刚创建）。会话保持在关闭状态，直到远程系统通过发送一个BFD控制数据包并将状态字段设置为除向上以外的任何值来表示它同意会话关闭。如果该分组发出下行状态信号，则会话进入初始状态；如果该数据包发出Init状态信号，会话将进入Up状态。从语义上讲，Down state表示转发路径不可用，并且监控BFD会话状态的应用程序应该采取适当的操作。系统可以无限期地将会话保持在关闭状态（通过简单地拒绝推进会话状态）。除其他原因外，这可能是出于运营或管理原因。
Init state means that the remote system is communicating, and the local system desires to bring the session up, but the remote system does not yet realize it. A session will remain in Init state until either a BFD Control Packet is received that is signaling Init or Up state (in which case the session advances to Up state) or the Detection Time expires, meaning that communication with the remote system has been lost (in which case the session advances to Down state).
Init状态表示远程系统正在通信，本地系统希望启动会话，但远程系统尚未实现。会话将保持初始状态，直到接收到发送初始或向上状态信号的BFD控制包（在这种情况下，会话进入向上状态）或检测时间到期，这意味着与远程系统的通信已丢失（在这种情况下，会话进入向下状态）。
Up state means that the BFD session has successfully been established, and implies that connectivity between the systems is working. The session will remain in the Up state until either connectivity fails or the session is taken down administratively. If either the remote system signals Down state or the Detection Time expires, the session advances to Down state.
Up状态表示BFD会话已成功建立，并表示系统之间的连接正在工作。会话将保持在启动状态，直到连接失败或会话被管理性关闭。如果远程系统发出关闭状态信号或检测时间到期，会话将进入关闭状态。
AdminDown state means that the session is being held administratively down. This causes the remote system to enter Down state, and remain there until the local system exits AdminDown state. AdminDown state has no semantic implications for the availability of the forwarding path.
AdminDown状态表示会话正在以管理方式关闭。这会导致远程系统进入关闭状态，并一直保持该状态，直到本地系统退出AdminDown状态。AdminDown状态对转发路径的可用性没有语义含义。
The following diagram provides an overview of the state machine. Transitions involving AdminDown state are deleted for clarity (but are fully specified in sections 6.8.6 and 6.8.16). 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.
下图提供了状态机的概述。为清楚起见，删除了涉及AdminDown状态的转换（但在第6.8.6节和第6.8.16节中有详细说明）。每个arc上的符号表示远程系统的状态（在BFD控制数据包的状态字段中接收）或指示检测计时器的过期。
+--+
| | UP, ADMIN DOWN, TIMER
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |TIMER TIMER| |
V | | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
+--+
| | UP, ADMIN DOWN, TIMER
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |TIMER TIMER| |
V | | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
Since multiple BFD sessions may be running between two systems, there needs to be a mechanism for demultiplexing received BFD packets to the proper session.
由于多个BFD会话可能在两个系统之间运行，因此需要有一种机制将接收到的BFD数据包解复用到适当的会话。
Each system MUST choose an opaque discriminator value that identifies each session, and which MUST be unique among all BFD sessions on the system. The local discriminator is sent in the My Discriminator field in the BFD Control packet, and is echoed back in the Your Discriminator field of packets sent from the remote end.
每个系统必须选择一个不透明的鉴别器值，该值标识每个会话，并且在系统上的所有BFD会话中必须是唯一的。本地鉴别器在BFD控制数据包的“我的鉴别器”字段中发送，并在从远程端发送的数据包的“您的鉴别器”字段中回显。
Once the remote end echoes back the local discriminator, all further received packets are demultiplexed based on the Your Discriminator field only (which means that, among other things, the source address field can change or the interface over which the packets are received can change, but the packets will still be associated with the proper session).
一旦远程端回显本地鉴别器，所有进一步接收的数据包将仅基于Your鉴别器字段进行解复用（这意味着，除其他外，源地址字段可以更改，或者接收分组的接口可以更改，但是分组仍将与适当的会话相关联）。
The method of demultiplexing the initial packets (in which Your Discriminator is zero) is application dependent, and is thus outside the scope of this specification.
解复用初始数据包（其中鉴别器为零）的方法取决于应用程序，因此不在本规范的范围内。
Note that it is permissible for a system to change its discriminator during a session without affecting the session state, since only that system uses its discriminator for demultiplexing purposes (by having the other system reflect it back). The implications on an implementation for changing the discriminator value is outside the scope of this specification.
请注意，允许系统在会话期间更改其鉴别器而不影响会话状态，因为只有该系统将其鉴别器用于解复用目的（通过让其他系统将其反射回来）。更改鉴别器值对实现的影响不在本规范的范围内。
The Echo function can be run independently in each direction between a pair of systems. For whatever reason, a system may advertise that it is willing to receive (and loop back) Echo packets, but may not wish to ever send any. The fact that a system is sending Echo packets is not directly signaled to the system looping them back.
回波功能可以在一对系统之间的每个方向上独立运行。无论出于何种原因，系统可能会公布它愿意接收（并回送）回显数据包，但可能不希望发送任何回显数据包。系统发送回显数据包的事实不会直接向系统发送回显信号。
When a system is using the Echo function, it is advantageous to choose a sedate reception rate for Control packets, since liveness detection is being handled by the Echo packets. This can be controlled by manipulating the Required Min RX Interval field (see section 6.8.3).
当系统使用Echo功能时，为控制分组选择一个安静的接收速率是有利的，因为活跃度检测由Echo分组处理。这可以通过操纵所需的最小RX间隔字段来控制（见第6.8.3节）。
If the Echo function is only being run in one direction, the system not running the Echo function will more likely wish to receive fairly rapid Control packets in order to achieve its desired Detection Time. Since BFD allows independent transmission rates in each direction, this is easily accomplished.
如果回声功能仅在一个方向上运行，则不运行回声功能的系统更可能希望接收相当快的控制数据包，以达到其期望的检测时间。由于BFD允许在每个方向上具有独立的传输速率，因此很容易实现。
A system SHOULD otherwise advertise the lowest value of Required Min RX Interval and Required Min Echo RX Interval that it can under the circumstances, to give the other system more freedom in choosing its transmission rate. Note that a system is committing to be able to receive both streams of packets at the rate it advertises, so this should be taken into account when choosing the values to advertise.
否则，一个系统应公布其在这种情况下可以公布的所需最小RX间隔和所需最小回波RX间隔的最低值，以使另一个系统在选择其传输速率时有更多的自由。请注意，系统承诺能够以播发的速率接收两个数据包流，因此在选择要播发的值时应考虑这一点。
A Poll Sequence is an exchange of BFD Control packets that is used in some circumstances to ensure that the remote system is aware of parameter changes. It is also used in Demand mode (see section 6.6) to validate bidirectional connectivity.
轮询序列是BFD控制数据包的交换，在某些情况下用于确保远程系统了解参数更改。它也用于需求模式（见第6.6节），以验证双向连接。
A Poll Sequence consists of a system sending periodic BFD Control packets with the Poll (P) bit set. When the other system receives a Poll, it immediately transmits a BFD Control packet with the Final (F) bit set, independent of any periodic BFD Control packets it may be sending (see section 6.8.7). When the system sending the Poll sequence receives a packet with Final, the Poll Sequence is terminated, and any subsequent BFD Control packets are sent with the Poll bit cleared. A BFD Control packet MUST NOT have both the Poll (P) and Final (F) bits set.
轮询序列由系统发送周期性BFD控制数据包和轮询（P）位组成。当另一个系统接收到轮询时，它立即发送带有最终（F）位设置的BFD控制包，与它可能发送的任何周期性BFD控制包无关（见第6.8.7节）。当发送轮询序列的系统接收到带有Final的数据包时，轮询序列终止，任何后续BFD控制数据包在轮询位清除的情况下发送。BFD控制数据包不能同时设置轮询（P）和最终（F）位。
If periodic BFD Control packets are already being sent (the remote system is not in Demand mode), the Poll Sequence MUST be performed by setting the Poll (P) bit on those scheduled periodic transmissions; additional packets MUST NOT be sent.
如果已经发送周期性BFD控制数据包（远程系统未处于需求模式），则必须通过在这些计划的周期性传输上设置轮询（P）位来执行轮询序列；不得发送其他数据包。
After a Poll Sequence is terminated, the system requesting the Poll Sequence will cease the periodic transmission of BFD Control packets if the remote end is in Demand mode; otherwise, it will return to the periodic transmission of BFD Control packets with the Poll (P) bit clear.
在轮询序列终止后，如果远端处于请求模式，则请求轮询序列的系统将停止BFD控制分组的周期性传输；否则，它将返回到轮询（P）位清除的BFD控制数据包的定期传输。
Typically, the entire sequence consists of a single packet in each direction, though packet losses or relatively long packet latencies may result in multiple Poll packets to be sent before the sequence terminates.
通常，整个序列由每个方向上的单个分组组成，尽管分组丢失或相对较长的分组延迟可能导致在序列终止之前发送多个轮询分组。
Demand mode is requested independently in each direction by virtue of a system setting the Demand (D) bit in its BFD Control packets. The system receiving the Demand bit ceases the periodic transmission of BFD Control packets. If both systems are operating in Demand mode, no periodic BFD Control packets will flow in either direction.
通过系统在其BFD控制数据包中设置需求（D）位，在每个方向上独立请求需求模式。接收到请求位的系统停止BFD控制数据包的周期性传输。如果两个系统都在按需模式下运行，则任何方向都不会有周期性BFD控制数据包。
Demand mode requires that some other mechanism is used to imply continuing connectivity between the two systems. The mechanism used does not have to be the same in both directions, and is outside of the scope of this specification. One possible mechanism is the receipt of traffic from the remote system; another is the use of the Echo function.
需求模式要求使用其他一些机制来暗示两个系统之间的持续连接。所使用的机制在两个方向上不必相同，并且不在本规范的范围内。一种可能的机制是从远程系统接收流量；另一个是使用回声功能。
When a system in Demand mode wishes to verify bidirectional connectivity, it initiates a Poll Sequence (see section 6.5). If no response is received to a Poll, the Poll is repeated until the Detection Time expires, at which point the session is declared to be Down. Note that if Demand mode is operating only on the local system, the Poll Sequence is performed by simply setting the Poll (P) bit in regular periodic BFD Control packets, as required by section 6.5.
当处于需求模式的系统希望验证双向连接时，它会启动轮询序列（参见第6.5节）。如果没有收到对轮询的响应，则将重复轮询，直到检测时间到期，此时会话被声明为关闭。注意，如果需求模式仅在本地系统上运行，则按照第6.5节的要求，只需在定期BFD控制数据包中设置轮询（P）位即可执行轮询序列。
The Detection Time in Demand mode is calculated differently than in Asynchronous mode; it is based on the transmit rate of the local system, rather than the transmit rate of the remote system. This ensures that the Poll Sequence mechanism works properly. See section 6.8.4 for more details.
按需模式下的检测时间计算方式与异步模式下的不同；它基于本地系统的传输速率，而不是远程系统的传输速率。这可以确保轮询序列机制正常工作。详见第6.8.4节。
Note that the Poll mechanism will always fail unless the negotiated Detection Time is greater than the round-trip time between the two systems. Enforcement of this constraint is outside the scope of this specification.
请注意，除非协商检测时间大于两个系统之间的往返时间，否则轮询机制将始终失败。此约束的实施不在本规范的范围内。
Demand mode MAY be enabled or disabled at any time, independently in each direction, by setting or clearing the Demand (D) bit in the BFD Control packet, without affecting the BFD session state. Note that the Demand bit MUST NOT be set unless both systems perceive the session to be Up (the local system thinks the session is Up, and the remote system last reported Up state in the State (Sta) field of the BFD Control packet).
在不影响BFD会话状态的情况下，通过设置或清除BFD控制数据包中的需求（D）位，可以在任何时候在每个方向上独立地启用或禁用需求模式。请注意，除非两个系统都认为会话已启动，否则不得设置请求位（本地系统认为会话已启动，远程系统在BFD控制数据包的状态（Sta）字段中上次报告的启动状态）。
When the transmitted value of the Demand (D) bit is to be changed, the transmitting system MUST initiate a Poll Sequence in conjunction with changing the bit in order to ensure that both systems are aware of the change.
当需求（D）位的传输值要更改时，传输系统必须在更改位的同时启动轮询序列，以确保两个系统都知道更改。
If Demand mode is active on either or both systems, a Poll Sequence MUST be initiated whenever the contents of the next BFD Control packet to be sent would be different than the contents of the previous packet, with the exception of the Poll (P) and Final (F) bits. This ensures that parameter changes are transmitted to the remote system and that the remote system acknowledges these changes.
如果需求模式在任一系统或两个系统上都处于活动状态，则只要要发送的下一个BFD控制数据包的内容与前一个数据包的内容不同，则必须启动轮询序列，轮询（P）位和最终（F）位除外。这可确保将参数更改传输到远程系统，并且远程系统确认这些更改。
Because the underlying detection mechanism is unspecified, and may differ between the two systems, the overall Detection Time characteristics of the path will not be fully known to either system. The total Detection Time for a particular system is the sum of the time prior to the initiation of the Poll Sequence, plus the calculated Detection Time.
由于底层检测机制未指定，并且两个系统之间可能有所不同，因此两个系统都无法完全了解路径的总体检测时间特征。特定系统的总检测时间是轮询序列开始前的时间加上计算的检测时间之和。
Note that if Demand mode is enabled in only one direction, continuous bidirectional connectivity verification is lost (only connectivity in the direction from the system in Demand mode to the other system will be verified). Resolving the issue of one system requesting Demand mode while the other requires continuous bidirectional connectivity verification is outside the scope of this specification.
请注意，如果仅在一个方向上启用需求模式，则会丢失连续双向连接验证（仅验证从需求模式下的系统到另一个系统方向上的连接）。解决一个系统请求需求模式，而另一个系统需要连续双向连接验证的问题不在本规范的范围内。
An optional Authentication Section MAY be present in the BFD Control packet. In its generic form, the purpose of the Authentication Section is to carry all necessary information, based on the authentication type in use, to allow the receiving system to determine the validity of the received packet. The exact mechanism depends on the authentication type in use, but in general the transmitting system will put information in the Authentication
BFD控制分组中可能存在可选的认证部分。在其一般形式中，认证部分的目的是基于所使用的认证类型携带所有必要的信息，以允许接收系统确定所接收分组的有效性。确切的机制取决于使用的身份验证类型，但通常情况下，传输系统会将信息放入身份验证中
Section that vouches for the packet's validity, and the receiving system will examine the Authentication Section and either accept the packet for further processing or discard it.
验证数据包有效性的部分，接收系统将检查验证部分，并接受数据包进行进一步处理或丢弃它。
The same authentication type, and any keys or other necessary information, obviously must be in use by the two systems. The negotiation of authentication type, key exchange, etc., are all outside the scope of this specification and are expected to be performed by means outside of the protocol.
两个系统显然必须使用相同的身份验证类型以及任何密钥或其他必要信息。身份验证类型、密钥交换等的协商均不在本规范的范围内，预计将通过协议之外的方式执行。
Note that in the subsections below, to "accept" a packet means only that the packet has passed authentication; it may in fact be discarded for other reasons as described in the general packet reception rules described in section 6.8.6.
注意，在下面的小节中，“接受”数据包仅意味着该数据包已通过认证；事实上，由于第6.8.6节中所述的一般数据包接收规则中所述的其他原因，可能会将其丢弃。
Implementations supporting authentication MUST support both types of SHA1 authentication. Other forms of authentication are optional.
支持身份验证的实现必须支持两种类型的SHA1身份验证。其他形式的身份验证是可选的。
It may be desirable to enable or disable authentication on a session without disturbing the session state. The exact mechanism for doing so is outside the scope of this specification. However, it is useful to point out some issues in supporting this mechanism.
可能希望在不干扰会话状态的情况下启用或禁用会话上的身份验证。执行此操作的确切机制不在本规范的范围内。然而，指出支持这一机制的一些问题是有益的。
In a simple implementation, a BFD session will fail when authentication is either turned on or turned off, because the packet acceptance rules essentially require the local and remote machines to
在一个简单的实现中，当身份验证打开或关闭时，BFD会话将失败，因为数据包接受规则本质上要求本地和远程计算机
do so in a more or less synchronized fashion (within the Detection Time) -- a packet with authentication will only be accepted if authentication is "in use" (and likewise packets without authentication).
以或多或少同步的方式（在检测时间内）这样做——只有在“正在使用”身份验证的情况下，才会接受具有身份验证的数据包（同样，没有身份验证的数据包也是如此）。
One possible approach is to build an implementation such that authentication is configured, but not considered "in use" until the first packet containing a matching authentication section is received (providing the necessary synchronization). Likewise, authentication could be configured off, but still considered "in use" until the receipt of the first packet without the authentication section.
一种可能的方法是构建一种实现，使得认证被配置，但在接收到包含匹配认证部分的第一个分组（提供必要的同步）之前不被认为是“正在使用”。同样，身份验证可以被配置为关闭，但在没有身份验证部分的情况下收到第一个数据包之前，仍然被视为“正在使用”。
In order to avoid security risks, implementations using this method SHOULD only allow the authentication state to be changed at most once without some form of intervention (so that authentication cannot be turned on and off repeatedly simply based on the receipt of BFD Control packets from remote systems). Unless it is desired to enable or disable authentication, an implementation SHOULD NOT allow the authentication state to change based on the receipt of BFD Control packets.
为了避免安全风险，使用此方法的实现应该只允许在没有某种形式的干预的情况下最多更改一次身份验证状态（因此，身份验证不能仅基于从远程系统接收BFD控制数据包而重复打开和关闭）。除非希望启用或禁用身份验证，否则实现不应允许基于BFD控制数据包的接收更改身份验证状态。
The most straightforward (and weakest) form of authentication is Simple Password Authentication. In this method of authentication, one or more Passwords (with corresponding Key IDs) are configured in each system and one of these Password/ID pairs is carried in each BFD Control packet. The receiving system accepts the packet if the Password and Key ID matches one of the Password/ID pairs configured in that system.
最直接（也是最薄弱）的身份验证形式是简单的密码身份验证。在该认证方法中，在每个系统中配置一个或多个密码（具有相应的密钥ID），并且在每个BFD控制数据包中携带这些密码/ID对中的一个。如果密码和密钥ID与该系统中配置的密码/ID对之一匹配，则接收系统接受该数据包。
Transmission Using Simple Password Authentication
使用简单密码身份验证进行传输
The currently selected password and Key ID for the session MUST be stored in the Authentication Section of each outgoing BFD Control packet. The Auth Type field MUST be set to 1 (Simple Password). The Auth Len field MUST be set to the proper length (4 to 19 bytes).
当前为会话选择的密码和密钥ID必须存储在每个传出BFD控制数据包的身份验证部分。身份验证类型字段必须设置为1（简单密码）。必须将Auth Len字段设置为正确的长度（4到19字节）。
The password is a binary string, and MUST be 1 to 16 bytes in length. For interoperability, the management interface by which the password is configured MUST accept ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported.
密码是二进制字符串，长度必须为1到16字节。为了实现互操作性，用于配置密码的管理接口必须接受ASCII字符串，并且还应允许以十六进制形式配置任意二进制字符串。可能支持其他配置方法。
Reception Using Simple Password Authentication
使用简单密码验证进行接收
If the received BFD Control packet does not contain an Authentication Section, or the Auth Type is not 1 (Simple Password), then the received packet MUST be discarded.
如果收到的BFD控制数据包不包含身份验证部分，或者身份验证类型不是1（简单密码），则必须丢弃收到的数据包。
If the Auth Key ID field does not match the ID of a configured password, the received packet MUST be discarded.
如果Auth Key ID字段与配置的密码的ID不匹配，则必须丢弃接收到的数据包。
If the Auth Len field is not equal to the length of the password selected by the key ID, plus three, the packet MUST be discarded.
如果Auth Len字段不等于密钥ID选择的密码长度加上三，则必须丢弃该数据包。
If the Password field does not match the password selected by the key ID, the packet MUST be discarded.
如果密码字段与密钥ID选择的密码不匹配，则必须丢弃数据包。
Otherwise, the packet MUST be accepted.
否则，必须接受数据包。
The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are very similar to those used in other protocols. In these methods of authentication, one or more secret keys (with corresponding key IDs) are configured in each system. One of the keys is included in an MD5 [MD5] digest calculated over the outgoing BFD Control packet, but the Key itself is not carried in the packet. To help avoid replay attacks, a sequence number is also carried in each packet. For Keyed MD5, the sequence number is occasionally incremented. For Meticulous Keyed MD5, the sequence number is incremented on every packet.
加密MD5和加密MD5身份验证机制与其他协议中使用的机制非常相似。在这些认证方法中，在每个系统中配置一个或多个密钥（具有相应的密钥ID）。其中一个密钥包含在通过传出BFD控制数据包计算的MD5[MD5]摘要中，但密钥本身不在数据包中携带。为了避免重播攻击，每个数据包中还携带一个序列号。对于键控MD5，序列号偶尔会增加。对于精心键入的MD5，序列号在每个数据包上递增。
The receiving system accepts the packet if the key ID matches one of the configured Keys, an MD5 digest including the selected key matches that carried in the packet, and the sequence number is greater than or equal to the last sequence number received (for Keyed MD5), or strictly greater than the last sequence number received (for Meticulous Keyed MD5).
如果密钥ID与配置的密钥之一匹配，则接收系统接受数据包，MD5摘要包括数据包中携带的所选密钥匹配，并且序列号大于或等于接收到的最后一个序列号（对于键控MD5），或严格大于接收到的最后一个序列号（适用于精心键入的MD5）。
Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication
使用加密MD5和加密MD5身份验证进行传输
The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous Keyed MD5). The Auth Len field MUST be set to 24. The Auth Key ID field MUST be set to the ID of the current authentication key. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
身份验证类型字段必须设置为2（键入MD5）或3（键入MD5）。“验证长度”字段必须设置为24。身份验证密钥ID字段必须设置为当前身份验证密钥的ID。序列号字段必须设置为bfd.XmitAuthSeq。
The authentication key value is a binary string of up to 16 bytes, and MUST be placed into the Auth Key/Digest field, padded with trailing zero bytes as necessary. For interoperability, the management interface by which the key is configured MUST accept
身份验证密钥值是一个最多16字节的二进制字符串，必须放在Auth key/Digest字段中，必要时用尾随的零字节填充。对于互操作性，配置密钥的管理接口必须接受
ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported.
ASCII字符串，还应允许以十六进制形式配置任意二进制字符串。可能支持其他配置方法。
An MD5 digest MUST be calculated over the entire BFD Control packet. The resulting digest MUST be stored in the Auth Key/Digest field prior to transmission (replacing the secret key, which MUST NOT be carried in the packet).
必须对整个BFD控制数据包计算MD5摘要。在传输之前，生成的摘要必须存储在Auth Key/digest字段中（替换不能在数据包中携带的密钥）。
For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular fashion (when treated as an unsigned 32-bit value). bfd.XmitAuthSeq SHOULD be incremented when the session state changes, or when the transmitted BFD Control packet carries different contents than the previously transmitted packet. The decision as to when to increment bfd.XmitAuthSeq is outside the scope of this specification. See the section titled "Security Considerations" below for a discussion.
对于键控MD5，bfd.XmitAuthSeq可以循环递增（当被视为无符号32位值时）。当会话状态改变时，或者当传输的bfd控制数据包携带与先前传输的数据包不同的内容时，bfd.XmitAuthSeq应该增加。关于何时增加bfd.XmitAuthSeq的决定超出了本规范的范围。有关讨论，请参阅下面标题为“安全注意事项”的部分。
For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a circular fashion (when treated as an unsigned 32-bit value).
对于精细键控MD5，bfd.XmitAuthSeq必须以循环方式递增（当被视为无符号32位值时）。
Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication
使用键控MD5和精细键控MD5身份验证的收据
If the received BFD Control packet does not contain an Authentication Section, or the Auth Type is not correct (2 for Keyed MD5 or 3 for Meticulous Keyed MD5), then the received packet MUST be discarded.
如果接收到的BFD控制数据包不包含身份验证部分，或者身份验证类型不正确（2个用于密钥MD5，3个用于密钥MD5），则必须丢弃接收到的数据包。
If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded.
如果身份验证密钥ID字段与配置的身份验证密钥的ID不匹配，则必须丢弃接收的数据包。
If the Auth Len field is not equal to 24, the packet MUST be discarded.
如果Auth Len字段不等于24，则必须丢弃数据包。
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For Keyed MD5, if the sequence number lies outside of the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space), the received packet MUST be discarded. For Meticulous Keyed MD5, if the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space) the received packet MUST be discarded.
如果bfd.AuthSeqKnown为1，请检查序列号字段。对于键控MD5，如果序列号超出bfd.RcvAuthSeq到bfd.RcvAuthSeq+（3*Detect Mult）的范围（当视为无符号32位循环数空间时），则必须丢弃接收的数据包。对于精心设置密钥的MD5，如果序列号超出bfd.RcvAuthSeq+1到bfd.RcvAuthSeq+（3*Detect Mult）的范围（当被视为无符号32位循环数空间时），则必须丢弃接收的数据包。
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, and bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field.
否则（bfd.AuthSeqKnown为0），bfd.AuthSeqKnown必须设置为1，bfd.RcvAuthSeq必须设置为接收序列号字段的值。
Replace the contents of the Auth Key/Digest field with the authentication key selected by the received Auth Key ID field. If the MD5 digest of the entire BFD Control packet is equal to the received value of the Auth Key/Digest field, the received packet MUST be accepted. Otherwise (the digest does not match the Auth Key/Digest field), the received packet MUST be discarded.
用接收的身份验证密钥ID字段选择的身份验证密钥替换身份验证密钥/摘要字段的内容。如果整个BFD控制数据包的MD5摘要等于Auth Key/digest字段的接收值，则必须接受接收的数据包。否则（摘要与身份验证密钥/摘要字段不匹配），必须丢弃接收到的数据包。
The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms are very similar to those used in other protocols. In these methods of authentication, one or more secret keys (with corresponding key IDs) are configured in each system. One of the keys is included in a SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but the key itself is not carried in the packet. To help avoid replay attacks, a sequence number is also carried in each packet. For Keyed SHA1, the sequence number is occasionally incremented. For Meticulous Keyed SHA1, the sequence number is incremented on every packet.
密钥化SHA1和精细密钥化SHA1身份验证机制与其他协议中使用的机制非常相似。在这些认证方法中，在每个系统中配置一个或多个密钥（具有相应的密钥ID）。其中一个密钥包含在通过传出BFD控制分组计算的SHA1[SHA1]散列中，但密钥本身不在分组中携带。为了避免重播攻击，每个数据包中还携带一个序列号。对于键控SHA1，序列号偶尔会增加。对于精心键入的SHA1，序列号在每个数据包上递增。
The receiving system accepts the packet if the key ID matches one of the configured keys, a SHA1 hash including the selected key matches that carried in the packet, and if the sequence number is greater than or equal to the last sequence number received (for Keyed SHA1), or strictly greater than the last sequence number received (for Meticulous Keyed SHA1).
如果密钥ID与配置的密钥之一相匹配，SHA1散列（包括分组中携带的所选密钥匹配），并且如果序列号大于或等于接收到的最后一个序列号（对于键控SHA1），或者严格大于接收到的最后一个序列号，则接收系统接受该分组（用于精细的键控SHA1）。
Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication
使用键控SHA1和精细键控SHA1身份验证进行传输
The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1). The Auth Len field MUST be set to 28. The Auth Key ID field MUST be set to the ID of the current authentication key. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
身份验证类型字段必须设置为4（键控SHA1）或5（键控SHA1）。“验证长度”字段必须设置为28。身份验证密钥ID字段必须设置为当前身份验证密钥的ID。序列号字段必须设置为bfd.XmitAuthSeq。
The authentication key value is a binary string of up to 20 bytes, and MUST be placed into the Auth Key/Hash field, padding with trailing zero bytes as necessary. For interoperability, the management interface by which the key is configured MUST accept ASCII strings, and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported.
身份验证密钥值是一个最多20字节的二进制字符串，必须放在Auth key/Hash字段中，必要时用尾随的零字节填充。为了实现互操作性，配置密钥的管理接口必须接受ASCII字符串，并且还应允许以十六进制形式配置任意二进制字符串。可能支持其他配置方法。
A SHA1 hash MUST be calculated over the entire BFD control packet. The resulting hash MUST be stored in the Auth Key/Hash field prior to transmission (replacing the secret key, which MUST NOT be carried in the packet).
必须在整个BFD控制数据包上计算SHA1哈希。在传输之前，结果散列必须存储在Auth Key/hash字段中（替换不能在数据包中携带的密钥）。
For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular fashion (when treated as an unsigned 32-bit value). bfd.XmitAuthSeq SHOULD be incremented when the session state changes, or when the transmitted BFD Control packet carries different contents than the previously transmitted packet. The decision as to when to increment bfd.XmitAuthSeq is outside the scope of this specification. See the section titled "Security Considerations" below for a discussion.
对于键控SHA1，bfd.XmitAuthSeq可以循环递增（当被视为无符号32位值时）。当会话状态改变时，或者当传输的bfd控制数据包携带与先前传输的数据包不同的内容时，bfd.XmitAuthSeq应该增加。关于何时增加bfd.XmitAuthSeq的决定超出了本规范的范围。有关讨论，请参阅下面标题为“安全注意事项”的部分。
For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in a circular fashion (when treated as an unsigned 32-bit value).
对于精细键控SHA1，bfd.XmitAuthSeq必须以循环方式递增（当被视为无符号32位值时）。
Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication
使用键控SHA1和精细键控SHA1身份验证的收据
If the received BFD Control packet does not contain an Authentication Section, or the Auth Type is not correct (4 for Keyed SHA1 or 5 for Meticulous Keyed SHA1), then the received packet MUST be discarded.
如果接收到的BFD控制数据包不包含身份验证部分，或者身份验证类型不正确（4表示密钥化SHA1，5表示密钥化SHA1），则必须丢弃接收到的数据包。
If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded.
如果身份验证密钥ID字段与配置的身份验证密钥的ID不匹配，则必须丢弃接收的数据包。
If the Auth Len field is not equal to 28, the packet MUST be discarded.
如果Auth Len字段不等于28，则必须丢弃数据包。
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For Keyed SHA1, if the sequence number lies outside of the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space), the received packet MUST be discarded. For Meticulous Keyed SHA1, if the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space, the received packet MUST be discarded.
如果bfd.AuthSeqKnown为1，请检查序列号字段。对于键控SHA1，如果序列号超出bfd.RcvAuthSeq到bfd.RcvAuthSeq+（3*Detect Mult）的范围（当视为无符号32位循环数空间时），则必须丢弃接收的数据包。对于精心设置密钥的SHA1，如果序列号超出bfd.RcvAuthSeq+1到bfd.RcvAuthSeq+（3*Detect Mult）的范围（当被视为无符号32位循环数空间时，则必须丢弃接收的数据包。
Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1, bfd.RcvAuthSeq MUST be set to the value of the received Sequence Number field, and the received packet MUST be accepted.
否则（bfd.AuthSeqKnown为0），bfd.AuthSeqKnown必须设置为1，bfd.RcvAuthSeq必须设置为接收序列号字段的值，并且必须接受接收的数据包。
Replace the contents of the Auth Key/Hash field with the authentication key selected by the received Auth Key ID field. If the SHA1 hash of the entire BFD Control packet is equal to the received value of the Auth Key/Hash field, the received packet MUST be accepted. Otherwise (the hash does not match the Auth Key/Hash field), the received packet MUST be discarded.
用接收到的身份验证密钥ID字段选择的身份验证密钥替换身份验证密钥/哈希字段的内容。如果整个BFD控制数据包的SHA1散列等于Auth Key/hash字段的接收值，则必须接受接收的数据包。否则（哈希与身份验证密钥/哈希字段不匹配），必须丢弃接收到的数据包。
The following section of this specification is normative. The means by which this specification is achieved is outside the scope of this specification.
本规范的以下章节为规范性章节。实现本规范的方法不在本规范的范围内。
When a system is said to have "the Echo function active" it means that the system is sending BFD Echo packets, implying that the session is Up and the other system has signaled its willingness to loop back Echo packets.
当一个系统被称为“Echo功能处于活动状态”时，这意味着该系统正在发送BFD Echo数据包，这意味着会话已启动，而另一个系统已发出信号表示愿意回送Echo数据包。
When the local system is said to have "Demand mode active," it means that bfd.DemandMode is 1 in the local system (see section 6.8.1), the session is Up, and the remote system is signaling that the session is in state Up.
当本地系统被称为“需求模式激活”时，这意味着本地系统中的bfd.DemandMode为1（参见第6.8.1节），会话启动，远程系统发出会话处于启动状态的信号。
When the remote system is said to have "Demand mode active," it means that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D) bit in the last received BFD Control packet), the session is Up, and the remote system is signaling that the session is in state Up.
当远程系统被称为“请求模式激活”时，这意味着bfd.RemoteDemandMode为1（远程系统在最后接收到的bfd控制数据包中设置请求（D）位），会话启动，远程系统发出会话处于启动状态的信号。
A minimum amount of information about a session needs to be tracked in order to achieve the elements of procedure described here. The following is a set of state variables that are helpful in describing the mechanisms of BFD. Any means of tracking this state may be used so long as the protocol behaves as described.
需要跟踪会话的最少信息量，以实现此处描述的过程要素。以下是一组有助于描述BFD机制的状态变量。只要协议的行为如所述，就可以使用跟踪该状态的任何方法。
When the text refers to initializing a state variable, this takes place only at the time that the session (and the corresponding state variables) is created. The state variables are subsequently manipulated by the state machine and are never reinitialized, even if the session fails and is reestablished.
当文本提到初始化状态变量时，这仅在创建会话（以及相应的状态变量）时发生。状态变量随后由状态机操作，并且永远不会重新初始化，即使会话失败并重新建立。
Once session state is created, and at least one BFD Control packet is received from the remote end, it MUST be preserved for at least one Detection Time (see section 6.8.4) subsequent to the receipt of the last BFD Control packet, regardless of the session state. This preserves timing parameters in case the session flaps. A system MAY preserve session state longer than this. The preservation or destruction of session state when no BFD Control packets for this session have been received from the remote system is outside the scope of this specification.
一旦创建了会话状态，并且从远程端接收到至少一个BFD控制数据包，则无论会话状态如何，在接收到最后一个BFD控制数据包后，必须将其至少保留一次检测时间（见第6.8.4节）。这将在会话切换时保留计时参数。系统保留会话状态的时间可能长于此时间。当没有从远程系统接收到此会话的BFD控制数据包时，会话状态的保存或销毁超出了本规范的范围。
All state variables in this specification are of the form "bfd.Xx" and should not be confused with fields carried in the protocol packets, which are always spelled out to match the names in section 4.
本规范中的所有状态变量均为“bfd.Xx”形式，不应与协议数据包中包含的字段混淆，协议数据包中的字段拼写始终与第4节中的名称相匹配。
bfd.SessionState
会话状态
The perceived state of the session (Init, Up, Down, or AdminDown). The exact action taken when the session state changes is outside the scope of this specification, though it is expected that this state change (particularly, to and from Up state) is reported to other components of the system. This variable MUST be initialized to Down.
会话的感知状态（Init、Up、Down或AdminDown）。会话状态更改时所采取的确切操作不在本规范的范围内，尽管预计该状态更改（尤其是从“启动”状态到“启动”状态）会报告给系统的其他组件。此变量必须初始化为Down。
bfd.RemoteSessionState
bfd.RemoteSessionState
The session state last reported by the remote system in the State (Sta) field of the BFD Control packet. This variable MUST be initialized to Down.
远程系统上次在BFD控制数据包的状态（Sta）字段中报告的会话状态。此变量必须初始化为Down。
bfd.LocalDiscr
bfd.LocalDiscr
The local discriminator for this BFD session, used to uniquely identify it. It MUST be unique across all BFD sessions on this system, and nonzero. It SHOULD be set to a random (but still unique) value to improve security. The value is otherwise outside the scope of this specification.
此BFD会话的本地鉴别器，用于唯一标识它。在该系统上的所有BFD会话中，它必须是唯一的，并且非零。应将其设置为随机（但仍然是唯一）值以提高安全性。该值不在本规范的范围内。
bfd.RemoteDiscr
远程磁盘驱动器
The remote discriminator for this BFD session. This is the discriminator chosen by the remote system, and is totally opaque to the local system. This MUST be initialized to zero. If a period of a Detection Time passes without the receipt of a valid, authenticated BFD packet from the remote system, this variable MUST be set to zero.
此BFD会话的远程鉴别器。这是远程系统选择的鉴别器，对本地系统完全不透明。这必须初始化为零。如果一段检测时间过后，未收到来自远程系统的有效、经过身份验证的BFD数据包，则该变量必须设置为零。
bfd.LocalDiag
bfd.LocalDiag
The diagnostic code specifying the reason for the most recent change in the local session state. This MUST be initialized to zero (No Diagnostic).
指定本地会话状态最近更改原因的诊断代码。必须将其初始化为零（无诊断）。
bfd.DesiredMinTxInterval
bfd.DesiredMinTxInterval
The minimum interval, in microseconds, between transmitted BFD Control packets that this system would like to use at the current time, less any jitter applied (see section 6.8.2). The actual interval is negotiated between the two systems. This MUST be initialized to a value of at least one second (1,000,000 microseconds) according to the rules described in section 6.8.3. The setting of this variable is otherwise outside the scope of this specification.
系统希望在当前时间使用的传输BFD控制数据包之间的最小间隔（以微秒为单位），减去应用的任何抖动（见第6.8.2节）。实际间隔由两个系统协商确定。必须根据第6.8.3节中描述的规则将其初始化为至少1秒（1000000微秒）的值。此变量的设置超出了本规范的范围。
bfd.RequiredMinRxInterval
bfd.RequiredMinRxInterval
The minimum interval, in microseconds, between received BFD Control packets that this system requires, less any jitter applied by the sender (see section 6.8.2). The setting of this variable is outside the scope of this specification. A value of zero means that this system does not want to receive any periodic BFD Control packets. See section 6.8.18 for details.
该系统要求接收的BFD控制数据包之间的最小间隔（以微秒为单位），减去发送方施加的任何抖动（见第6.8.2节）。此变量的设置不在本规范的范围内。值为零表示此系统不希望接收任何定期BFD控制数据包。详见第6.8.18节。
bfd.RemoteMinRxInterval
bfd.RemoteMinRxInterval
The last value of Required Min RX Interval received from the remote system in a BFD Control packet. This variable MUST be initialized to 1.
BFD控制数据包中从远程系统接收的所需最小RX间隔的最后一个值。此变量必须初始化为1。
bfd.DemandMode
需求模式
Set to 1 if the local system wishes to use Demand mode, or 0 if not.
如果本地系统希望使用需求模式，则设置为1，否则设置为0。
bfd.RemoteDemandMode
bfd.RemoteDemandMode
Set to 1 if the remote system wishes to use Demand mode, or 0 if not. This is the value of the Demand (D) bit in the last received BFD Control packet. This variable MUST be initialized to zero.
如果远程系统希望使用按需模式，则设置为1，否则设置为0。这是上次接收到的BFD控制数据包中的需求（D）位的值。此变量必须初始化为零。
bfd.DetectMult
探测结果
The desired Detection Time multiplier for BFD Control packets on the local system. The negotiated Control packet transmission interval, multiplied by this variable, will be the Detection Time for this session (as seen by the remote system). This variable MUST be a nonzero integer, and is otherwise outside the scope of this specification. See section 6.8.4 for further information.
本地系统上BFD控制数据包所需的检测时间乘数。协商的控制包传输间隔乘以该变量，将成为该会话的检测时间（如远程系统所示）。此变量必须是非零整数，否则超出本规范的范围。详见第6.8.4节。
bfd.AuthType
bfd.AuthType
The authentication type in use for this session, as defined in section 4.1, or zero if no authentication is in use.
如第4.1节所定义，此会话使用的身份验证类型，如果未使用身份验证，则为零。
bfd.RcvAuthSeq
bfd.RcvAuthSeq
A 32-bit unsigned integer containing the last sequence number for Keyed MD5 or SHA1 Authentication that was received. The initial value is unimportant.
一个32位无符号整数，包含接收到的带密钥MD5或SHA1身份验证的最后一个序列号。初始值并不重要。
bfd.XmitAuthSeq
bfd.XmitAuthSeq
A 32-bit unsigned integer containing the next sequence number for Keyed MD5 or SHA1 Authentication to be transmitted. This variable MUST be initialized to a random 32-bit value.
一个32位无符号整数，包含要传输的键控MD5或SHA1身份验证的下一个序列号。此变量必须初始化为随机32位值。
bfd.AuthSeqKnown
bfd.authSeq已知
Set to 1 if the next sequence number for Keyed MD5 or SHA1 authentication expected to be received is known, or 0 if it is not known. This variable MUST be initialized to zero.
如果预期接收的键控MD5或SHA1身份验证的下一个序列号已知，则设置为1；如果未知，则设置为0。此变量必须初始化为零。
This variable MUST be set to zero after no packets have been received on this session for at least twice the Detection Time. This ensures that the sequence number can be resynchronized if the remote system restarts.
在该会话上至少两倍检测时间内未收到任何数据包后，必须将该变量设置为零。这可确保在远程系统重新启动时序列号可以重新同步。
The time values used to determine BFD packet transmission intervals and the session Detection Time are continuously negotiated, and thus may be changed at any time. The negotiation and time values are independent in each direction for each session.
用于确定BFD分组传输间隔和会话检测时间的时间值是连续协商的，因此可以随时改变。协商值和时间值在每个会话的每个方向上都是独立的。
Each system reports in the BFD Control packet how rapidly it would like to transmit BFD packets, as well as how rapidly it is prepared to receive them. This allows either system to unilaterally determine the maximum packet rate (minimum interval) in both directions.
每个系统在BFD控制数据包中报告它希望以多快的速度传输BFD数据包，以及准备以多快的速度接收这些数据包。这允许任一系统单方面确定两个方向上的最大分组速率（最小间隔）。
See section 6.8.7 for the details of packet transmission timing and negotiation.
有关数据包传输定时和协商的详细信息，请参见第6.8.7节。
The time values used to determine BFD packet transmission intervals and the session Detection Time may be modified at any time without affecting the state of the session. When the timer parameters are changed for any reason, the requirements of this section apply.
用于确定BFD分组传输间隔和会话检测时间的时间值可以在任何时候修改，而不影响会话的状态。当定时器参数因任何原因改变时，本节的要求适用。
If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated (see section 6.5). If the timing is such that a system receiving a Poll Sequence wishes to change the parameters described in this paragraph, the new parameter values MAY be carried in packets with the Final (F) bit set, even if the Poll Sequence has not yet been sent.
如果更改了bfd.DesiredMinxinterval或bfd.RequiredMinRxInterval，则必须启动轮询序列（见第6.5节）。如果定时使得接收轮询序列的系统希望改变本段中描述的参数，则即使尚未发送轮询序列，也可以在设置了最终（F）位的分组中携带新的参数值。
If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, the actual transmission interval used MUST NOT change until the Poll Sequence described above has terminated. This is to ensure that the remote system updates its Detection Time before the transmission interval increases.
如果bfd.DesiredMinTxInterval增加且bfd.SessionState启动，则在上述轮询序列终止之前，所使用的实际传输间隔不得更改。这是为了确保远程系统在传输间隔增加之前更新其检测时间。
If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, the previous value of bfd.RequiredMinRxInterval MUST be used when calculating the Detection Time for the remote system until the Poll Sequence described above has terminated. This is to ensure that the remote system is transmitting packets at the higher rate (and those packets are being received) prior to the Detection Time being reduced.
如果bfd.RequiredMinRxInterval减少且bfd.SessionState启动，则在计算远程系统的检测时间时，必须使用bfd.RequiredMinRxInterval的先前值，直到上述轮询序列终止。这是为了确保在减少检测时间之前，远程系统以更高的速率传输数据包（并且正在接收这些数据包）。
When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds). This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD.
当bfd.SessionState未启动时，系统必须将bfd.DesiredMinTxInterval设置为不小于1秒（1000000微秒）的值。这是为了确保未启动的BFD会话所消耗的带宽可以忽略不计，特别是在邻居可能未运行BFD的情况下。
If the local system reduces its transmit interval due to bfd.RemoteMinRxInterval being reduced (the remote system has advertised a reduced value in Required Min RX Interval), and the remote system is not in Demand mode, the local system MUST honor the new interval immediately. In other words, the local system cannot wait longer than the new interval between the previous packet transmission and the next one. If this interval has already passed since the last transmission (because the new interval is significantly shorter), the local system MUST send the next periodic BFD Control packet as soon as practicable.
如果本地系统由于bfd.RemoteMinRxInterval减小而减小其传输间隔（远程系统已在所需的最小接收间隔中公布减小的值），并且远程系统未处于需求模式，则本地系统必须立即遵守新的间隔。换句话说，本地系统不能等待超过上一个数据包传输和下一个数据包传输之间的新间隔。如果自上次传输以来该间隔已经过去（因为新间隔明显更短），本地系统必须尽快发送下一个定期BFD控制数据包。
When the Echo function is active, a system SHOULD set bfd.RequiredMinRxInterval to a value of not less than one second (1,000,000 microseconds). This is intended to keep received BFD Control traffic at a negligible level, since the actual detection function is being performed using BFD Echo packets.
当回波功能激活时，系统应将bfd.RequiredMinRxInterval设置为不小于1秒（1000000微秒）的值。这是为了将接收到的BFD控制流量保持在可忽略的水平，因为实际检测功能是使用BFD回波数据包执行的。
In any case other than those explicitly called out above, timing parameter changes MUST be effected immediately (changing the transmission rate and/or the Detection Time).
在除上述明确要求之外的任何情况下，必须立即改变定时参数（改变传输速率和/或检测时间）。
Note that the Poll Sequence mechanism is ambiguous if more than one parameter change is made that would require its use, and those multiple changes are spread across multiple packets (since the semantics of the returning Final are unclear). Therefore, if multiple changes are made that require the use of a Poll Sequence, there are three choices: 1) they MUST be communicated in a single BFD Control packet (so the semantics of the Final reply are clear), or 2) sufficient time must have transpired since the Poll Sequence was completed to disambiguate the situation (at least a round trip time since the last Poll was transmitted) prior to the initiation of another Poll Sequence, or 3) an additional BFD Control packet with the Final (F) bit *clear* MUST be received after the Poll Sequence has completed prior to the initiation of another Poll Sequence (this option is not available when Demand mode is active).
请注意，如果需要使用多个参数更改，并且这些更改分布在多个数据包中，则轮询序列机制是不明确的（因为返回Final的语义不清楚）。因此，如果进行了需要使用轮询序列的多个更改，则有三种选择：1）必须在单个BFD控制数据包中进行通信（因此最终回复的语义是明确的），或2）自轮询序列完成以来必须有足够的时间来消除情况的歧义（至少自上次轮询发送后的往返时间）在启动另一个轮询序列之前，或3）在启动另一个轮询序列之前完成轮询序列之后，必须接收具有最终（F）位*清除*的附加BFD控制数据包（当需求模式激活时，此选项不可用）。
The Detection Time (the period of time without receiving BFD packets after which the session is determined to have failed) is not carried explicitly in the protocol. Rather, it is calculated independently in each direction by the receiving system based on the negotiated transmit interval and the detection multiplier. Note that there may be different Detection Times in each direction.
协议中未明确规定检测时间（未接收BFD数据包的时间段，在此时间段之后，会话被确定为失败）。相反，它由接收系统基于协商的发送间隔和检测乘法器在每个方向上独立地计算。注意，每个方向上可能有不同的检测时间。
The calculation of the Detection Time is slightly different when in Demand mode versus Asynchronous mode.
在需求模式和异步模式下，检测时间的计算略有不同。
In Asynchronous mode, the Detection Time calculated in the local system is equal to the value of Detect Mult received from the remote system, multiplied by the agreed transmit interval of the remote system (the greater of bfd.RequiredMinRxInterval and the last received Desired Min TX Interval). The Detect Mult value is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down.
在异步模式下，本地系统中计算的检测时间等于从远程系统接收到的Detect Mult值乘以远程系统的约定发送间隔（bfd.RequiredMinRxInterval和上次接收到的期望最小发送间隔中的较大值）。Detect Mult值是（粗略地说，由于抖动）一行中必须丢失的数据包数，以声明会话关闭。
If Demand mode is not active, and a period of time equal to the Detection Time passes without receiving a BFD Control packet from the remote system, and bfd.SessionState is Init or Up, the session has gone down -- the local system MUST set bfd.SessionState to Down and bfd.LocalDiag to 1 (Control Detection Time Expired).
如果请求模式未处于活动状态，并且经过了相当于检测时间的一段时间而未从远程系统接收BFD控制数据包，并且BFD.SessionState为Init或Up，则会话已关闭--本地系统必须将BFD.SessionState设置为down，将BFD.LocalDiag设置为1（控制检测时间已过期）。
In Demand mode, the Detection Time calculated in the local system is equal to bfd.DetectMult, multiplied by the agreed transmit interval of the local system (the greater of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval). bfd.DetectMult is (roughly speaking, due to jitter) the number of packets that have to be missed in a row to declare the session to be down.
在需求模式下，本地系统中计算的检测时间等于bfd.DetectMult乘以本地系统约定的传输间隔（bfd.DESIREDMINXINTERVAL和bfd.RemoteMinRxInterval中的较大者）。bfd.DetectMult是（粗略地说，由于抖动）一行中必须丢失的数据包数，以声明会话关闭。
If Demand mode is active, and a period of time equal to the Detection Time passes after the initiation of a Poll Sequence (the transmission of the first BFD Control packet with the Poll bit set), the session has gone down -- the local system MUST set bfd.SessionState to Down, and bfd.LocalDiag to 1 (Control Detection Time Expired).
如果请求模式处于活动状态，并且在发起轮询序列（设置轮询位的第一个BFD控制数据包的传输）后经过了一段与检测时间相等的时间，则会话已停止——本地系统必须将BFD.SessionState设置为down，将BFD.LocalDiag设置为1（控制检测时间已过期）。
(Note that a packet is considered to have been received, for the purposes of Detection Time expiration, only if it has not been "discarded" according to the rules of section 6.8.6).
（注意，为了检测时间到期，仅当数据包未根据第6.8.6节的规则被“丢弃”时，才视为已收到数据包）。
When the Echo function is active and a sufficient number of Echo packets have not arrived as they should, the session has gone down -- the local system MUST set bfd.SessionState to Down and bfd.LocalDiag to 2 (Echo Function Failed).
当Echo函数处于活动状态且有足够数量的Echo数据包未按预期到达时，会话已停止--本地系统必须将bfd.SessionState设置为down，将bfd.LocalDiag设置为2（Echo函数失败）。
The means by which the Echo function failures are detected is outside of the scope of this specification. Any means that will detect a communication failure are acceptable.
检测回波功能故障的方法不在本规范的范围内。任何检测通信故障的方法都是可以接受的。
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 Multipoint (M) bit is nonzero, the packet MUST be discarded.
如果多点（M）位为非零，则必须丢弃数据包。
If the My Discriminator field is zero, the packet MUST be discarded.
如果My鉴别器字段为零，则必须丢弃数据包。
If the Your Discriminator field is nonzero, it MUST be used to select the session with which this BFD packet is associated. If no session is found, the packet MUST be discarded.
如果Your Discriminator字段为非零，则必须使用该字段选择与此BFD数据包关联的会话。如果找不到会话，则必须丢弃数据包。
If the Your Discriminator field is zero and the State field is not Down or AdminDown, the packet MUST be discarded.
如果Your Discriminator字段为零且State字段不是Down或AdminDown，则必须丢弃数据包。
If the Your Discriminator field is zero, 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 not found, a new session MAY be created, or the packet MAY be discarded. This choice is outside the scope of this specification.
如果Your Discriminator字段为零，则必须根据其他字段的某些组合来选择会话，这些字段可能包括源地址信息、My Discriminator字段和接收数据包的接口。具体的选择方法因应用而异，因此不在本规范的范围内。如果未找到匹配的会话，则可能会创建新会话，或者丢弃数据包。此选择不在本规范的范围内。
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, based on the authentication type in use (bfd.AuthType). This may cause the packet to be discarded.
如果设置了A位，则必须根据第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）位，则必须终止轮询序列。
Update the transmit interval as described in section 6.8.2.
按照第6.8.2节所述更新传输间隔。
Update the Detection Time as described in section 6.8.4.
按照第6.8.4节所述更新检测时间。
If bfd.SessionState is AdminDown
如果bfd.SessionState为AdminDown
Discard the packet
丢弃包
If received state is AdminDown If bfd.SessionState is not Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down
如果接收状态为AdminDown，如果bfd.SessionState未关闭，则将bfd.LocalDiag设置为3（邻居信号会话关闭），将bfd.SessionState设置为Down
Else
其他的
If bfd.SessionState is Down If received State is Down Set bfd.SessionState to Init Else if received State is Init Set bfd.SessionState to Up
如果bfd.SessionState为Down，如果接收到的状态为Down，则将bfd.SessionState设置为Init；如果接收到的状态为Init，则将bfd.SessionState设置为Up
Else if bfd.SessionState is Init If received State is Init or Up Set bfd.SessionState to Up
否则，如果bfd.SessionState为Init，如果接收到的状态为Init，则设置bfd.SessionState为Up
Else (bfd.SessionState is Up) If received State is Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down
Else（bfd.SessionState为上）如果接收到的状态为Down，则将bfd.LocalDiag设置为3（邻居发出信号的会话关闭）将bfd.SessionState设置为Down
Check to see if Demand mode should become active or not (see section 6.6).
检查需求模式是否应激活（见第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 6.8.7).
如果bfd.RemoteDemandMode为1，bfd.SessionState为Up，bfd.RemoteSessionState为Up，则远程系统上的请求模式处于活动状态，本地系统必须停止定期传输bfd控制数据包（参见第6.8.7节）。
If bfd.RemoteDemandMode is 0, or 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 6.8.7).
如果bfd.RemoteDemandMode为0，或bfd.SessionState未启动，或bfd.RemoteSessionState未启动，则远程系统上的请求模式不处于活动状态，并且本地系统必须定期发送bfd控制数据包（参见第6.8.7节）。
If the Poll (P) bit is set, send a BFD Control packet to the remote system with the Poll (P) bit clear, and the Final (F) bit set (see section 6.8.7).
如果设置了轮询（P）位，则向远程系统发送一个BFD控制数据包，清除轮询（P）位，并设置最终（F）位（见第6.8.7节）。
If the packet was not discarded, it has been received for purposes of the Detection Time expiration rules in section 6.8.4.
如果数据包未被丢弃，则根据第6.8.4节中的检测时间到期规则，数据包已被接收。
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控制数据包之前，计算出的检测时间不会过去。
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 for details on transmit timers.
每当bfd.desiredMinrXinterval更改或bfd.RemoteMinRxInterval更改时，必须重新计算传输间隔，并且该间隔等于这两个值中的较大值。有关传输定时器的详细信息，请参见第6.8.2节和第6.8.3节。
A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is zero and the system is taking the Passive role.
如果BFD.RemoteDiscr为零且系统处于被动角色，则系统不得传输BFD控制数据包。
A system MUST NOT periodically transmit BFD Control packets if bfd.RemoteMinRxInterval is zero.
如果BFD.RemoteMinRxInterval为零，则系统不得定期发送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控制数据包。
If a BFD Control packet is received with the Poll (P) bit set to 1, the receiving system MUST transmit a BFD Control packet with the Poll (P) bit clear and the Final (F) bit set as soon as practicable, without respect to the transmission timer or any other transmission limitations, without respect to the session state, and without respect to whether Demand mode is active on either system. A system MAY limit the rate at which such packets are transmitted. If rate limiting is in effect, the advertised value of Desired Min TX Interval MUST be greater than or equal to the interval between transmitted packets imposed by the rate limiting function.
如果在轮询（P）位设置为1的情况下接收BFD控制数据包，则接收系统必须在不考虑传输计时器或任何其他传输限制的情况下，在不考虑会话状态的情况下，尽快发送轮询（P）位已清除且最终（F）位已设置的BFD控制数据包，并且不考虑需求模式是否在任一系统上处于活动状态。系统可限制此类分组的传输速率。如果速率限制生效，则所需最小TX间隔的公布值必须大于或等于速率限制功能施加的传输数据包之间的间隔。
A system MUST NOT set the Demand (D) bit unless bfd.DemandMode is 1, bfd.SessionState is Up, and bfd.RemoteSessionState is Up.
除非bfd.DemandMode为1，bfd.SessionState为Up，且bfd.RemoteSessionState为Up，否则系统不得设置Demand（D）位。
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 and Final bits) in order to more rapidly communicate a change in state.
当BFD控制分组的内容将不同于先前发送的分组（轮询和最终比特除外）中的内容时，应在周期性控制分组传输之间的间隔期间发送BFD控制分组，以便更快速地传达状态的变化。
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 0 if not.
如果本地系统正在发送轮询序列，则设置为1，否则设置为0。
Final (F)
决赛（F）
Set to 1 if the local system is responding to a Control packet received with the Poll (P) bit set, or 0 if not.
如果本地系统响应以轮询（P）位设置接收的控制数据包，则设置为1，否则设置为0。
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 on this session (bfd.AuthType is nonzero), or 0 if not.
如果此会话上正在使用身份验证，则设置为1（bfd.AuthType为非零），否则设置为0。
Demand (D)
需求（D）
Set to bfd.DemandMode if bfd.SessionState is Up and bfd.RemoteSessionState is Up. Otherwise, it is set to 0.
如果bfd.SessionState已启动且bfd.RemoteSessionState已启动，则设置为bfd.DemandMode。否则，它将设置为0。
Multipoint (M)
多点（M）
Set to 0.
设置为0。
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 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回送数据包回送至远程系统，远程系统将不发送回送数据包。
Authentication Section
认证部分
Included and set according to the rules in section 6.7 if authentication is in use (bfd.AuthType is nonzero). Otherwise, this section is not present.
如果正在使用身份验证（bfd.AuthType为非零），则根据第6.7节中的规则包括和设置。否则，本节不存在。
A received BFD Echo packet MUST be demultiplexed to the appropriate session for processing. A means of detecting missing Echo packets MUST be implemented, which most likely involves processing of the Echo packets that are received. The processing of received Echo packets is otherwise outside the scope of this specification.
接收到的BFD回波数据包必须解复用到适当的会话进行处理。必须实现检测丢失的回波数据包的方法，这很可能涉及对接收到的回波数据包的处理。接收到的回波数据包的处理不在本规范的范围内。
BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Control packet received from the remote system contains a nonzero value in Required Min Echo RX Interval.
BFD.SessionState未启动时，不得传输BFD回送数据包。除非从远程系统接收的最后一个BFD控制数据包在要求的最小回波接收间隔内包含非零值，否则不得传输BFD回波数据包。
BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The interval between transmitted BFD Echo packets MUST NOT be less than the value advertised by the remote system in Required Min Echo RX Interval, except as follows:
当BFD.SessionState启动时，可以传输BFD回波数据包。发送的BFD回波数据包之间的间隔不得小于远程系统在要求的最小回波接收间隔内公布的值，以下情况除外：
A 25% jitter MAY be applied to the rate of transmission, such that the actual interval MAY be between 75% and 100% of the advertised value. A single BFD Echo packet MAY be transmitted between normally scheduled Echo transmission intervals.
25%的抖动可应用于传输速率，使得实际间隔可在广告值的75%到100%之间。单个BFD回波包可在正常调度的回波传输间隔之间传输。
The transmission of BFD Echo packets is otherwise outside the scope of this specification.
BFD回波数据包的传输不在本规范的范围内。
When it is desired to change the rate at which BFD Control packets arrive from the remote system, bfd.RequiredMinRxInterval can be changed at any time to any value. The new value will be transmitted in the next outgoing Control packet, and the remote system will adjust accordingly. See section 6.8.3 for further requirements.
当需要更改BFD控制数据包从远程系统到达的速率时，BFD.RequiredMinRxInterval可以随时更改为任何值。新值将在下一个传出控制数据包中传输，远程系统将进行相应调整。更多要求见第6.8.3节。
When it is desired to change the rate at which BFD Control packets are transmitted to the remote system (subject to the requirements of the neighboring system), bfd.DesiredMinTxInterval can be changed at any time to any value. The rules in section 6.8.3 apply.
当需要更改BFD控制数据包传输到远程系统的速率时（根据相邻系统的要求），BFD.DesiredMinTxInterval可以随时更改为任何值。第6.8.3节中的规则适用。
When it is desired to change the detect multiplier, the value of bfd.DetectMult can be changed to any nonzero value. The new value will be transmitted with the next BFD Control packet, and the use of a Poll Sequence is not necessary. See section 6.6 for additional requirements.
当需要更改检测乘数时，bfd.DetectMult的值可以更改为任何非零值。新值将与下一个BFD控制数据包一起传输，无需使用轮询序列。其他要求见第6.6节。
If it is desired to start or stop the transmission of BFD Echo packets, this MAY be done at any time (subject to the transmission requirements detailed in section 6.8.9).
如果需要启动或停止BFD回波数据包的传输，可在任何时候进行（根据第6.8.9节详述的传输要求）。
If it is desired to enable or disable the looping back of received BFD Echo packets, this MAY be done at any time by changing the value of Required Min Echo RX Interval to zero or nonzero in outgoing BFD Control packets.
如果需要启用或禁用接收的BFD回波数据包的环回，可随时通过将输出BFD控制数据包中所需的最小回波RX间隔值更改为零或非零来实现。
If it is desired to start or stop Demand mode, this MAY be done at any time by setting bfd.DemandMode to the proper value. Demand mode will subsequently become active under the rules described in section 6.6.
如果需要启动或停止需求模式，可通过将bfd.DemandMode设置为适当的值随时启动或停止需求模式。根据第6.6节所述规则，需求模式随后将变为激活状态。
If Demand mode is no longer active on the remote system, the local system MUST begin transmitting periodic BFD Control packets as described in section 6.8.7.
如果远程系统上的需求模式不再处于活动状态，则本地系统必须按照第6.8.7节所述开始定期发送BFD控制数据包。
When the forwarding plane in the local system is reset for some reason, such that the remote system can no longer rely on the local forwarding state, the local system MUST set bfd.LocalDiag to 4 (Forwarding Plane Reset), and set bfd.SessionState to Down.
当由于某种原因重置本地系统中的转发平面时，远程系统无法再依赖本地转发状态，本地系统必须将bfd.LocalDiag设置为4（转发平面重置），并将bfd.SessionState设置为Down。
There may be circumstances where it is desirable to administratively enable or disable a BFD session. When this is desired, the following procedure MUST be followed:
在某些情况下，可能需要以管理方式启用或禁用BFD会话。需要时，必须遵循以下程序：
If enabling session Set bfd.SessionState to Down
如果启用会话，请将bfd.SessionState设置为Down
Else Set bfd.SessionState to AdminDown Set bfd.LocalDiag to an appropriate value Cease the transmission of BFD Echo packets
否则将bfd.SessionState设置为AdminDown将bfd.LocalDiag设置为适当的值停止bfd回显数据包的传输
If signaling is received from outside BFD that the underlying path has failed, an implementation MAY administratively disable the session with the diagnostic Path Down.
如果从BFD外部接收到底层路径失败的信号，则实现可以在诊断路径关闭的情况下管理性地禁用会话。
Other scenarios MAY use the diagnostic Administratively Down.
其他场景可能会使用诊断管理关闭。
BFD Control packets SHOULD be transmitted for at least a Detection Time after transitioning to AdminDown state in order to ensure that the remote system is aware of the state change. BFD Control packets MAY be transmitted indefinitely after transitioning to AdminDown state in order to maintain session state in each system (see section 6.8.18 below).
BFD控制数据包应在转换到AdminDown状态后至少传输一段检测时间，以确保远程系统了解状态变化。在转换到AdminDown状态后，BFD控制数据包可以无限期地传输，以便在每个系统中保持会话状态（见下文第6.8.18节）。
If the path being monitored by BFD is concatenated with other paths (connected end-to-end in series), it may be desirable to propagate the indication of a failure of one of those paths across the BFD session (providing an interworking function for liveness monitoring between BFD and other technologies).
如果由BFD监控的路径与其他路径连接（端到端串联连接），则可能需要在BFD会话中传播这些路径之一的故障指示（为BFD和其他技术之间的活动性监控提供互通功能）。
Two diagnostic codes are defined for this purpose: Concatenated Path Down and Reverse Concatenated Path Down. The first propagates forward path failures (in which the concatenated path fails in the direction toward the interworking system), and the second propagates
为此定义了两个诊断代码：串联路径下降和反向串联路径下降。第一个传播前向路径故障（其中连接的路径在朝向互通系统的方向上发生故障），第二个传播
reverse path failures (in which the concatenated path fails in the direction away from the interworking system, assuming a bidirectional link).
反向路径故障（在这种情况下，串联路径在远离互通系统的方向上发生故障，假设存在双向链路）。
A system MAY signal one of these failure states by simply setting bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD session is not taken down. If Demand mode is not active on the remote system, no other action is necessary, as the diagnostic code will be carried via the periodic transmission of BFD Control packets. If Demand mode is active on the remote system (the local system is not transmitting periodic BFD Control packets), a Poll Sequence MUST be initiated to ensure that the diagnostic code is transmitted. Note that if the BFD session subsequently fails, the diagnostic code will be overwritten with a code detailing the cause of the failure. It is up to the interworking agent to perform the above procedure again, once the BFD session reaches Up state, if the propagation of the concatenated path failure is to resume.
通过简单地将bfd.LocalDiag设置为适当的诊断代码，系统可以向这些故障状态之一发送信号。请注意，BFD会话未被取下。如果远程系统上的按需模式未激活，则无需采取其他措施，因为诊断代码将通过定期传输BFD控制数据包来携带。如果远程系统上的请求模式处于激活状态（本地系统未发送定期BFD控制数据包），则必须启动轮询序列以确保发送诊断代码。注意，如果BFD会话随后失败，诊断代码将被详细说明故障原因的代码覆盖。一旦BFD会话达到up状态，如果要恢复连接路径故障的传播，则应由互通代理再次执行上述过程。
A system MAY choose to prevent a BFD session from being established. One possible reason might be to manage the rate at which sessions are established. This can be done by holding the session in Down or AdminDown state, as appropriate.
系统可以选择阻止建立BFD会话。一个可能的原因可能是管理会话建立的速率。这可以通过将会话保持在关闭或AdminDown状态（视情况而定）来实现。
There are two related mechanisms that are available to help with this task. First, a system is REQUIRED to maintain session state (including timing parameters), even when a session is down, until a Detection Time has passed without the receipt of any BFD Control packets. This means that a system may take down a session and transmit an arbitrarily large value in the Required Min RX Interval field to control the rate at which it receives packets.
有两种相关机制可用于帮助完成此任务。首先，系统需要保持会话状态（包括定时参数），即使会话已关闭，直到检测时间已过且未收到任何BFD控制数据包为止。这意味着系统可以关闭会话并在所需的最小RX间隔字段中发送任意大的值，以控制其接收数据包的速率。
Additionally, a system MAY transmit a value of zero for Required Min RX Interval to indicate that the remote system should send no packets whatsoever.
此外，系统可发送所需最小RX间隔的零值，以指示远程系统不应发送任何数据包。
So long as the local system continues to transmit BFD Control packets, the remote system is obligated to obey the value carried in Required Min RX Interval. If the remote system does not receive any BFD Control packets for a Detection Time, it SHOULD reset bfd.RemoteMinRxInterval to its initial value of 1 (per section 6.8.1, since it is no longer required to maintain previous session state) and then can transmit at its own rate.
只要本地系统继续传输BFD控制数据包，远程系统就有义务遵守所需最小接收间隔内的值。如果远程系统在一段检测时间内未收到任何BFD控制数据包，则应将BFD.RemoteMinRxInterval重置为其初始值1（根据第6.8.1节，因为不再需要保持以前的会话状态），然后可以以自己的速率进行传输。
BFD is likely to be deployed as a critical part of network infrastructure. As such, care should be taken to avoid disruption.
BFD可能被部署为网络基础设施的关键部分。因此，应注意避免中断。
Obviously, any mechanism that blocks BFD packets, such as firewalls or other policy processes, will cause BFD to fail.
显然，任何阻止BFD数据包的机制（如防火墙或其他策略进程）都会导致BFD失败。
Mechanisms that control packet scheduling, such as policers, traffic shapers, priority queueing, etc., have the potential of impacting BFD operations if the Detection Time is similar in scale to the scheduled packet transmit or receive rate. The delivery of BFD packets is time-critical, relative to the magnitude of the Detection Time, so this may need to be taken into account in implementation and deployment, particularly when very short Detection Times are to be used.
如果检测时间在规模上与调度的数据包发送或接收速率相似，则控制数据包调度的机制（如策略、流量整形器、优先级排队等）可能会影响BFD操作。相对于检测时间的大小，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. The exact mechanism used is outside the scope of this specification, and the requirements of this mechanism may differ depending on how BFD is deployed, and how it interacts with other parts of the system (for example, exponential backoff may not be appropriate in cases where routing protocols are interacting closely with BFD).
当跨多个跃点使用BFD时，必须实现拥塞控制机制，当检测到拥塞时，BFD实现必须减少其产生的流量。使用的确切机制不在本规范的范围内，该机制的要求可能因BFD的部署方式以及它与系统其他部分的交互方式而异（例如，在路由协议与BFD密切交互的情况下，指数退避可能不合适）。
Note that "congestion" is not only a traffic phenomenon, but also a computational one. It is possible for systems with a large number of BFD sessions and/or very short packet intervals to become CPU-bound. As such, a congestion control algorithm SHOULD be used even across single hops in order to avoid the possibility of catastrophic system collapse, as such failures have been seen repeatedly in other periodic Hello-based protocols.
请注意，“拥塞”不仅是一种交通现象，也是一种计算现象。具有大量BFD会话和/或非常短的数据包间隔的系统可能会受到CPU的限制。因此，即使在单跳中也应该使用拥塞控制算法，以避免灾难性系统崩溃的可能性，因为在其他基于Hello的定期协议中已经多次看到这种故障。
The mechanisms for detecting congestion are outside the scope of this specification, but may include the detection of lost BFD Control packets (by virtue of holes in the authentication sequence number space, or by BFD session failure) or other means.
用于检测拥塞的机制不在本规范的范围内，但可包括检测丢失的BFD控制分组（借助于认证序列号空间中的漏洞，或通过BFD会话失败）或其他方式。
The mechanisms for reducing BFD's traffic load are the control of the local and remote packet transmission rate via the Min RX Interval and Min TX Interval fields.
减少BFD流量负载的机制是通过Min RX Interval和Min TX Interval字段控制本地和远程数据包传输速率。
Note that any mechanism that increases the transmit or receive intervals will increase the Detection Time for the session.
请注意，任何增加发送或接收间隔的机制都会增加会话的检测时间。
It is worth noting that a single BFD session does not consume a large amount of bandwidth. An aggressive session that achieves a detection time of 50 milliseconds, by using a transmit interval of 16.7 milliseconds and a detect multiplier of 3, will generate 60 packets per second. The maximum length of each packet on the wire is on the order of 100 bytes, for a total of around 48 kilobits per second of bandwidth consumption in each direction.
值得注意的是，单个BFD会话不会消耗大量带宽。通过使用16.7毫秒的传输间隔和3的检测乘数，达到50毫秒检测时间的主动会话将每秒生成60个数据包。线路上每个数据包的最大长度约为100字节，每个方向的带宽消耗总量约为每秒48千位。
This document defines two registries administered by IANA. The first is titled "BFD Diagnostic Codes" (see section 4.1). Initial values for the BFD Diagnostic Code registry are given below. Further assignments are to be made through Expert Review [IANA-CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name and its associated value.
本文件定义了IANA管理的两个注册中心。第一个标题为“BFD诊断代码”（见第4.1节）。BFD诊断代码注册表的初始值如下所示。进一步的任务将通过专家评审[IANA-考虑因素]完成。分配由BFD诊断代码名称及其关联值组成。
Value BFD Diagnostic Code Name
----- ------------------------
0 No Diagnostic
1 Control Detection Time Expired
2 Echo Function Failed
3 Neighbor Signaled Session Down
4 Forwarding Plane Reset
5 Path Down
6 Concatenated Path Down
7 Administratively Down
8 Reverse Concatenated Path Down
9-31 Unassigned
Value BFD Diagnostic Code Name
----- ------------------------
0 No Diagnostic
1 Control Detection Time Expired
2 Echo Function Failed
3 Neighbor Signaled Session Down
4 Forwarding Plane Reset
5 Path Down
6 Concatenated Path Down
7 Administratively Down
8 Reverse Concatenated Path Down
9-31 Unassigned
The second registry is titled "BFD Authentication Types" (see section 4.1). Initial values for the BFD Authentication Type registry are given below. Further assignments are to be made through Expert Review [IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type Code name and its associated value.
第二个注册表名为“BFD身份验证类型”（见第4.1节）。BFD身份验证类型注册表的初始值如下所示。进一步的任务将通过专家评审[IANA-考虑因素]完成。分配由BFD身份验证类型代码名及其关联值组成。
Value BFD Authentication Type Name
----- ----------------------------
0 Reserved
1 Simple Password
2 Keyed MD5
3 Meticulous Keyed MD5
4 Keyed SHA1
5 Meticulous Keyed SHA1
6-255 Unassigned
Value BFD Authentication Type Name
----- ----------------------------
0 Reserved
1 Simple Password
2 Keyed MD5
3 Meticulous Keyed MD5
4 Keyed SHA1
5 Meticulous Keyed SHA1
6-255 Unassigned
As BFD may be tied into the stability of the network infrastructure (such as routing protocols), the effects of an attack on a BFD session may be very serious: a link may be falsely declared to be down, or falsely declared to be up; in either case, the effect is denial of service.
由于BFD可能与网络基础设施（如路由协议）的稳定性有关，攻击BFD会话的影响可能非常严重：链路可能被错误地宣布为关闭，或被错误地宣布为打开；在任何一种情况下，其后果都是拒绝服务。
An attacker who is in complete control of the link between the systems can easily drop all BFD packets but forward everything else (causing the link to be falsely declared down), or forward only the BFD packets but nothing else (causing the link to be falsely declared up). This attack cannot be prevented by BFD.
完全控制系统间链路的攻击者可以轻松丢弃所有BFD数据包，但转发其他所有数据包（导致链路错误声明为关闭），或仅转发BFD数据包，而不转发其他数据包（导致链路错误声明为关闭）。BFD无法阻止此攻击。
To mitigate threats from less capable attackers, BFD specifies two mechanisms to prevent spoofing of BFD Control packets. The Generalized TTL Security Mechanism [GTSM] uses the time to live (TTL) or Hop Count to prevent off-link attackers from spoofing packets. The Authentication Section authenticates the BFD Control packets. These mechanisms are described in more detail below.
为了减轻能力较差的攻击者的威胁，BFD指定了两种机制来防止对BFD控制数据包的欺骗。通用TTL安全机制[GTSM]使用生存时间（TTL）或跳数来防止断开链路的攻击者欺骗数据包。身份验证部分对BFD控制数据包进行身份验证。下面将更详细地描述这些机制。
When a BFD session is directly connected across a single link (physical, or a secure tunnel such as IPsec), the TTL or Hop Count MUST be set to the maximum on transmit, and checked to be equal to the maximum value on reception (and the packet dropped if this is not the case). See [GTSM] for more information on this technique. If BFD is run across multiple hops or an insecure tunnel (such as Generic Routing Encapsulation (GRE)), the Authentication Section SHOULD be utilized.
当BFD会话通过单个链路（物理链路或安全隧道，如IPsec）直接连接时，TTL或跃点计数必须在传输时设置为最大值，并在接收时检查为等于最大值（如果不是这种情况，则丢弃数据包）。有关此技术的更多信息，请参见[GTSM]。如果BFD跨多个跃点或不安全的隧道运行（如通用路由封装（GRE）），则应使用身份验证部分。
The level of security provided by the Authentication Section varies based on the authentication type used. Simple Password authentication is obviously only as secure as the secrecy of the passwords used, and should be considered only if the BFD session is guaranteed to be run over an infrastructure not subject to packet interception. Its chief advantage is that it minimizes the computational effort required for authentication.
身份验证部分提供的安全级别根据所使用的身份验证类型而有所不同。简单密码身份验证显然只与所用密码的保密性一样安全，并且只有在保证BFD会话在不受数据包截获的基础设施上运行时，才应考虑使用简单密码身份验证。它的主要优点是将身份验证所需的计算工作量降至最低。
Keyed MD5 Authentication is much stronger than Simple Password Authentication since the keys cannot be discerned by intercepting packets. It is vulnerable to replay attacks in between increments of the sequence number. The sequence number can be incremented as seldom (or as often) as desired, trading off resistance to replay attacks with the computational effort required for authentication.
密钥MD5身份验证比简单的密码身份验证强得多，因为通过拦截数据包无法识别密钥。它很容易受到序列号增量之间的重播攻击。序列号可以根据需要很少（或经常）增加，以抵抗重播攻击和验证所需的计算工作量来权衡。
Meticulous Keyed MD5 authentication is stronger yet, as it requires the sequence number to be incremented for every packet. Replay attack vulnerability is reduced due to the requirement that the
细致的键控MD5身份验证更强大，因为它要求每个数据包的序列号都增加。由于要求
sequence number must be incremented on every packet, the window size of acceptable packets is small, and the initial sequence number is randomized. There is still a window of attack at the beginning of the session while the sequence number is being determined. This authentication scheme requires an MD5 calculation on every packet transmitted and received.
序列号必须在每个数据包上递增，可接受数据包的窗口大小较小，初始序列号随机化。在确定序列号时，会话开始时仍有一个攻击窗口。此身份验证方案要求对发送和接收的每个数据包进行MD5计算。
Using SHA1 is believed to have stronger security properties than MD5. All comments about MD5 in this section also apply to SHA1.
使用SHA1被认为比MD5具有更强的安全性。本节中关于MD5的所有评论也适用于SHA1。
Both Keyed MD5/SHA1 and Meticulous Keyed MD5/SHA1 use the "secret suffix" construction (also called "append only") in which the shared secret key is appended to the data before calculating the hash, instead of the more common Hashed Message Authentication Code (HMAC) construction [HMAC]. This construction is believed to be appropriate for BFD, but designers of any additional authentication mechanisms for BFD are encouraged to read [HMAC] and its references.
键控MD5/SHA1和精细键控MD5/SHA1都使用“秘密后缀”构造（也称为“仅附加”），其中在计算散列之前将共享密钥附加到数据，而不是更常见的散列消息认证码（HMAC）构造[HMAC]。这种结构被认为适用于BFD，但鼓励BFD任何附加认证机制的设计者阅读[HMAC]及其参考文献。
If both systems randomize their Local Discriminator values at the beginning of a session, replay attacks may be further mitigated, regardless of the authentication type in use. Since the Local Discriminator may be changed at any time during a session, this mechanism may also help mitigate attacks.
如果两个系统在会话开始时随机化其本地鉴别器值，则无论使用何种身份验证类型，都可以进一步减轻重播攻击。由于本地鉴别器可以在会话期间的任何时间更改，因此该机制还可以帮助减轻攻击。
The security implications of the use of BFD Echo packets are dependent on how those packets are defined, since their structure is local to the transmitting system and outside the scope of this specification. However, since Echo packets are defined and processed only by the transmitting system, the use of cryptographic authentication does not guarantee that the other system is actually alive; an attacker could loop the Echo packets back (without knowing any secret keys) and cause the link to be falsely declared to be up. This can be mitigated by using a suitable interval for BFD Control packets. [GTSM] could be applied to BFD Echo packets, though the TTL/Hop Count will be decremented by 1 in the course of echoing the packet, so spoofing is possible from one hop away.
使用BFD回波数据包的安全含义取决于这些数据包的定义方式，因为它们的结构是传输系统的局部结构，不在本规范的范围内。然而，由于回波数据包仅由传输系统定义和处理，因此密码认证的使用并不保证另一个系统实际上是活动的；攻击者可以在不知道任何密钥的情况下将回显数据包循环回来，并导致错误地声明链接已启动。这可以通过为BFD控制数据包使用合适的间隔来缓解。[GTSM]可应用于BFD回送数据包，但在回送数据包的过程中，TTL/跃点计数将减少1，因此可以从一个跃点之外进行欺骗。
[GTSM] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[GTSM]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[SHA1]Eastlake 3rd，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 31742001年9月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA注意事项]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
Appendix A. Backward Compatibility (Non-Normative)
附录A.向后兼容性（非规范性）
Although version 0 of this protocol (as defined in early versions of the Internet-Draft that became this RFC) is unlikely to have been deployed widely, some implementors may wish to have a backward compatibility mechanism. Note that any mechanism may be potentially used that does not alter the protocol definition, so interoperability should not be an issue.
尽管此协议的版本0（如成为此RFC的Internet草案的早期版本中所定义）不太可能广泛部署，但一些实现者可能希望具有向后兼容机制。请注意，可能会使用任何不会改变协议定义的机制，因此互操作性不应成为问题。
The suggested mechanism described here has the property that it will converge on version 1 if both systems implement it, even if one system is upgraded from version 0 within a Detection Time. It will interoperate with a system that implements only one version (or is configured to support only one version). A system should obviously not perform this function if it is configured to or is only capable of using a single version.
此处描述的建议机制具有这样的属性：如果两个系统都实现了它，那么它将收敛到版本1，即使一个系统在检测时间内从版本0升级。它将与只实现一个版本（或配置为只支持一个版本）的系统进行互操作。如果系统配置为或只能使用单一版本，则系统显然不应执行此功能。
A BFD session will enter a "negotiation holddown" if it is configured for automatic versioning and either has just started up, or the session has been manually cleared. The session is set to AdminDown state and version 1. During the holddown period, which lasts for one Detection Time, the system sends BFD Control packets as usual, but ignores received packets. After the holddown time is complete, the state transitions to Down and normal operation resumes.
如果BFD会话配置为自动版本控制，并且刚刚启动，或者会话已手动清除，则BFD会话将进入“协商抑制”。会话设置为AdminDown状态和版本1。在持续一次检测的抑制期间，系统像往常一样发送BFD控制数据包，但忽略接收到的数据包。按住时间完成后，状态转换为向下，恢复正常操作。
When a system is not in holddown, if it doing automatic versioning and is currently using version 1, if any version 0 packet is received for the session, it switches immediately to version 0. If it is currently using version 0 and a version 1 packet is received that indicates that the neighbor is in state AdminDown, it switches to version 1. If using version 0 and a version 1 packet is received indicating a state other than AdminDown, the packet is ignored (per spec).
当系统未处于搁置状态时，如果系统正在执行自动版本控制并且当前正在使用版本1，则如果会话收到任何版本0数据包，则系统将立即切换到版本0。如果它当前正在使用版本0，并且收到一个表示邻居处于AdminDown状态的版本1数据包，它将切换到版本1。如果使用版本0并收到表示AdminDown以外状态的版本1数据包，则忽略该数据包（根据规范）。
If the version being used is changed, the session goes down as appropriate for the new version (Down state for version 1 or Failing state for version 0).
如果正在使用的版本已更改，则会话将根据新版本的情况关闭（版本1处于关闭状态，版本0处于失败状态）。
Kireeti Kompella and Yakov Rekhter of Juniper Networks were also significant contributors to this document.
Juniper Networks的Kireeti Kompella和Yakov Rekhter也是本文件的重要贡献者。
This document was inspired by (and is intended to replace) the Protocol Liveness Protocol document, written by Kireeti Kompella.
本文件受Kireeti Kompella编写的协议活性协议文件的启发（并打算取代该文件）。
Demand mode was inspired by "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", by G. Huang, et al.
需求模式的灵感来源于G.Huang等人的“基于流量的检测死掉的互联网密钥交换（IKE）对等点的方法”。
The authors would also like to thank Mike Shand, John Scudder, Stewart Bryant, Pekka Savola, Richard Spencer, and Pasi Eronen for their substantive input.
作者还要感谢迈克·山德、约翰·斯卡德尔、斯图尔特·布莱恩特、佩卡·萨沃拉、理查德·斯宾塞和帕西·埃隆的大量投入。
The authors would also like to thank Owen Wheeler for hosting teleconferences between the authors of this specification and multiple vendors in order address implementation and clarity issues.
作者还要感谢Owen Wheeler主持本规范作者与多家供应商之间的电话会议，以解决实现和清晰性问题。
Authors' Addresses
作者地址
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
Dave Katz Juniper Networks美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089-1206
Phone: +1-408-745-2000
EMail: dkatz@juniper.net
Phone: +1-408-745-2000
EMail: dkatz@juniper.net
Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
Dave Ward Juniper Networks美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号，邮编94089-1206
Phone: +1-408-745-2000
EMail: dward@juniper.net
Phone: +1-408-745-2000
EMail: dward@juniper.net