Internet Engineering Task Force (IETF) N. Akiya
Request for Comments: 7419 M. Binderberger
Updates: 5880 Cisco Systems
Category: Informational G. Mirsky
ISSN: 2070-1721 Ericsson
December 2014
Internet Engineering Task Force (IETF) N. Akiya
Request for Comments: 7419 M. Binderberger
Updates: 5880 Cisco Systems
Category: Informational G. Mirsky
ISSN: 2070-1721 Ericsson
December 2014
Common Interval Support in Bidirectional Forwarding Detection
双向转发检测中的公共间隔支持
Abstract
摘要
Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions.
双向转发检测（BFD）要求以固定的间隔发送消息，并提供一种协商BFD对等方使用的间隔的方法。某些BFD实现可能被限制为仅支持几个间隔值。当此类BFD实现相互对话时，双方可能无法找到运行BFD会话的间隔的公共值。
This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals.
本文档通过为BFD定义一组小的间隔值（我们称之为“公共间隔”）来更新RFC 5880，并推荐支持已定义间隔的实现。这解决了查找两个BFD扬声器都可以支持的间隔值的问题，同时允许简化实现，如基于硬件的BFD所示。它不限制一个实现在公共间隔之外支持更多的间隔。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7419.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7419.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Problem with Few Supported Intervals . . . . . . . . . . 3
3. Well-Defined, Common Intervals . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Why Some Values Are in the Common Interval Set . . . 6
Appendix B. Timer Adjustment with Non-identical Interval Sets . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Problem with Few Supported Intervals . . . . . . . . . . 3
3. Well-Defined, Common Intervals . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Why Some Values Are in the Common Interval Set . . . 6
Appendix B. Timer Adjustment with Non-identical Interval Sets . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
The Bidirectional Forwarding Detection (BFD) standard [RFC5880] describes how to calculate the transmission interval and the detection time. However, it does not make any statement about how to solve a situation where one BFD speaker cannot support the calculated value. In practice, this may not have been a problem as long as software-implemented timers were used and as long as the granularity of such timers was small compared to the interval values being supported, i.e. as long as the error in the timer interval was small compared to 25 percent jitter.
双向转发检测（BFD）标准[RFC5880]描述了如何计算传输间隔和检测时间。但是，它没有说明如何解决一个BFD演讲者无法支持计算值的情况。在实践中，只要使用了软件实现的计时器，并且与所支持的间隔值相比，此类计时器的粒度较小，即，只要与25%的抖动相比，计时器间隔中的误差较小，则这可能不是问题。
In the meantime, requests exist for very fast interval values, down to 3.3 msec for the MPLS Transport Profile (MPLS-TP). At the same time, the requested scale for the number of BFD sessions is increasing. Both requirements have driven vendors to use Network Processors (NP), Field Programmable Gate Arrays (FPGAs), or other hardware-based solutions to offload the periodic packet transmission and the timeout detection in the receive direction. A potential
同时，存在对非常快的间隔值的请求，对于MPLS传输配置文件（MPLS-TP），该间隔值低至3.3毫秒。同时，请求的BFD会话数量规模正在增加。这两项要求促使供应商使用网络处理器（NP）、现场可编程门阵列（FPGA）或其他基于硬件的解决方案来卸载接收方向上的定期数据包传输和超时检测。潜力
problem with this hardware-based BFD is the granularity of the interval timers. Depending on the implementation, only a few intervals may be supported, which can cause interoperability problems. This document proposes a set of interval values that should be supported by all implementations. Details are laid out in the following sections.
这种基于硬件的BFD的问题是间隔计时器的粒度。根据实现的不同，可能只支持几个间隔，这可能会导致互操作性问题。本文档提出了一组所有实现都应支持的间隔值。以下各节列出了详细信息。
Let's assume vendor "A" supports 10 msec, 100 msec, and 1 sec interval timers in hardware, and vendor "B" supports every value from 20 msec onward, with a granularity of 1 msec. For a BFD session, "A" tries to set up the session with 10 msec while "B" uses 20 msec as the value for RequiredMinRxInterval and DesiredMinTxInterval. Rx and Tx are negotiated as described in [RFC5880], which is 20 msec in this case. However, system "A" is not able to support the 20 msec interval timer. Multiple ways exist to resolve the dilemma, but none of them is without problems.
假设供应商“A”支持硬件中的10毫秒、100毫秒和1秒间隔计时器，供应商“B”支持从20毫秒开始的每个值，粒度为1毫秒。对于BFD会话，“a”尝试将会话设置为10毫秒，而“B”使用20毫秒作为RequiredMinRxInterval和DesiredMinTxInterval的值。按照[RFC5880]中所述协商Rx和Tx，在这种情况下为20毫秒。但是，系统“A”无法支持20毫秒间隔计时器。解决这一困境的方法多种多样，但没有一种是没有问题的。
a. Realizing that it cannot support 20 msec, system "A" sends out a new BFD packet advertising the next larger interval of 100 msec with RequiredMinRxInterval and DesiredMinTxInterval. The new negotiated interval between "A" and "B" is then 100 msec, which is supported by both systems. However, the problem is that we moved from the 10/20 msec range to 100 msec, which has far deviated from operator expectations.
a. 意识到它不能支持20毫秒，系统“A”发送一个新的BFD数据包，用RequiredMinRxInterval和DesiredMinTxInterval在下一个更大的100毫秒间隔内进行广告。“A”和“B”之间的新协商间隔为100毫秒，这两个系统都支持。然而，问题是我们从10/20毫秒的范围移动到了100毫秒，这与运营商的预期相差甚远。
b. System "A" could violate [RFC5880] and use the 10 msec interval for the Tx direction. In the receive direction, it could use an adjusted multiplier value M' = 2 * M to match the correct detection time. Now, in addition to the fact that we explicitly violate [RFC5880], there may be the problem that system "B" drops up to 50% of the packets; this could be the case when "B" uses an ingress rate policer to protect itself and the policer would be programmed with an expectation of 20 msec receive intervals.
b. 系统“A”可能违反[RFC5880]，并在发送方向上使用10毫秒的间隔。在接收方向，它可以使用调整后的乘数值M'=2*M来匹配正确的检测时间。现在，除了我们明确违反[RFC5880]的事实之外，还可能存在系统“B”丢弃高达50%的数据包的问题；当“B”使用入口速率策略来保护自身，并且该策略将以20毫秒的预期接收间隔进行编程时，可能会出现这种情况。
The example above could be worse when we assume that system "B" can only support a few timer values itself. Let's assume "B" supports 20 msec, 300 msec, and 1 sec. If both systems would adjust their advertised intervals, then the adjustment ends at 1 sec. The example above could even be worse when we assume that system "B" can only support 50 msec, 500 msec, and 2 sec. Even if both systems walk through all of their supported intervals, the two systems will never be able to agree on an interval to run any BFD sessions.
当我们假设系统“B”本身只能支持几个计时器值时，上面的示例可能会更糟。假设“B”支持20毫秒、300毫秒和1秒。如果两个系统都将调整其公布的间隔，则调整将在1秒后结束。当我们假设系统“B”只能支持50毫秒、500毫秒和2秒时，上面的例子可能更糟。即使两个系统都经过了所有支持的时间间隔，两个系统也永远无法就运行任何BFD会话的时间间隔达成一致。
The problem can be reduced by defining interval values that are supported by all implementations. Then, the adjustment mechanism could find a commonly supported interval without deviating too much from the original request.
通过定义所有实现都支持的间隔值，可以减少该问题。然后，调整机制可以找到一个共同支持的间隔，而不会偏离原始请求太多。
In technical terms, the requirement is as follows: a BFD implementation should support all values in the set of Common Interval values that are equal to or larger than the fastest (i.e., lowest) interval the particular BFD implementation supports.
在技术方面，要求如下：BFD实现应支持公共间隔值集合中的所有值，这些值等于或大于特定BFD实现支持的最快（即最低）间隔。
This document defines the set of Common Interval values to be: 3.3 msec, 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec.
本文档将公共间隔值集定义为：3.3毫秒、10毫秒、20毫秒、50毫秒、100毫秒和1秒。
In addition, both a 10 sec interval and multiplier values up to 255 are recommended to support graceful restart.
此外，建议10秒间隔和最大255的乘数值都支持正常重启。
The adjustment is always towards larger (i.e., slower) interval values when the initial interval proposed by the peer is not supported.
当对等方提出的初始间隔不受支持时，调整总是朝着更大（即较慢）的间隔值进行。
This document is not adding new requirements with respect to the precision with which a timer value must be implemented. Supporting an interval value means advertising this value in the DesiredMinTxInterval and/or RequiredMinRxInterval field of the BFD packets and providing timers that are reasonably close. [RFC5880] defines safety margins for the timers by defining a jitter range.
本文件并未增加有关计时器值必须实现的精度的新要求。支持间隔值意味着在BFD数据包的DesiredMinxinterval和/或RequiredMinRxInterval字段中公布该值，并提供合理接近的计时器。[RFC5880]通过定义抖动范围来定义计时器的安全裕度。
How is the Common Interval set used exactly? In the example above, vendor "A" has a fastest interval of 10 msec and thus would be required to support all intervals in the Common Interval set that are equal or larger than 10 msec, i.e., it would support 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec. Vendor "B" has a fastest interval of 20 msec and thus would need to support 20 msec, 50 msec, 100 msec, and 1 sec. As long as this requirement is met for the common set of values, then both vendor "A" and "B" are free to support additional values outside of the Common Interval set.
如何准确地使用公共间隔集？在上面的示例中，供应商“A”具有10毫秒的最快间隔，因此需要支持公共间隔集中等于或大于10毫秒的所有间隔，即，它将支持10毫秒、20毫秒、50毫秒、100毫秒和1秒。供应商“B”的最快间隔为20毫秒，因此需要支持20毫秒、50毫秒、100毫秒和1秒。只要通用值集满足此要求，那么供应商“A”和“B”都可以自由支持通用间隔集之外的其他值。
This document does not introduce any additional security concerns. The security considerations described in the BFD documents, [RFC5880] and others, apply to devices implementing the BFD protocol, regardless of whether or not the Common Interval set is implemented.
本文件不涉及任何其他安全问题。BFD文件[RFC5880]和其他文件中描述的安全注意事项适用于实现BFD协议的设备，无论是否实现了公共间隔集。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月<http://www.rfc-editor.org/info/rfc5880>.
[G.8013_Y.1731] International Telecommunications Union, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, November 2013.
[G.8013_Y.1731]国际电信联盟，“基于以太网的网络的OAM功能和机制”，ITU-T建议G.8013/Y.17311913年11月。
[GR-253-CORE] Telcordia Technologies, Inc., "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria", GR-253-CORE Issue 05, October 2009.
[GR-253-CORE]Telcordia Technologies，Inc.“同步光网络（SONET）传输系统：通用标准”，GR-253-CORE第05期，2009年10月。
The list of Common Interval values is trying to balance various objectives. The list should not contain too many values, as more timers may increase the implementation costs. On the other hand, fewer values produces larger gaps and adjustment jumps. More values in the lower interval range are thus seen as critical to support customer needs for fast detection in setups with multiple vendors.
常用区间值列表试图平衡各种目标。列表不应该包含太多的值，因为更多的计时器可能会增加实现成本。另一方面，值越小，间隙和调整跳跃越大。因此，较低间隔范围内的更多值对于支持客户在多个供应商的设置中快速检测的需求至关重要。
o 3.3 msec: required by MPLS-TP, to support the defect detection time of 10 msec from [GR-253-CORE].
o 3.3毫秒：MPLS-TP要求，以支持[GR-253-CORE]10毫秒的缺陷检测时间。
o 10 msec: general consensus is to support 10 msec. Multiple vendors plan to or do already implement 10 msec.
o 10毫秒：普遍共识是支持10毫秒。多个供应商计划或已经实施10毫秒。
o 20 msec: basically avoids a larger gap in this critical interval region. Still allows 50-60 msec detect and restore (with multiplier of 2) and covers existing software-based implementations.
o 20毫秒：基本上避免了该临界间隔区域中的较大间隙。仍然允许50-60毫秒的检测和恢复（乘数为2），并涵盖现有的基于软件的实现。
o 50 msec: widely deployed interval. Supporting this value reflects the reality of many BFD implementations today.
o 50毫秒：广泛部署的间隔。支持此值反映了当今许多BFD实现的现实。
o 100 msec: similar to 10 msec, this value allows the reuse of [G.8013_Y.1731] implementations, especially hardware. It supports a large number of 100 msec sessions with multiplier 9 (9 x 100 msec), which could be replacing of 3 x 300 msec configurations used by customers to have a detection time slightly below 1 sec for VoIP setups.
o 100毫秒：与10毫秒类似，此值允许重用[G.8013_Y.1731]实现，尤其是硬件。它支持大量使用乘法器9（9 x 100毫秒）的100毫秒会话，可以取代客户使用的3 x 300毫秒配置，使VoIP设置的检测时间略低于1秒。
o 1 sec: as mentioned in [RFC5880]. While the interval for Down packets can be 1 sec or larger, this document recommends use of exactly 1 sec to avoid interoperability issues.
o 1秒：如[RFC5880]所述。虽然下行数据包的间隔可以是1秒或更大，但本文档建议使用1秒来避免互操作性问题。
The recommended value for large intervals is 10 sec, allowing for a timeout of 42.5 minutes with a multiplier of 255. This value is kept outside the Common Interval set, as it is not required for normal BFD operations that occur in the sub-second range. Instead, the expected usage is for graceful restart, if needed.
大间隔的建议值为10秒，允许超时42.5分钟，乘数为255。该值保持在公共间隔设置之外，因为在亚秒范围内发生的正常BFD操作不需要该值。相反，如果需要的话，预期的用途是优雅地重新启动。
[RFC5880] implicitly assumes that a BFD implementation can support any timer value equal to or above the advertised value. When a BFD speaker starts a Poll Sequence, then the peer must reply with the Final (F) bit set and adjust the transmit and detection timers accordingly. With contiguous software-based timers, this is a valid assumption. Even in the case of a small number of supported interval
[RFC5880]隐式假设BFD实现可以支持等于或高于公布值的任何计时器值。当BFD扬声器启动轮询序列时，对等方必须使用设置的最终（F）位进行应答，并相应地调整发送和检测计时器。对于连续的基于软件的计时器，这是一个有效的假设。即使在支持的间隔数很少的情况下
values, this assumption holds when both BFD speakers support exactly the same interval values.
值，当两个BFD扬声器支持完全相同的间隔值时，此假设成立。
But what happens when both speakers support intervals that are not supported by the peer? An example is router "A" supporting the Common Interval set plus 200 msec, while router "B" supports the Common Intervals plus 300 msec. Assume both routers are configured and run at 50 msec. Now, router A is configured for 200 msec. We know the result must be that both BFD speakers use 1 sec timers, but how do they reach this endpoint?
但是，如果两个发言者都支持对方不支持的间隔，会发生什么情况呢？例如，路由器“A”支持公共间隔集加200毫秒，而路由器“B”支持公共间隔加300毫秒。假设两个路由器都已配置并以50毫秒的速度运行。现在，路由器A被配置为200毫秒。我们知道结果一定是两个BFD扬声器都使用1秒定时器，但它们是如何达到这个终点的？
First, router A sends a packet with 200 msec. The P bit is set according to [RFC5880]. The Tx timer stays at 50 msec, the detection timer is 3 * 200 msec:
首先，路由器A发送一个200毫秒的数据包。根据[RFC5880]设置P位。Tx定时器保持在50毫秒，检测定时器为3*200毫秒：
(A) DesiredTx: 200 msec, MinimumRx: 200 msec, P-bit
Tx: 50 msec, Detect: 3 * 200 msec
(A) DesiredTx: 200 msec, MinimumRx: 200 msec, P-bit
Tx: 50 msec, Detect: 3 * 200 msec
Router B now must reply with an F bit. The problem is B is confirming timer values that it cannot support. The only setting to avoid a session flap would be
路由器B现在必须用F位应答。问题是B正在确认它无法支持的计时器值。避免会话抖动的唯一设置是
(B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
Tx: 50 msec, Detect: 3 * 300 msec
(B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
Tx: 50 msec, Detect: 3 * 300 msec
immediately followed by a P-bit packet, as the advertised timer values have been changed:
紧接着是一个P位数据包，因为公布的计时器值已更改：
(B) DesiredTx: 300 msec, MinimumRx: 300 msec, P-bit
Tx: 50 msec, Detect: 3 * 300 msec
(B) DesiredTx: 300 msec, MinimumRx: 300 msec, P-bit
Tx: 50 msec, Detect: 3 * 300 msec
This is not exactly what Section 6.8.7 of [RFC5880] states about the transmission rate. On the other hand, as we will see, this state does not last for long. Router A would adjust its timers based on the received Final bit:
这并不完全是[RFC5880]第6.8.7节中关于传输速率的规定。另一方面，正如我们将看到的，这种状态不会持续很久。路由器A将根据接收到的最终位调整其计时器：
(A) Tx: 200 msec, Detect: 3 * 1 sec
(A) Tx: 200 msec, Detect: 3 * 1 sec
Router A is not supporting the proposed 300 msec and would use 1 sec instead for the detection time. It would then respond to the received Poll Sequence from router B using 1 sec, as router A does not support the Max(200 msec, 300 msec):
路由器A不支持建议的300毫秒，将使用1秒来代替检测时间。由于路由器A不支持最大值（200毫秒、300毫秒），因此它将使用1秒时间响应从路由器B接收到的轮询序列：
(A) DesiredTx: 1 sec, MinimumRx: 1 sec, F-bit
Tx: 200 msec, Detect: 3 * 1 sec
(A) DesiredTx: 1 sec, MinimumRx: 1 sec, F-bit
Tx: 200 msec, Detect: 3 * 1 sec
followed by its own Poll Sequence, as the advertised timer values have been changed:
随后是其自己的轮询序列，因为播发的计时器值已更改：
(A) DesiredTx: 1 sec, MinimumRx: 1 sec, P-bit
Tx: 200 msec, Detect: 3 * 1 sec
(A) DesiredTx: 1 sec, MinimumRx: 1 sec, P-bit
Tx: 200 msec, Detect: 3 * 1 sec
Router B would adjust its timers based on the received Final bit
路由器B将根据接收到的最终位调整其定时器
(B) Tx: 300 msec , Detect: 3 * 1 sec
(B) Tx: 300 msec , Detect: 3 * 1 sec
and would then reply to the Poll Sequence from router A:
然后从路由器A回复轮询序列：
(B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
Tx: 1 sec, Detect: 3 * 1 sec
(B) DesiredTx: 300 msec, MinimumRx: 300 msec, F-bit
Tx: 1 sec, Detect: 3 * 1 sec
which finally makes router A adjust its timers:
这最终使路由器A调整其计时器：
(A) Tx: 1 sec, Detect: 3 * 1 sec
(A) Tx: 1 sec, Detect: 3 * 1 sec
In other words, router A and B go through multiple Poll Sequences until they reach a commonly supported interval value. Reaching such a value is guaranteed by this document.
换句话说，路由器A和B通过多个轮询序列，直到它们达到通常支持的间隔值。本文件保证达到该值。
Acknowledgments
致谢
We would like to thank Sylvain Masse and Anca Zamfir for bringing up the discussion about the Poll Sequence, and Jeffrey Haas for helping find the fine line between "exact" and "pedantic".
我们要感谢Sylvain Masse和Anca Zamfir提出了关于投票顺序的讨论，感谢Jeffrey Haas帮助我们找到了“精确”和“迂腐”之间的细微差别。
Authors' Addresses
作者地址
Nobo Akiya Cisco Systems
Nobo Akiya思科系统公司
EMail: nobo@cisco.com
EMail: nobo@cisco.com
Marc Binderberger Cisco Systems
Marc Binderberger思科系统公司
EMail: mbinderb@cisco.com
EMail: mbinderb@cisco.com
Greg Mirsky Ericsson
格雷格·米尔斯基·爱立信
EMail: gregory.mirsky@ericsson.com
EMail: gregory.mirsky@ericsson.com