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)
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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-1HOP] [BFD-MULTI] [BFD-MPLS]）とBFDの使用を詳述しています。 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
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.
実装は関係なく、それを利用したいアプリケーションの数の、データ・プロトコル・パスごとに1つだけ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セッションはしっかりとそのクライアントアプリケーションに接続することができます。例えば、アップ状態のうち任意の遷移は、障害アクションを取るために、クライアントにシグナリングを引き起こす可能性があります。しかし、いくつかのケースでは、これは常に最善の行動ではないかもしれません。
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セッションがその時間枠内で最高の状態に戻らない場合、クライアントはセッションに障害が発生したことを通知する必要があります。
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).
したがって、システムは、IFローカルセッション状態または（既知の場合）、リモートセッション状態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へのセッションの状態遷移ローカルまたはリモート場合、ダウン状態のセマンティクスを前提としています。そうでない場合、クライアントはパスが実行可能であるかどうかを判断することはできません、と不幸な結果が発生する可能性があります。
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 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の様々なタイミングパラメータとモードの設定は、標準化の対象ではありません。セッションを共有するすべてのプロトコルが同じパラメータを使用して動作することに注意してください。様々なプロトコルによって、所望のうちのパラメータを選択するための機構は、本明細書の範囲外です。最短検出時間が得られたパラメータを選択することが一般的に有用です。それは長い検出時間を希望する場合、特定のクライアントアプリケーションは常に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.
AdminDownまでの状態から、BFDセッションの移行、またはがアップからダウンにセッション遷移は、リモート・システムは、セッションが状態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.
制御プロトコルの数は、ISIS [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 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の実装では、制御プレーンと制御プレーンの独立した「C」ビットか否か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は、転送プレーンに実装されており、いずれかのシステム上の制御プレーンと運命を共有していない場合（「C」ビットが両方向にBFD制御パケットに設定されている）、制御プロトコルの再起動は、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.
制御プロトコルの階層や依存の層が使用されている場合は、それらの2つ以上がBFDと対話するために（たとえば、OSPFおよび内部BGP（IBGP））は、それが有用ではないかもしれません。 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 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).
BFDセッション状態は（例えば、静的ルート）プロトコルベースでない他のシステム機能に影響を与えるために使用されてもよいです。リモートシステムへのパスに障害が発生した場合に、そのリモートシステムにトラフィックを渡す回避することが望ましいかもしれないので、ローカルシステムは、（例えば、スタティック・ルートを吸引し、ルーティングプロトコルからのルートを引き出すように）これを実現するための内部措置をとることを望むかもしれ。
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セッションを有していてもよいです。 2つのシステムがIPv4とIPv6がそれらの間の同じリンクを介して実行している場合たとえば、これらは、2つの別個の経路を考慮し、二つの別個の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.
これと同じ手法は、よりきめの細かいパスに使用されます。複数差別化サービス[DIFFSERV]はIPv4の上に操作されている場合、例えば、独立した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.でパスを保護するために、多くの方法で使用することができる層N-1に複数の平行リンクを集約し、層N. BFDで単一のリンクとしてそれらを処理するために存在しますこの仕様の範囲。ただし、このセクションでは、いくつかの可能な展開シナリオの例を示します。他のシナリオも可能であり、除外されません。
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-1のメカニズムとの相互作用で、層Nの経路を介してBFDを実行することです。そうすることで層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隣接するN-1リンクをBFDセッションを実行するかもしれないし、次に層Nに別のBFDセッションを実行します隣人。層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をアサートするシステムは、リモートシステムがそれを認識していることを保証するためには、少なくとも1つの検出時間のためにそれを行うべきです。
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は、（1つのダウンする実装と考え出す別の実装を引き起こし、そのような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の2つのバージョン（[OSPFv2の]と[OSPFv3の]）、ならびにISIS [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.
BFDは、それぞれの場合に使用されるHelloプロトコルを補完することにより、これらのプロトコルのための任意の小さな検出時間を達成するために使用することができます。
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プロトコルに固有の検出メカニズムを用いることであろうと、BFDセッションの確立をブートストラップするためにIS-IS。任意のBFDセッションOSPFをサポートするために設立され、単一のIPホップ間でIS-ISは、[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セッションに関連するトポロジー固有のパスがもはやでアドバタイズされるべきではないラベルのパス（LSPを）スイッチIS-IS接続性の欠如を知らせるため。そうでなければ、失敗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.
しない-ISがIS一方OSPFは、シグナリングメカニズム計画の再起動があります。 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.
OSPF仮想リンクの故障検出のためのBFDを使用することが望ましい場合OSPF仮想リンクホップの任意の数を横断することができるので、[BFD-MULTI]に記載の機構を使用しなければなりません。 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をまだ行っている場合IBGPセッションは、BFDと対話するために、一般的には賢明ではありません。
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セッションは、隣人がすぐ隣接しているか否かに応じて、1つのホップ[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セッションが失敗した場合、EBGPセッションは、セクション3.2に従って解体されなければなりません。グレースフルリスタートが行われている場合は、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.
ネイバーに関連付けられたBFDセッションが失敗したときにRIPの場合には、（隣接ネクストホップであるため）ネイバからインストールされた各経路の「タイムアウト」タイマーの満了がシミュレートされるべきです。
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 (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.
BFDセッションが失敗し、ルートが隣人自体のアドレスでないネクストホップアドレスとそのネイバーから受信した場合、ルートはまで自然にタイムアウトする（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]カッツ、D.とD.ウォード、 "双方向フォワーディング検出"、RFC 5880、2010年6月。
[BFD-1HOP] Katz, D. and D. Ward,"Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[BFD-1HOP]カッツ、D.およびD.区、 "IPv4およびIPv6（シングルホップ）のための双方向フォワーディング検出（BFD）"、RFC 5881、2010年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]アガルワル、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、 "双方向フォワーディング検出（BFD）MPLSラベルの（LSPを）パスのスイッチ" 2010年6月、RFC 5884を。
[BFD-MULTI] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
"マルチホップパスの双方向フォワーディング検出（BFD）" [BFD-MULTI]カッツ、D.およびD.区、RFC 5883、2010年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年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]サングリ、S.、チェン、E.、フェルナンド、R.、スカダー、J.、およびY. Rekhter、 "BGPのためのグレースフルリスタート機構"、RFC 4724、2007年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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[ISIS] Callon、R.、RFC 1195、1990年12月、 "TCP / IPやデュアル環境でのルーティングのためのOSI ISISの使用"。
[ISIS-GRACE] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
[ISIS-GRACE]シャンド、M.およびL.ギンズバーグ、 "ISISのための再起動シグナリング"、RFC 5306、2008年10月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
【のOSPFv2]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
【のOSPFv3] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
[OSPF-GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[OSPF-GRACE]モイ、J.、Pillay-Esnault、P.、およびA. Lindem、 "優雅なOSPF再起動"、RFC 3623、2003年11月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP]マルキン、G.、 "RIPバージョン2"、STD 56、RFC 2453、1998年11月。
Authors' Addresses
著者のアドレス
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
デイブ・カッツジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089-1206 USA
Phone: +1-408-745-2000 EMail: dkatz@juniper.net
電話：+ 1-408-745-2000 Eメール：dkatz@juniper.net
Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089-1206 USA
デイブ・ワードジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089-1206 USA
Phone: +1-408-745-2000 EMail: dward@juniper.net
電話：+ 1-408-745-2000 Eメール：dward@juniper.net