Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5882 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5882 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010
Generic Application of Bidirectional Forwarding Detection (BFD)
双向转发检测（BFD）的一般应用
Abstract
摘要
This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol.
本文档描述了双向转发检测（BFD）协议的一般应用。
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/rfc5882.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5882.
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 ..........................3
2. Overview ........................................................3
3. Basic Interaction between BFD Sessions and Clients ..............4
3.1. Session State Hysteresis ...................................4
3.2. AdminDown State ............................................5
3.3. Hitless Establishment/Reestablishment of BFD State .........5
4. Control Protocol Interactions ...................................6
4.1. Adjacency Establishment ....................................6
4.2. Reaction to BFD Session State Changes ......................7
4.2.1. Control Protocols with a Single Data Protocol .......7
4.2.2. Control Protocols with Multiple Data Protocols ......8
4.3. Interactions with Graceful Restart Mechanisms ..............8
4.3.1. BFD Fate Independent of the Control Plane ...........9
4.3.2. BFD Shares Fate with the Control Plane ..............9
4.4. Interactions with Multiple Control Protocols ..............10
5. Interactions with Non-Protocol Functions .......................10
6. Data Protocols and Demultiplexing ..............................11
7. Multiple Link Subnetworks ......................................11
7.1. Complete Decoupling .......................................12
7.2. Layer N-1 Hints ...........................................12
7.3. Aggregating BFD Sessions ..................................12
7.4. Combinations of Scenarios .................................12
8. Other Application Issues .......................................13
9. Interoperability Issues ........................................13
10. Specific Protocol Interactions (Non-Normative) ................13
10.1. BFD Interactions with OSPFv2, OSPFv3, and IS-IS ..........14
10.1.1. Session Establishment .............................14
10.1.2. Reaction to BFD State Changes .....................14
10.1.3. OSPF Virtual Links ................................15
10.2. Interactions with BGP ....................................15
10.3. Interactions with RIP ....................................15
11. Security Considerations .......................................16
12. References ....................................................16
12.1. Normative References .....................................16
12.2. Informative References ...................................16
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Overview ........................................................3
3. Basic Interaction between BFD Sessions and Clients ..............4
3.1. Session State Hysteresis ...................................4
3.2. AdminDown State ............................................5
3.3. Hitless Establishment/Reestablishment of BFD State .........5
4. Control Protocol Interactions ...................................6
4.1. Adjacency Establishment ....................................6
4.2. Reaction to BFD Session State Changes ......................7
4.2.1. Control Protocols with a Single Data Protocol .......7
4.2.2. Control Protocols with Multiple Data Protocols ......8
4.3. Interactions with Graceful Restart Mechanisms ..............8
4.3.1. BFD Fate Independent of the Control Plane ...........9
4.3.2. BFD Shares Fate with the Control Plane ..............9
4.4. Interactions with Multiple Control Protocols ..............10
5. Interactions with Non-Protocol Functions .......................10
6. Data Protocols and Demultiplexing ..............................11
7. Multiple Link Subnetworks ......................................11
7.1. Complete Decoupling .......................................12
7.2. Layer N-1 Hints ...........................................12
7.3. Aggregating BFD Sessions ..................................12
7.4. Combinations of Scenarios .................................12
8. Other Application Issues .......................................13
9. Interoperability Issues ........................................13
10. Specific Protocol Interactions (Non-Normative) ................13
10.1. BFD Interactions with OSPFv2, OSPFv3, and IS-IS ..........14
10.1.1. Session Establishment .............................14
10.1.2. Reaction to BFD State Changes .....................14
10.1.3. OSPF Virtual Links ................................15
10.2. Interactions with BGP ....................................15
10.3. Interactions with RIP ....................................15
11. Security Considerations .......................................16
12. References ....................................................16
12.1. Normative References .....................................16
12.2. Informative References ...................................16
The Bidirectional Forwarding Detection [BFD] protocol provides a liveness detection mechanism that can be utilized by other network components for which their integral liveness mechanisms are either too slow, inappropriate, or nonexistent. Other documents have detailed the use of BFD with specific encapsulations ([BFD-1HOP] [BFD-MULTI] [BFD-MPLS]). As the utility of BFD has become understood, there have been calls to specify BFD interactions with a growing list of network functions. Rather than producing a long series of short documents on the application of BFD, it seemed worthwhile to describe the interactions between BFD and other network functions ("BFD clients") in a broad way.
双向转发检测[BFD]协议提供了一种活跃度检测机制，其他网络组件可以利用该机制，因为它们的整体活跃度机制太慢、不合适或不存在。其他文件详细说明了带特定封装的BFD的使用（[BFD-1HOP][BFD-MULTI][BFD-MPLS]）。随着人们对BFD的实用性的理解，越来越多的网络功能要求指定BFD交互。与其制作一长串关于BFD应用的简短文档，不如广泛地描述BFD与其他网络功能（“BFD客户端”）之间的交互。
This document describes the generic application of BFD. Specific protocol applications are provided for illustrative purposes.
本文件描述了BFD的一般应用。为了说明的目的，提供了特定的协议应用程序。
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[关键词]中所述进行解释。
The Bidirectional Forwarding Detection (BFD) specification defines a protocol with simple and specific semantics. Its sole purpose is to verify connectivity between a pair of systems, for a particular data protocol across a path (which may be of any technology, length, or OSI layer). The promptness of the detection of a path failure can be controlled by trading off protocol overhead and system load with detection times.
双向转发检测（BFD）规范定义了一个具有简单和特定语义的协议。其唯一目的是验证一对系统之间的连接，以跨路径（可以是任何技术、长度或OSI层）验证特定数据协议。通过权衡协议开销和系统负载与检测时间，可以控制路径故障检测的及时性。
BFD is *not* intended to directly provide control protocol liveness information; those protocols have their own means and vagaries. Rather, control protocols can use the services provided by BFD to inform their operation. BFD can be viewed as a service provided by the layer in which it is running.
BFD*不*旨在直接提供控制协议活性信息；这些协议有自己的手段和变幻莫测之处。相反，控制协议可以使用BFD提供的服务来通知其操作。BFD可以被看作是由运行它的层提供的服务。
The service interface with BFD is straightforward. The application supplies session parameters (neighbor address, time parameters, protocol options), and BFD provides the session state, of which the most interesting transitions are to and from the Up state. The application is expected to bootstrap the BFD session, as BFD has no discovery mechanism.
与BFD的服务接口非常简单。应用程序提供会话参数（邻居地址、时间参数、协议选项），BFD提供会话状态，其中最有趣的转换是从向上状态到向上状态的转换。应用程序将引导BFD会话，因为BFD没有发现机制。
An implementation SHOULD establish only a single BFD session per data protocol path, regardless of the number of applications that wish to utilize it. There is no additional value in having multiple BFD sessions to the same endpoints. If multiple applications request different session parameters, it is a local issue as to how to resolve the parameter conflicts. BFD in turn will notify all applications bound to a session when a session state change occurs.
一个实现应该只为每个数据协议路径建立一个BFD会话，而不管有多少应用程序希望使用它。将多个BFD会话连接到同一端点没有任何附加价值。如果多个应用程序请求不同的会话参数，那么如何解决参数冲突是本地问题。当会话状态发生更改时，BFD将通知绑定到会话的所有应用程序。
BFD should be viewed as having an advisory role to the protocol or protocols or other network functions with which it is interacting, which will then use their own mechanisms to effect any state transitions. The interaction is very much at arm's length, which keeps things simple and decoupled. In particular, BFD explicitly does not carry application-specific information, partly for architectural reasons and partly because BFD may have curious and unpredictable latency characteristics and as such makes a poor transport mechanism.
BFD应被视为对与其交互的一个或多个协议或其他网络功能具有咨询作用，然后将使用其自身的机制实现任何状态转换。相互作用是一臂之遥的，这使得事情变得简单和不耦合。特别是，BFD显式地不携带特定于应用程序的信息，部分是因为架构原因，部分是因为BFD可能具有奇怪和不可预测的延迟特性，因此导致传输机制较差。
It is important to remember that the interaction between BFD and its client applications has essentially no interoperability issues, because BFD is acting in an advisory nature (similar to hardware signaling the loss of light on a fiber optic circuit, for example) and existing mechanisms in the client applications are used in reaction to BFD events. In fact, BFD may interact with only one of a pair of systems for a particular client application without any ill effect.
重要的是要记住，BFD与其客户机应用程序之间的交互基本上没有互操作性问题，因为BFD具有咨询性质（例如，类似于在光纤电路上发出光损耗信号的硬件）客户端应用程序中的现有机制用于响应BFD事件。事实上，对于特定的客户端应用程序，BFD可能只与一对系统中的一个进行交互，而不会产生任何不良影响。
The interaction between a BFD session and its associated client applications is, for the most part, an implementation issue that is outside the scope of this specification. However, it is useful to describe some mechanisms that implementors may use in order to promote full-featured implementations. One way of modeling this interaction is to create an adaptation layer between the BFD state machine and the client applications. The adaptation layer is cognizant of both the internals of the BFD implementation and the requirements of the clients.
BFD会话与其关联的客户端应用程序之间的交互在很大程度上是一个不在本规范范围内的实现问题。然而，描述一些实现者为了促进全功能实现而可能使用的机制是有用的。对这种交互进行建模的一种方法是在BFD状态机和客户端应用程序之间创建一个适配层。适应层了解BFD实现的内部内容和客户的需求。
A BFD session can be tightly coupled to its client applications; for example, any transition out of the Up state could cause signaling to the clients to take failure action. However, in some cases, this may not always be the best course of action.
BFD会话可以与其客户端应用程序紧密耦合；例如，任何脱离Up状态的转换都可能导致向客户端发送信号以采取故障操作。然而，在某些情况下，这可能并不总是最佳的行动方案。
Implementors may choose to hide rapid Up/Down/Up transitions of the BFD session from its clients. This is useful in order to support process restarts without necessitating complex protocol mechanisms, for example.
实现者可以选择对其客户端隐藏BFD会话的快速向上/向下/向上转换。例如，为了支持进程重启而不需要复杂的协议机制，这非常有用。
As such, a system MAY choose not to notify clients if a BFD session transitions from Up to Down state, and returns to Up state, if it does so within a reasonable period of time (the length of which is outside the scope of this specification). If the BFD session does not return to Up state within that time frame, the clients SHOULD be notified that a session failure has occurred.
因此，如果BFD会话在合理的时间段内（其长度不在本规范的范围内）从上升状态转换到下降状态，系统可以选择不通知客户端，而返回到上升状态。如果BFD会话在该时间范围内没有返回到Up状态，则应通知客户端会话失败。
The AdminDown mechanism in BFD is intended to signal that the BFD session is being taken down for administrative purposes, and the session state is not indicative of the liveness of the data path.
BFD中的AdminDown机制旨在发出信号，表示出于管理目的正在关闭BFD会话，而会话状态并不表示数据路径的活动性。
Therefore, a system SHOULD NOT indicate a connectivity failure to a client if either the local session state or the remote session state (if known) transitions to AdminDown, so long as that client has independent means of liveness detection (typically, control protocols).
因此，如果本地会话状态或远程会话状态（如果已知）转换为AdminDown，则系统不应向客户端指示连接故障，只要该客户端具有独立的活动性检测手段（通常为控制协议）。
If a client does not have any independent means of liveness detection, a system SHOULD indicate a connectivity failure to a client, and assume the semantics of Down state, if either the local or remote session state transitions to AdminDown. Otherwise, the client will not be able to determine whether the path is viable, and unfortunate results may occur.
如果客户机没有任何独立的活动性检测手段，则系统应向客户机指示连接故障，并假设在本地或远程会话状态转换为AdminDown时为Down状态。否则，客户端将无法确定该路径是否可行，可能会出现不幸的结果。
It is useful to be able to configure a BFD session between a pair of systems without impacting the state of any clients that will be associated with that session. Similarly, it is useful for BFD state to be reestablished without perturbing associated clients when all BFD state is lost (such as in process restart situations). This interacts with the clients' ability to establish their state independent of BFD.
能够在一对系统之间配置BFD会话而不影响将与该会话关联的任何客户端的状态非常有用。类似地，当所有BFD状态丢失时（例如在进程重新启动的情况下），重新建立BFD状态而不干扰相关的客户端也是很有用的。这与客户建立独立于BFD的状态的能力相互作用。
The BFD state machine transitions that occur in the process of bringing up a BFD session in such situations SHOULD NOT cause a connectivity failure notification to the clients.
在这种情况下，在启动BFD会话的过程中发生的BFD状态机转换不应向客户端发出连接失败通知。
A client that is capable of establishing its state prior to the configuration or restarting of a BFD session MAY do so if appropriate. The means to do so is outside of the scope of this specification.
如果适当，能够在配置或重新启动BFD会话之前建立其状态的客户端可以这样做。这样做的方法不在本规范的范围内。
Very common client applications of BFD are control protocols, such as routing protocols. The object, when BFD interacts with a control protocol, is to advise the control protocol of the connectivity of the data protocol. In the case of routing protocols, for example, this allows the connectivity failure to trigger the rerouting of traffic around the failed path more quickly than the native detection mechanisms.
BFD非常常见的客户端应用程序是控制协议，例如路由协议。当BFD与控制协议交互时，其目的是向控制协议建议数据协议的连接。例如，在路由协议的情况下，这允许连接故障比本机检测机制更快地触发故障路径周围流量的重新路由。
If the session state on either the local or remote system (if known) is AdminDown, BFD has been administratively disabled, and the establishment of a control protocol adjacency MUST be allowed.
如果本地或远程系统（如果已知）上的会话状态为AdminDown，则BFD已被管理禁用，并且必须允许建立控制协议邻接。
BFD sessions are typically bootstrapped by the control protocol, using the mechanism (discovery, configuration) used by the control protocol to find neighbors. Note that it is possible in some failure scenarios for the network to be in a state such that the control protocol is capable of coming up, but the BFD session cannot be established, and, more particularly, data cannot be forwarded. To avoid this situation, it would be beneficial not to allow the control protocol to establish a neighbor adjacency. However, this would preclude the operation of the control protocol in an environment in which not all systems support BFD.
BFD会话通常由控制协议引导，使用控制协议用于查找邻居的机制（发现、配置）。注意，在某些故障场景中，网络可能处于控制协议能够启动的状态，但无法建立BFD会话，更具体地说，无法转发数据。为了避免这种情况，不允许控制协议建立邻居邻接是有益的。然而，这将妨碍控制协议在并非所有系统都支持BFD的环境中运行。
Therefore, the establishment of control protocol adjacencies SHOULD be blocked if both systems are willing to establish a BFD session but a BFD session cannot be established. One method for determining that both systems are willing to establish a BFD session is if the control protocol carries explicit signaling of this fact. If there is no explicit signaling, the willingness to establish a BFD session may be determined by means outside the scope of this specification.
因此，如果两个系统都愿意建立BFD会话，但无法建立BFD会话，则应阻止建立控制协议邻接。确定两个系统都愿意建立BFD会话的一种方法是，控制协议是否携带该事实的明确信令。如果没有明确的信令，建立BFD会话的意愿可以通过本规范范围之外的方式确定。
If it is believed that the neighboring system does not support BFD, the establishment of a control protocol adjacency SHOULD NOT be blocked.
如果认为相邻系统不支持BFD，则不应阻止建立控制协议邻接。
The setting of BFD's various timing parameters and modes are not subject to standardization. Note that all protocols sharing a session will operate using the same parameters. The mechanism for choosing the parameters among those desired by the various protocols
BFD的各种定时参数和模式的设置不进行标准化。请注意，共享会话的所有协议都将使用相同的参数进行操作。在各种协议所需参数中选择参数的机制
is outside the scope of this specification. It is generally useful to choose the parameters resulting in the shortest Detection Time; a particular client application can always apply hysteresis to the notifications from BFD if it desires longer Detection Times.
不在本规范的范围内。选择能使检测时间最短的参数通常很有用；如果某个特定的客户端应用程序需要更长的检测时间，它总是可以对来自BFD的通知应用滞后。
Note that many control protocols assume full connectivity between all systems on multiaccess media such as LANs. If BFD is running on only a subset of systems on such a network, and adjacency establishment is blocked by the absence of a BFD session, the assumptions of the control protocol may be violated, with unpredictable results.
请注意，许多控制协议假定多址介质（如LAN）上的所有系统之间具有完全连接。如果BFD仅在此类网络上的系统子集上运行，并且邻接建立因缺少BFD会话而受阻，则可能违反控制协议的假设，从而导致不可预测的结果。
If a BFD session transitions from Up state to AdminDown, or the session transitions from Up to Down because the remote system is indicating that the session is in state AdminDown, clients SHOULD NOT take any control protocol action.
如果BFD会话从向上状态转换为AdminDown，或者由于远程系统指示会话处于AdminDown状态，因此会话从向上转换为向下，则客户端不应采取任何控制协议操作。
For other transitions from Up to Down state, the mechanism by which the control protocol reacts to a path failure signaled by BFD depends on the capabilities of the protocol, as specified in the following subsections.
对于从上升到下降状态的其他转换，控制协议对BFD发出的路径故障做出反应的机制取决于协议的能力，如以下小节所述。
A control protocol that is tightly bound to a single failing data protocol SHOULD take action to ensure that data traffic is no longer directed to the failing path. Note that this should not be interpreted as BFD replacing the control protocol liveness mechanism, if any, as the control protocol may rely on mechanisms not verified by BFD (multicast, for instance) so BFD most likely cannot detect all failures that would impact the control protocol. However, a control protocol MAY choose to use BFD session state information to more rapidly detect an impending control protocol failure, particularly if the control protocol operates in-band (over the data protocol).
紧密绑定到单个故障数据协议的控制协议应采取措施确保数据通信不再定向到故障路径。请注意，这不应解释为BFD取代了控制协议活性机制（如果有），因为控制协议可能依赖于未经BFD验证的机制（例如，多播），因此BFD很可能无法检测到会影响控制协议的所有故障。然而，控制协议可以选择使用BFD会话状态信息来更快速地检测即将发生的控制协议故障，特别是当控制协议在频带内（通过数据协议）运行时。
Therefore, when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path over which BFD is running. If the control protocol has an explicit mechanism for announcing path state, a system SHOULD use that mechanism rather than impacting the connectivity of the control protocol, particularly if the control protocol operates out-of-band from the failed data protocol. However, if such a mechanism is not available, a control protocol timeout SHOULD be emulated for the associated neighbor.
因此，当BFD会话从上到下转换时，应在控制协议中采取措施，以表明BFD运行的路径缺乏连接。如果控制协议具有明确的机制来宣布路径状态，则系统应使用该机制，而不是影响控制协议的连接性，尤其是当控制协议在故障数据协议的带外运行时。但是，如果这种机制不可用，则应为关联的邻居模拟控制协议超时。
Slightly different mechanisms are used if the control protocol supports the routing of multiple data protocols, depending on whether the control protocol supports separate topologies for each data protocol.
如果控制协议支持多个数据协议的路由，则使用稍微不同的机制，具体取决于控制协议是否支持每个数据协议的单独拓扑。
With a shared topology, if one of the data protocols fails (as signaled by the associated BFD session), it is necessary to consider the path to have failed for all data protocols. Otherwise, there is no way for the control protocol to turn away traffic for the failed data protocol (and such traffic would be black-holed indefinitely).
对于共享拓扑，如果其中一个数据协议失败（由相关的BFD会话发出信号），则必须考虑所有数据协议失败的路径。否则，控制协议无法关闭故障数据协议的通信量（这样的通信量将被无限期地屏蔽）。
Therefore, when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path in the topology corresponding to the BFD session. If this cannot be signaled otherwise, a control protocol timeout SHOULD be emulated for the associated neighbor.
因此，当BFD会话从上到下转换时，应在控制协议中采取措施，以表明与BFD会话对应的拓扑中的路径缺乏连接。如果不能以其他方式发出信号，则应为关联的邻居模拟控制协议超时。
With individual routing topologies for each data protocol, only the failed data protocol needs to be rerouted around the failed path.
对于每个数据协议的单独路由拓扑，只有故障数据协议需要围绕故障路径重新路由。
Therefore, when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path in the topology over which BFD is running. Generally, this can be done without impacting the connectivity of other topologies (since otherwise it is very difficult to support separate topologies for multiple data protocols).
因此，当BFD会话从上到下转换时，应在控制协议中采取措施，以表明BFD运行的拓扑中的路径缺乏连接。通常，这可以在不影响其他拓扑的连接性的情况下完成（因为在其他情况下，很难为多个数据协议支持单独的拓扑）。
A number of control protocols support Graceful Restart mechanisms, including IS-IS [ISIS-GRACE], OSPF [OSPF-GRACE], and BGP [BGP-GRACE]. These mechanisms are designed to allow a control protocol to restart without perturbing network connectivity state (lest it appear that the system and/or all of its links had failed). They are predicated on the existence of a separate forwarding plane that does not necessarily share fate with the control plane in which the routing protocols operate. In particular, the assumption is that the forwarding plane can continue to function while the protocols restart and sort things out.
许多控制协议支持优雅的重启机制，包括IS-IS[ISIS-GRACE]、OSPF[OSPF-GRACE]和BGP[BGP-GRACE]。这些机制旨在允许控制协议在不干扰网络连接状态的情况下重新启动（以免系统和/或其所有链路出现故障）。它们的前提是存在一个独立的转发平面，该转发平面不一定与路由协议运行的控制平面共享命运。特别是，假设转发平面可以在协议重新启动和排序时继续工作。
BFD implementations announce via the Control Plane Independent "C" bit whether or not BFD shares fate with the control plane. This
BFD实现通过与控制平面无关的“C”位宣布BFD是否与控制平面共享命运。这
information is used to determine the actions to be taken in conjunction with Graceful Restart. If BFD does not share its fate with the control plane on either system, it can be used to determine whether Graceful Restart in a control protocol is NOT viable (the forwarding plane is not operating).
信息用于确定在正常重启时要采取的操作。如果BFD不能与任一系统上的控制平面共享其命运，则可使用BFD确定控制协议中的正常重启是否不可行（转发平面未运行）。
If the control protocol has a Graceful Restart mechanism, BFD may be used in conjunction with this mechanism. The interaction between BFD and the control protocol depends on the capabilities of the control protocol and whether or not BFD shares fate with the control plane. In particular, it may be desirable for a BFD session failure to abort the Graceful Restart process and allow the failure to be visible to the network.
如果控制协议具有优雅的重启机制，则BFD可与该机制结合使用。BFD和控制协议之间的交互取决于控制协议的能力以及BFD是否与控制平面共享命运。特别是，BFD会话故障可能需要中止正常重启过程，并允许故障对网络可见。
If BFD is implemented in the forwarding plane and does not share fate with the control plane on either system (the "C" bit is set in the BFD Control packets in both directions), control protocol restarts should not affect the BFD session. In this case, a BFD session failure implies that data can no longer be forwarded, so any Graceful Restart in progress at the time of the BFD session failure SHOULD be aborted in order to avoid black holes, and a topology change SHOULD be signaled in the control protocol.
如果BFD在转发平面中实现，并且不与任何系统上的控制平面共享命运（在两个方向的BFD控制数据包中设置了“C”位），则控制协议重新启动不应影响BFD会话。在这种情况下，BFD会话失败意味着无法再转发数据，因此在BFD会话失败时正在进行的任何正常重启都应该中止，以避免黑洞，并且拓扑更改应该在控制协议中发出信号。
If BFD shares fate with the control plane on either system (the "C" bit is clear in either direction), a BFD session failure cannot be disentangled from other events taking place in the control plane. In many cases, the BFD session will fail as a side effect of the restart taking place. As such, it would be best to avoid aborting any Graceful Restart taking place, if possible (since otherwise BFD and Graceful Restart cannot coexist).
如果BFD与任一系统上的控制平面命运相同（“C”位在任一方向上都是清晰的），则BFD会话故障无法与控制平面中发生的其他事件分离。在许多情况下，BFD会话将由于重新启动的副作用而失败。因此，如果可能，最好避免中止任何正常重启（否则BFD和正常重启不能共存）。
There is some risk in doing so, since a simultaneous failure or restart of the forwarding plane will not be detected, but this is always an issue when BFD shares fate with the control plane.
这样做有一定的风险，因为转发平面的同时故障或重新启动不会被检测到，但当BFD与控制平面共享命运时，这始终是一个问题。
Some control protocols can signal a planned restart prior to the restart taking place. In this case, if a BFD session failure occurs during the restart, such a planned restart SHOULD NOT be aborted and the session failure SHOULD NOT result in a topology change being signaled in the control protocol.
一些控制协议可以在重新启动之前发出计划重新启动的信号。在这种情况下，如果重新启动期间发生BFD会话故障，则不应中止此类计划的重新启动，并且会话故障不应导致在控制协议中发出拓扑更改信号。
Control protocols that cannot signal a planned restart depend on the recently restarted system to signal the Graceful Restart prior to the control protocol adjacency timeout. In most cases, whether the restart is planned or unplanned, it is likely that the BFD session will time out prior to the onset of Graceful Restart, in which case a topology change SHOULD be signaled in the control protocol as specified in Section 3.2.
无法发出计划重启信号的控制协议依赖于最近重启的系统在控制协议邻接超时之前发出正常重启信号。在大多数情况下，无论重启是计划内的还是计划外的，BFD会话都可能在正常重启开始之前超时，在这种情况下，应按照第3.2节的规定在控制协议中发出拓扑更改的信号。
However, if the restart is in fact planned, an implementation MAY adjust the BFD session timing parameters prior to restarting in such a way that the Detection Time in each direction is longer than the restart period of the control protocol, providing the restarting system the same opportunity to enter Graceful Restart as it would have without BFD. The restarting system SHOULD NOT send any BFD Control packets until there is a high likelihood that its neighbors know a Graceful Restart is taking place, as the first BFD Control packet will cause the BFD session to fail.
然而，如果实际上计划了重启，则实现可以在重启之前调整BFD会话定时参数，使得每个方向上的检测时间长于控制协议的重启周期，为重新启动系统提供与无BFD时相同的进入优雅重新启动的机会。由于第一个BFD控制数据包将导致BFD会话失败，重新启动系统不应发送任何BFD控制数据包，直到其邻居很可能知道正在进行正常的重新启动。
If multiple control protocols wish to establish BFD sessions with the same remote system for the same data protocol, all MUST share a single BFD session.
如果多个控制协议希望为同一数据协议与同一远程系统建立BFD会话，则所有协议必须共享一个BFD会话。
If hierarchical or dependent layers of control protocols are in use (say, OSPF and Internal BGP (IBGP)), it may not be useful for more than one of them to interact with BFD. In this example, because IBGP is dependent on OSPF for its routing information, the faster failure detection relayed to IBGP may actually be detrimental. The cost of a peer state transition is high in BGP, and OSPF will naturally heal the path through the network if it were to receive the failure detection.
如果使用控制协议的分层或依赖层（例如，OSPF和内部BGP（IBGP）），则其中多个与BFD交互可能没有用处。在本例中，由于IBGP的路由信息依赖于OSPF，因此中继到IBGP的更快的故障检测实际上可能是有害的。在BGP中，对等状态转换的成本很高，如果OSPF要接收故障检测，它自然会修复通过网络的路径。
In general, it is best for the protocol at the lowest point in the hierarchy to interact with BFD, and then to use existing interactions between the control protocols to effect changes as necessary. This will provide the fastest possible failure detection and recovery in a network.
通常，层次结构中最低点的协议最好与BFD交互，然后使用控制协议之间的现有交互来实现必要的更改。这将在网络中提供尽可能快的故障检测和恢复。
BFD session status may be used to affect other system functions that are not protocol based (for example, static routes). If the path to a remote system fails, it may be desirable to avoid passing traffic
BFD会话状态可用于影响非基于协议的其他系统功能（例如，静态路由）。如果到远程系统的路径出现故障，可能需要避免通过通信量
to that remote system, so the local system may wish to take internal measures to accomplish this (such as withdrawing a static route and withdrawing that route from routing protocols).
对于该远程系统，本地系统可能希望采取内部措施来实现这一点（例如从路由协议中提取静态路由和该路由）。
If it is known, or presumed, that the remote system is BFD capable and the BFD session is not in Up state, appropriate action SHOULD be taken (such as withdrawing a static route).
如果已知或假定远程系统具有BFD功能，且BFD会话未处于启动状态，则应采取适当的措施（例如撤回静态路由）。
If it is known, or presumed, that the remote system does not support BFD, action such as withdrawing a static route SHOULD NOT be taken.
如果已知或推测远程系统不支持BFD，则不应采取诸如撤消静态路由之类的操作。
Bootstrapping of the BFD session in the non-protocol case is likely to be derived from configuration information.
非协议情况下BFD会话的引导可能来自配置信息。
There is no need to exchange endpoints or discriminator values via any mechanism other than configuration (via Operational Support Systems or any other means) as the endpoints must be known and configured by the same means.
不需要通过配置以外的任何机制（通过操作支持系统或任何其他方式）交换端点或鉴别器值，因为端点必须是已知的，并且必须通过相同的方式进行配置。
BFD is intended to protect a single "data protocol" and is encapsulated within that protocol. A pair of systems may have multiple BFD sessions over the same topology if they support (and are encapsulated by) different protocols. For example, if two systems have IPv4 and IPv6 running across the same link between them, these are considered two separate paths and require two separate BFD sessions.
BFD旨在保护单个“数据协议”，并封装在该协议中。如果一对系统支持（并由）不同的协议封装，则它们可能在同一拓扑上具有多个BFD会话。例如，如果两个系统的IPv4和IPv6在它们之间的同一链路上运行，则它们被视为两个独立的路径，需要两个独立的BFD会话。
This same technique is used for more fine-grained paths. For example, if multiple differentiated services [DIFFSERV] are being operated over IPv4, an independent BFD session may be run for each service level. The BFD Control packets must be marked in the same way as the data packets, partly to ensure as much fate sharing as possible between BFD and data traffic, and also to demultiplex the initial packet if the discriminator values have not been exchanged.
同样的技术也用于更细粒度的路径。例如，如果在IPv4上运行多个区分服务[DIFFSERV]，则可以为每个服务级别运行独立的BFD会话。BFD控制包必须以与数据包相同的方式进行标记，部分是为了确保BFD和数据流量之间尽可能多的命运共享，并且如果没有交换鉴别器值，也为了解复用初始包。
A number of technologies exist for aggregating multiple parallel links at layer N-1 and treating them as a single link at layer N. BFD may be used in a number of ways to protect the path at layer N. The exact mechanism used is outside the scope of this specification. However, this section provides examples of some possible deployment scenarios. Other scenarios are possible and are not precluded.
有许多技术可用于聚合N-1层的多个并行链路，并将其视为N层的单个链路。BFD可用于多种方式来保护N层的路径。所使用的确切机制不在本规范的范围内。但是，本节提供了一些可能的部署场景的示例。其他情况也是可能的，也不排除。
The simplest approach is to simply run BFD over the layer N path, with no interaction with the layer N-1 mechanisms. Doing so assumes that the layer N-1 mechanism will deal with connectivity issues in individual layer N-1 links. BFD will declare a failure in the layer N path only when the session times out.
最简单的方法是简单地在N层路径上运行BFD，而不与N-1层机制交互。这样做假设N-1层机制将处理单个N-1层链路中的连接问题。只有在会话超时时，BFD才会在第N层路径中声明失败。
This approach will work whether or not the layer N-1 neighbor is the same as the layer N neighbor.
无论层N-1邻居是否与层N邻居相同，这种方法都有效。
A slightly more intelligent approach than complete decoupling is to have the layer N-1 mechanism inform the layer N BFD when the aggregated link is no longer viable. In this case, the BFD session will detect the failure more rapidly, as it need not wait for the session to time out. This is analogous to triggering a session failure based on the hardware-detected failure of a single link.
与完全解耦相比，更智能的方法是，当聚合链路不再可行时，让第N-1层机制通知第N层BFD。在这种情况下，BFD会话将更快地检测到故障，因为它不需要等待会话超时。这类似于基于单个链路的硬件检测故障触发会话故障。
This approach will also work whether or not the layer N-1 neighbor is the same as the layer N neighbor.
无论层N-1邻居是否与层N邻居相同，此方法也将起作用。
Another approach would be to use BFD on each layer N-1 link and to aggregate the state of the multiple sessions into a single indication to the layer N clients. This approach has the advantage that it is independent of the layer N-1 technology. However, this approach only works if the layer N neighbor is the same as the layer N-1 neighbor (a single hop at layer N-1).
另一种方法是在每个N-1层链路上使用BFD，并将多个会话的状态聚合为一个对N层客户端的指示。这种方法的优点是它独立于N-1层技术。然而，这种方法仅在N层邻居与N-1层邻居（N-1层的单跳）相同的情况下有效。
Combinations of more than one of the scenarios listed above (or others) may be useful in some cases. For example, if the layer N neighbor is not directly connected at layer N-1, a system might run a BFD session across each layer N-1 link to the immediate layer N-1 neighbor and then run another BFD session to the layer N neighbor. The aggregate state of the layer N-1 BFD sessions could be used to trigger a layer N BFD session failure.
在某些情况下，上述（或其他）多个场景的组合可能很有用。例如，如果N层邻居未直接连接到N-1层，则系统可能会在每个N-1层链路上运行一个BFD会话，然后运行另一个BFD会话到N层邻居。层N-1 BFD会话的聚合状态可用于触发层N BFD会话失败。
BFD can provide liveness detection for functions related to Operations, Administration, and Maintenance (OAM) in tunneling and pseudowire protocols. Running BFD inside the tunnel is recommended, as it exercises more aspects of the path. One way to accommodate this is to address BFD packets based on the tunnel endpoints, assuming that they are numbered.
BFD可以为隧道和伪线协议中与操作、管理和维护（OAM）相关的功能提供活跃度检测。建议在隧道内运行BFD，因为它锻炼了路径的更多方面。解决这一问题的一种方法是基于隧道端点寻址BFD数据包，假设它们已编号。
If a planned outage is to take place on a path over which BFD is run, it is preferable to take down the BFD session by going into AdminDown state prior to the outage. The system asserting AdminDown SHOULD do so for at least one Detection Time in order to ensure that the remote system is aware of it.
如果计划的停机发生在运行BFD的路径上，则最好在停机之前进入AdminDown状态以关闭BFD会话。断言AdminDown的系统应至少进行一次检测，以确保远程系统知道它。
Similarly, if BFD is to be deconfigured from a system, it is desirable not to trigger any client application action. Simply ceasing the transmission of BFD Control packets will cause the remote system to detect a session failure. In order to avoid this, the system on which BFD is being deconfigured SHOULD put the session into AdminDown state and maintain this state for a Detection Time to ensure that the remote system is aware of it.
类似地，如果要从系统中取消配置BFD，最好不要触发任何客户端应用程序操作。简单地停止BFD控制数据包的传输将导致远程系统检测到会话失败。为了避免这种情况，正在取消配置BFD的系统应将会话置于AdminDown状态，并将此状态保持一段检测时间，以确保远程系统知道它。
The BFD protocol itself is designed so that it will always interoperate at a basic level; asynchronous mode is mandatory and is always available, and other modes and functions are negotiated at run time. Since the service provided by BFD is identical regardless of the variants used, the particular choice of BFD options has no bearing on interoperability.
BFD协议本身的设计使其始终在基本级别上进行互操作；异步模式是强制性的，并且始终可用，其他模式和函数在运行时协商。由于无论使用何种变体，BFD提供的服务都是相同的，因此BFD选项的特定选择对互操作性没有影响。
The interaction between BFD and other protocols and control functions is very loosely coupled. The actions taken are based on existing mechanisms in those protocols and functions, so interoperability problems are very unlikely unless BFD is applied in contradictory ways (such as a BFD session failure causing one implementation to go down and another implementation to come up). In fact, BFD may be advising one system for a particular control function but not the other; the only impact of this would be potentially asymmetric control protocol failure detection.
BFD与其他协议和控制功能之间的交互非常松散耦合。所采取的行动基于这些协议和功能中的现有机制，因此，除非以相互矛盾的方式应用BFD（例如BFD会话失败，导致一个实现失败，另一个实现出现），否则互操作性问题不太可能出现。事实上，BFD可能建议一个系统执行特定的控制功能，但不建议另一个系统；这唯一的影响是潜在的不对称控制协议故障检测。
As noted above, there are no interoperability concerns regarding interactions between BFD and control protocols. However, there is enough concern and confusion in this area so that it is worthwhile to provide examples of interactions with specific protocols.
如上所述，BFD和控制协议之间的交互不存在互操作性问题。然而，在这一领域有足够的关注和困惑，因此有必要提供与特定协议交互的示例。
Since the interactions do not affect interoperability, they are non-normative.
由于交互不影响互操作性，因此它们是非规范性的。
The two versions of OSPF ([OSPFv2] and [OSPFv3]), as well as IS-IS [ISIS], all suffer from an architectural limitation, namely that their Hello protocols are limited in the granularity of their failure detection times. In particular, OSPF has a minimum detection time of two seconds, and IS-IS has a minimum detection time of one second.
OSPF的两个版本（[OSPFv2]和[OSPFv3]）以及IS-IS[ISIS]都受到架构限制，即它们的Hello协议在故障检测时间的粒度上受到限制。特别是，OSPF的最小检测时间为2秒，IS-IS的最小检测时间为1秒。
BFD may be used to achieve arbitrarily small detection times for these protocols by supplementing the Hello protocols used in each case.
通过补充在每种情况下使用的Hello协议，BFD可用于实现这些协议任意小的检测时间。
The most obvious choice for triggering BFD session establishment with these protocols would be to use the discovery mechanism inherent in the Hello protocols in OSPF and IS-IS to bootstrap the establishment of the BFD session. Any BFD sessions established to support OSPF and IS-IS across a single IP hop must operate in accordance with [BFD-1HOP].
使用这些协议触发BFD会话建立的最明显的选择是使用OSPF中Hello协议固有的发现机制和IS-IS引导BFD会话的建立。为支持OSPF和IS-IS而建立的任何BFD会话必须按照[BFD-1HOP]进行操作。
The basic mechanisms are covered in Section 3 above. At this time, OSPFv2 and OSPFv3 carry routing information for a single data protocol (IPv4 and IPv6, respectively) so when it is desired to signal a topology change after a BFD session failure, this should be done by tearing down the corresponding OSPF neighbor.
基本机制见上文第3节。此时，OSPFv2和OSPFv3携带单个数据协议（分别为IPv4和IPv6）的路由信息，因此当需要在BFD会话失败后发出拓扑更改信号时，应通过拆除相应的OSPF邻居来完成。
IS-IS may be used to support only one data protocol, or multiple data protocols. [ISIS] specifies a common topology for multiple data protocols, but work is under way to support multiple topologies. If multiple topologies are used to support multiple data protocols (or multiple classes of service of the same data protocol), the topology-specific path associated with a failing BFD session should no longer be advertised in IS-IS Label Switched Paths (LSPs) in order to signal a lack of connectivity. Otherwise, a failing BFD session should be signaled by simulating an IS-IS adjacency failure.
IS-IS可用于仅支持一个或多个数据协议。[ISIS]为多个数据协议指定了一个通用拓扑，但支持多个拓扑的工作正在进行中。如果使用多个拓扑来支持多个数据协议（或同一数据协议的多个服务类别），则与故障BFD会话相关联的拓扑特定路径不应再在IS-IS标签交换路径（LSP）中通告，以表示缺乏连接。否则，失败的BFD会话应通过模拟IS-IS邻接故障发出信号。
OSPF has a planned restart signaling mechanism, whereas IS-IS does not. The appropriate mechanisms outlined in Section 3.3 should be used.
OSPF有计划的重启信令机制，而IS-IS没有。应使用第3.3节中概述的适当机制。
If it is desired to use BFD for failure detection of OSPF Virtual Links, the mechanism described in [BFD-MULTI] MUST be used, since OSPF Virtual Links may traverse an arbitrary number of hops. BFD authentication SHOULD be used and is strongly encouraged.
如果希望使用BFD检测OSPF虚拟链路的故障，则必须使用[BFD-MULTI]中描述的机制，因为OSPF虚拟链路可能会穿越任意数量的跃点。应使用BFD认证，并强烈鼓励使用。
BFD may be useful with External Border Gateway Protocol (EBGP) sessions [BGP] in order to more rapidly trigger topology changes in the face of path failure. As noted in Section 4.4, it is generally unwise for IBGP sessions to interact with BFD if the underlying IGP is already doing so.
BFD可用于外部边界网关协议（EBGP）会话[BGP]，以便在遇到路径故障时更快速地触发拓扑更改。如第4.4节所述，如果基础IGP已经在与BFD互动，IBGP会话通常不明智。
EBGP sessions being advised by BFD may establish either a one-hop [BFD-1HOP] or a multihop [BFD-MULTI] session, depending on whether or not the neighbor is immediately adjacent. The BFD session should be established to the BGP neighbor (as opposed to any other Next Hop advertised in BGP). BFD authentication SHOULD be used and is strongly encouraged.
由BFD建议的EBGP会话可以建立单跳[BFD-1HOP]或多跳[BFD-MULTI]会话，具体取决于邻居是否紧邻。BFD会话应建立到BGP邻居（与BGP中公布的任何其他下一跳相反）。应使用BFD认证，并强烈鼓励使用。
[BGP-GRACE] describes a Graceful Restart mechanism for BGP. If Graceful Restart is not taking place on an EBGP session, and the corresponding BFD session fails, the EBGP session should be torn down in accordance with Section 3.2. If Graceful Restart is taking place, the basic procedures in Section 4.3 apply. BGP Graceful Restart does not signal planned restarts, so Section 4.3.2.2 applies. If Graceful Restart is aborted due to the rules described in Section 4.3, the "receiving speaker" should act as if the "restart timer" expired (as described in [BGP-GRACE]).
[BGP-GRACE]描述了BGP的优雅重启机制。如果EBGP会话未正常重启，且相应的BFD会话失败，则应按照第3.2节的规定拆除EBGP会话。如果正常重启，则第4.3节中的基本程序适用。BGP优雅重启并不表示计划重启，因此第4.3.2.2节适用。如果由于第4.3节中所述的规则而中止正常重启，“接收扬声器”的作用应与“重启定时器”过期一样（如[BGP-GRACE]中所述）。
The Routing Information Protocol (RIP) [RIP] is somewhat unique in that, at least as specified, neighbor adjacency state is not stored per se. Rather, installed routes contain a next hop address, which in most cases is the address of the advertising neighbor (but may not be).
路由信息协议（RIP）[RIP]在某种程度上是唯一的，至少按照规定，邻居邻接状态本身不存储。相反，安装的路由包含下一跳地址，在大多数情况下，下一跳地址是广告邻居的地址（但可能不是）。
In the case of RIP, when the BFD session associated with a neighbor fails, an expiration of the "timeout" timer for each route installed from the neighbor (for which the neighbor is the next hop) should be simulated.
在RIP的情况下，当与邻居关联的BFD会话失败时，应该模拟从邻居安装的每个路由（邻居是下一跳）的“超时”计时器过期。
Note that if a BFD session fails, and a route is received from that neighbor with a next hop address that is not the address of the neighbor itself, the route will linger until it naturally times out
请注意，如果BFD会话失败，并且从该邻居接收到一条路由，该路由的下一跳地址不是邻居本身的地址，则该路由将一直保留，直到它自然超时
(after 180 seconds). However, if an implementation keeps track of all of the routes received from each neighbor, all of the routes from the neighbor corresponding to the failed BFD session should be timed out, regardless of the next hop specified therein, and thereby avoiding the lingering route problem.
（180秒后）。然而，如果实现跟踪从每个邻居接收的所有路由，则与失败的BFD会话相对应的来自邻居的所有路由都应超时，而不管其中指定的下一跳，从而避免延迟路由问题。
This specification does not raise any additional security issues beyond those of the specifications referred to in the list of normative references.
除了规范性参考文献列表中提及的规范外，本规范不会提出任何其他安全问题。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010.
[BFD]Katz，D.和D.Ward，“双向转发检测”，RFC 58802010年6月。
[BFD-1HOP] Katz, D. and D. Ward,"Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[BFD-1HOP]Katz，D.和D.Ward，“IPv4和IPv6的双向转发检测（BFD）（单跳）”，RFC 58812010年6月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[BFD-MPLS]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[BFD-MULTI] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
[BFD-MULTI]Katz，D.和D.Ward，“多跳路径的双向转发检测（BFD）”，RFC 58832010年6月。
[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月。
[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[BGP-GRACE] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[BGP-GRACE]Sangli，S.，Chen，E.，Fernando，R.，Scudder，J.，和Y.Rekhter，“BGP的优雅重启机制”，RFC 47242007年1月。
[DIFFSERV] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[DIFFSERV]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 24741998年12月。
[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[ISIS]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 1195，1990年12月。
[ISIS-GRACE] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
[ISIS-GRACE]Shand，M.和L.Ginsberg，“IS-IS的重启信令”，RFC 5306，2008年10月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFv2]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[OSPFv3]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[OSPF-GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[OSPF-GRACE]Moy，J.，Pillay Esnault，P.，和A.Lindem，“OSPF的优雅重启”，RFC 36232003年11月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP]Malkin，G.，“RIP版本2”，STD 56，RFC 2453，1998年11月。
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