メインコンテンツまでスキップ

RFC 5880 - Bidirectional Forwarding Detection (双方向フォワーディング検出)

  • ステータス: Proposed Standard
  • 発行日: 2010年6月
  • ストリーム: IETF
  • エラッタ: エラッタなし

Abstract (概要)​

この文書は, 2つのフォワーディングエンジン間の双方向パスにおける障害を検出するためのプロトコルについて説明します。検出対象にはインターフェース, データリンク, および可能な限りフォワーディングエンジン自体が含まれ, 潜在的に非常に低いレイテンシで動作します。このプロトコルは, メディア, データプロトコル, およびルーティングプロトコルから独立して動作します。

Status of This Memo (この文書の位置付け)​

これは Internet Standards Track 文書です。

この文書は Internet Engineering Task Force (IETF) の成果物です。IETF コミュニティの合意を表しています。公開レビューを受け, Internet Engineering Steering Group (IESG) によって発行が承認されました。Internet Standards に関する詳細情報は RFC 5741 のセクション 2 で入手できます。

この文書の現在の状態, 正誤表, およびフィードバックの提供方法に関する情報は http://www.rfc-editor.org/info/rfc5880 で入手できます。

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

この文書は, この文書の発行日時点で有効な BCP 78 および IETF Trust の IETF 文書に関する法的規定 (http://trustee.ietf.org/license-info) の対象となります。これらの文書は, この文書に関するあなたの権利と制限を説明しているため, 注意深く確認してください。この文書から抽出されたコードコンポーネントには, Trust Legal Provisions のセクション 4.e に記載されている Simplified BSD License テキストを含める必要があり, Simplified BSD License に記載されているように保証なしで提供されます。

Contents​

6.7. Authentication (認証)​

任意の Authentication Section が BFD Control パケットに存在する場合があります (MAY)。一般的な形式では, Authentication Section の目的は, 使用されている認証タイプに基づいて, 受信システムが受信したパケットの妥当性を判断できるようにするために必要なすべての情報を運ぶことです。正確なメカニズムは使用されている認証タイプに依存しますが, 一般的に送信システムは Authentication Section にパケットの妥当性を保証する情報を入れ, 受信システムは Authentication Section を検査し, パケットをさらなる処理のために受け入れるか破棄します。

同じ認証タイプ, およびすべての必要なキーまたはその他の情報は, 明らかに2つのシステムで使用されていなければなりません。認証タイプのネゴシエーション, 鍵交換などは, すべてこの仕様の範囲外であり, プロトコル外の手段によって実行されることが期待されます。

以下のサブセクションで, パケットを "accept (受け入れる)" とは, パケットが認証に合格したことのみを意味することに注意してください。セクション 6.8.6 で説明されている一般的なパケット受信ルールで説明されているように, 他の理由で実際には破棄される可能性があります。

認証をサポートする実装は, 両方のタイプの SHA1 認証をサポートしなければなりません (MUST)。他の形式の認証はオプションです。

6.7.1. Enabling and Disabling Authentication (認証の有効化と無効化)​

セッション状態を乱すことなくセッションで認証を有効または無効にすることが望ましい場合があります。そのための正確なメカニズムは, この仕様の範囲外です。ただし, このメカニズムをサポートする際のいくつかの問題を指摘することは有用です。

単純な実装では, 認証がオンまたはオフにされると BFD セッションは失敗します。パケット受け入れルールは, 本質的にローカルマシンとリモートマシンがほぼ同期した方法で (検出時間内に) これを行うことを要求するためです。認証付きのパケットは, 認証が "使用中" の場合にのみ受け入れられます (同様に認証なしのパケット)。

1つの可能なアプローチは, 認証が設定されているが, 一致する認証セクションを含む最初のパケットが受信されるまで "使用中" とは見なされない実装を構築することです (必要な同期を提供します)。同様に, 認証はオフに設定できますが, 認証セクションなしの最初のパケットを受信するまで "使用中" と見なされます。

セキュリティリスクを回避するために, この方法を使用する実装は, 何らかの形式の介入なしに認証状態を最大1回のみ変更できるようにすべきです (SHOULD) (したがって, リモートシステムからの BFD Control パケットの受信のみに基づいて認証を繰り返しオンおよびオフにすることはできません)。認証を有効または無効にすることが望まれない限り, 実装は BFD Control パケットの受信に基づいて認証状態が変更されることを許可すべきではありません (SHOULD NOT)。

6.7.2. Simple Password Authentication (シンプルパスワード認証)​

最も単純な (そして最も弱い) 形式の認証は Simple Password Authentication です。この認証方法では, 1つ以上のパスワード (対応する Key ID を持つ) が各システムで設定され, これらのパスワード/IDペアの1つが各 BFD Control パケットで運ばれます。受信システムは, パスワードと Key ID がそのシステムで設定されているパスワード/IDペアの1つと一致する場合にパケットを受け入れます。

Transmission Using Simple Password Authentication (シンプルパスワード認証を使用した送信)

セッションの現在選択されているパスワードと Key ID は, 送信される各 BFD Control パケットの Authentication Section に格納されなければなりません (MUST)。Auth Type フィールドは 1 (Simple Password) に設定されなければなりません (MUST)。Auth Len フィールドは適切な長さ (4から19バイト) に設定されなければなりません (MUST)。

パスワードはバイナリ文字列であり, 1から16バイトの長さでなければなりません (MUST)。相互運用性のために, パスワードを設定する管理インターフェースは ASCII 文字列を受け入れなければならず (MUST), また16進数形式で任意のバイナリ文字列の設定も許可すべきです (SHOULD)。他の設定方法をサポートしてもかまいません (MAY)。

Reception Using Simple Password Authentication (シンプルパスワード認証を使用した受信)

受信した BFD Control パケットに Authentication Section が含まれていない場合, または Auth Type が 1 (Simple Password) でない場合, 受信したパケットは破棄されなければなりません (MUST)。

Auth Key ID フィールドが設定されているパスワードの ID と一致しない場合, 受信したパケットは破棄されなければなりません (MUST)。

Auth Len フィールドがキー ID によって選択されたパスワードの長さに3を加えたものと等しくない場合, パケットは破棄されなければなりません (MUST)。

Password フィールドがキー ID によって選択されたパスワードと一致しない場合, パケットは破棄されなければなりません (MUST)。

それ以外の場合, パケットは受け入れられなければなりません (MUST)。

6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication (Keyed MD5 および Meticulous Keyed MD5 認証)​

Keyed MD5 および Meticulous Keyed MD5 認証メカニズムは, 他のプロトコルで使用されているものと非常に似ています。これらの認証方法では, 1つ以上の秘密鍵 (対応するキー ID を持つ) が各システムで設定されます。鍵の1つは, 送信 BFD 制御パケット上で計算される MD5 [MD5] ダイジェストに含まれますが, 鍵自体はパケットで運ばれません。リプレイ攻撃を回避するために, シーケンス番号も各パケットで運ばれます。Keyed MD5 の場合, シーケンス番号は時折インクリメントされます。Meticulous Keyed MD5 の場合, シーケンス番号はすべてのパケットでインクリメントされます。

受信システムは, キー ID が設定されている鍵の1つと一致し, 選択された鍵を含む MD5 ダイジェストがパケットで運ばれているものと一致し, シーケンス番号が最後に受信したシーケンス番号以上である (Keyed MD5 の場合), または最後に受信したシーケンス番号より厳密に大きい (Meticulous Keyed MD5 の場合) 場合, パケットを受け入れます。

Keyed MD5 および Meticulous Keyed MD5 認証を使用した送信 (Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication)​

Auth Type フィールドは 2 (Keyed MD5) または 3 (Meticulous Keyed MD5) に設定されなければなりません (MUST)。Auth Len フィールドは 24 に設定されなければなりません (MUST)。Auth Key ID フィールドは現在の認証鍵の ID に設定されなければなりません (MUST)。Sequence Number フィールドは bfd.XmitAuthSeq に設定されなければなりません (MUST)。

認証鍵値は最大 16 バイトのバイナリ文字列であり, 必要に応じて末尾のゼロバイトでパディングして, Auth Key/Digest フィールドに配置されなければなりません (MUST)。相互運用性のために, 鍵が設定される管理インターフェースは ASCII 文字列を受け入れなければならず (MUST), 任意のバイナリ文字列を16進形式で設定できるようにもすべきです (SHOULD)。他の設定方法がサポートされてもよいです (MAY)。

MD5 ダイジェストは BFD 制御パケット全体に対して計算されなければなりません (MUST)。結果のダイジェストは, 送信前に Auth Key/Digest フィールドに格納されなければなりません (MUST) (パケットで運ばれてはならない (MUST NOT) 秘密鍵を置き換える)。

Keyed MD5 の場合, bfd.XmitAuthSeq は循環的にインクリメントされてもよいです (MAY) (符号なし 32 ビット値として扱われる場合)。bfd.XmitAuthSeq は, セッション状態が変更されたとき, または送信された BFD 制御パケットが以前に送信されたパケットと異なる内容を運ぶときにインクリメントされるべきです (SHOULD)。bfd.XmitAuthSeq をいつインクリメントするかの決定は, この仕様の範囲外です。議論については, 以下の "Security Considerations" というタイトルのセクションを参照してください。

Meticulous Keyed MD5 の場合, bfd.XmitAuthSeq は循環的にインクリメントされなければなりません (MUST) (符号なし 32 ビット値として扱われる場合)。

Keyed MD5 および Meticulous Keyed MD5 認証を使用した受信 (Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication)​

受信した BFD 制御パケットに認証セクションが含まれていない場合, または Auth Type が正しくない (Keyed MD5 の場合は 2, Meticulous Keyed MD5 の場合は 3) 場合, 受信したパケットは破棄されなければなりません (MUST)。

Auth Key ID フィールドが設定されている認証鍵の ID と一致しない場合, 受信したパケットは破棄されなければなりません (MUST)。

Auth Len フィールドが 24 と等しくない場合, パケットは破棄されなければなりません (MUST)。

bfd.AuthSeqKnown が 1 の場合, Sequence Number フィールドを検査します。Keyed MD5 の場合, シーケンス番号が bfd.RcvAuthSeq から bfd.RcvAuthSeq+(3*Detect Mult) までの範囲 (符号なし 32 ビット循環数空間として扱われる場合, 両端を含む) の外にある場合, 受信したパケットは破棄されなければなりません (MUST)。Meticulous Keyed MD5 の場合, シーケンス番号が bfd.RcvAuthSeq+1 から bfd.RcvAuthSeq+(3*Detect Mult) までの範囲 (符号なし 32 ビット循環数空間として扱われる場合, 両端を含む) の外にある場合, 受信したパケットは破棄されなければなりません (MUST)。

それ以外の場合 (bfd.AuthSeqKnown が 0), bfd.AuthSeqKnown は 1 に設定されなければならず (MUST), bfd.RcvAuthSeq は受信した Sequence Number フィールドの値に設定されなければなりません (MUST)。

Auth Key/Digest フィールドの内容を, 受信した Auth Key ID フィールドによって選択された認証鍵で置き換えます。BFD 制御パケット全体の MD5 ダイジェストが Auth Key/Digest フィールドの受信値と等しい場合, 受信したパケットは受け入れられなければなりません (MUST)。それ以外の場合 (ダイジェストが Auth Key/Digest フィールドと一致しない), 受信したパケットは破棄されなければなりません (MUST)。

6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication (Keyed SHA1 および Meticulous Keyed SHA1 認証)​

Keyed SHA1 および Meticulous Keyed SHA1 認証メカニズムは, 他のプロトコルで使用されているものと非常に似ています。これらの認証方法では, 1つ以上の秘密鍵 (対応するキー ID を持つ) が各システムで設定されます。鍵の1つは, 送信 BFD 制御パケット上で計算される SHA1 [SHA1] ハッシュに含まれますが, 鍵自体はパケットで運ばれません。リプレイ攻撃を回避するために, シーケンス番号も各パケットで運ばれます。Keyed SHA1 の場合, シーケンス番号は時折インクリメントされます。Meticulous Keyed SHA1 の場合, シーケンス番号はすべてのパケットでインクリメントされます。

受信システムは, キー ID が設定されている鍵の1つと一致し, 選択された鍵を含む SHA1 ハッシュがパケットで運ばれているものと一致し, シーケンス番号が最後に受信したシーケンス番号以上である (Keyed SHA1 の場合), または最後に受信したシーケンス番号より厳密に大きい (Meticulous Keyed SHA1 の場合) 場合, パケットを受け入れます。

Keyed SHA1 および Meticulous Keyed SHA1 認証を使用した送信 (Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication)​

Auth Type フィールドは 4 (Keyed SHA1) または 5 (Meticulous Keyed SHA1) に設定されなければなりません (MUST)。Auth Len フィールドは 28 に設定されなければなりません (MUST)。Auth Key ID フィールドは現在の認証鍵の ID に設定されなければなりません (MUST)。Sequence Number フィールドは bfd.XmitAuthSeq に設定されなければなりません (MUST)。

認証鍵値は最大 20 バイトのバイナリ文字列であり, 必要に応じて末尾のゼロバイトでパディングして, Auth Key/Hash フィールドに配置されなければなりません (MUST)。相互運用性のために, 鍵が設定される管理インターフェースは ASCII 文字列を受け入れなければならず (MUST), 任意のバイナリ文字列を16進形式で設定できるようにもすべきです (SHOULD)。他の設定方法がサポートされてもよいです (MAY)。

SHA1 ハッシュは BFD 制御パケット全体に対して計算されなければなりません (MUST)。結果のハッシュは, 送信前に Auth Key/Hash フィールドに格納されなければなりません (MUST) (パケットで運ばれてはならない (MUST NOT) 秘密鍵を置き換える)。

Keyed SHA1 の場合, bfd.XmitAuthSeq は循環的にインクリメントされてもよいです (MAY) (符号なし 32 ビット値として扱われる場合)。bfd.XmitAuthSeq は, セッション状態が変更されたとき, または送信された BFD 制御パケットが以前に送信されたパケットと異なる内容を運ぶときにインクリメントされるべきです (SHOULD)。bfd.XmitAuthSeq をいつインクリメントするかの決定は, この仕様の範囲外です。議論については, 以下の "Security Considerations" というタイトルのセクションを参照してください。

Meticulous Keyed SHA1 の場合, bfd.XmitAuthSeq は循環的にインクリメントされなければなりません (MUST) (符号なし 32 ビット値として扱われる場合)。

Keyed SHA1 および Meticulous Keyed SHA1 認証を使用した受信 (Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication)​

受信した BFD 制御パケットに認証セクションが含まれていない場合, または Auth Type が正しくない (Keyed SHA1 の場合は 4, Meticulous Keyed SHA1 の場合は 5) 場合, 受信したパケットは破棄されなければなりません (MUST)。

Auth Key ID フィールドが設定されている認証鍵の ID と一致しない場合, 受信したパケットは破棄されなければなりません (MUST)。

Auth Len フィールドが 28 と等しくない場合, パケットは破棄されなければなりません (MUST)。

bfd.AuthSeqKnown が 1 の場合, Sequence Number フィールドを検査します。Keyed SHA1 の場合, シーケンス番号が bfd.RcvAuthSeq から bfd.RcvAuthSeq+(3*Detect Mult) までの範囲 (符号なし 32 ビット循環数空間として扱われる場合, 両端を含む) の外にある場合, 受信したパケットは破棄されなければなりません (MUST)。Meticulous Keyed SHA1 の場合, シーケンス番号が bfd.RcvAuthSeq+1 から bfd.RcvAuthSeq+(3*Detect Mult) までの範囲 (符号なし 32 ビット循環数空間として扱われる場合, 両端を含む) の外にある場合, 受信したパケットは破棄されなければなりません (MUST)。

それ以外の場合 (bfd.AuthSeqKnown が 0), bfd.AuthSeqKnown は 1 に設定されなければならず (MUST), bfd.RcvAuthSeq は受信した Sequence Number フィールドの値に設定されなければならず (MUST), 受信したパケットは受け入れられなければなりません (MUST)。

Auth Key/Hash フィールドの内容を, 受信した Auth Key ID フィールドによって選択された認証鍵で置き換えます。BFD 制御パケット全体の SHA1 ハッシュが Auth Key/Hash フィールドの受信値と等しい場合, 受信したパケットは受け入れられなければなりません (MUST)。それ以外の場合 (ハッシュが Auth Key/Hash フィールドと一致しない), 受信したパケットは破棄されなければなりません (MUST)。

6.8. Functional Specifics (機能仕様)​

この仕様の以下のセクションは規範的です。この仕様が達成される手段は, この仕様の範囲外です。

システムが "the Echo function active (エコー機能がアクティブ)" であると言われる場合, それはシステムが BFD Echo パケットを送信していることを意味し, セッションが Up であり, 他のシステムが Echo パケットをループバックする意思を通知していることを示します。

ローカルシステムが "Demand mode active (デマンドモードがアクティブ)" であると言われる場合, それはローカルシステムで bfd.DemandMode が 1 であり (セクション 6.8.1 参照), セッションが Up であり, リモートシステムがセッションが Up 状態であることを通知していることを意味します。

リモートシステムが "Demand mode active (デマンドモードがアクティブ)" であると言われる場合, それは bfd.RemoteDemandMode が 1 であり (リモートシステムが最後に受信した BFD Control パケットで Demand (D) ビットを設定した), セッションが Up であり, リモートシステムがセッションが Up 状態であることを通知していることを意味します。

6.8.2. Timer Negotiation (タイマーネゴシエーション)​

BFD パケット送信間隔とセッション検出時間を決定するために使用される時間値は継続的にネゴシエートされるため, いつでも変更できます。ネゴシエーションと時間値は, 各セッションの各方向で独立しています。

各システムは, BFD Control パケットで BFD パケットをどれだけ迅速に送信したいか, およびそれらを受信する準備がどれだけ整っているかを報告します。これにより, どちらのシステムも両方向の最大パケットレート (最小間隔) を一方的に決定できます。

パケット送信タイミングとネゴシエーションの詳細については, セクション 6.8.7 を参照してください。

6.8.3. Timer Manipulation (タイマー操作)​

BFD パケット送信間隔とセッション検出時間を決定するために使用される時間値は, セッションの状態に影響を与えることなく, いつでも変更できます。タイマーパラメータが何らかの理由で変更された場合, このセクションの要件が適用されます。

bfd.DesiredMinTxInterval が変更された場合, または bfd.RequiredMinRxInterval が変更された場合, Poll Sequence を開始しなければなりません (MUST) (セクション 6.5 参照)。タイミングが, パラメータの変更を必要とする複数の変更が行われるようなものであり, それらの複数の変更が複数のパケットに分散されている場合 (返される Final のセマンティクスが不明確であるため), Poll Sequence メカニズムは曖昧です。したがって, Poll Sequence の使用を必要とする複数の変更が行われた場合, 3つの選択肢があります: 1) それらは単一の BFD Control パケットで通信されなければなりません (MUST) (Final 応答のセマンティクスが明確になるように), または 2) Poll Sequence が完了してから (最後のポールが送信されてから少なくともラウンドトリップ時間), 別の Poll Sequence の開始前に状況を明確にするのに十分な時間が経過していなければなりません, または 3) Poll Sequence が完了した後, 別の Poll Sequence の開始前に Final (F) ビットが クリア された追加の BFD Control パケットが受信されなければなりません (MUST) (このオプションは Demand mode がアクティブな場合は利用できません)。

Poll Sequence を受信しているシステムがこの段落で説明されているパラメータを変更したい場合, 新しいパラメータ値は Final (F) ビットがセットされたパケットで運ばれてもかまいません (MAY)。たとえ Poll Sequence がまだ送信されていなくても同様です。

bfd.DesiredMinTxInterval が増加し, bfd.SessionState が Up の場合, 使用される実際の送信間隔は, 上記の Poll Sequence が終了するまで変更してはなりません (MUST NOT)。これは, 送信間隔が増加する前にリモートシステムがその検出時間を更新することを保証するためです。

bfd.RequiredMinRxInterval が減少し, bfd.SessionState が Up の場合, 上記の Poll Sequence が終了するまで, bfd.RequiredMinRxInterval の前の値をリモートシステムの検出時間を計算する際に使用しなければなりません (MUST)。これは, 検出時間が減少する前に, リモートシステムがより高いレートでパケットを送信している (そしてそれらのパケットが受信されている) ことを保証するためです。

bfd.SessionState が Up でない場合, システムは bfd.DesiredMinTxInterval を1秒以上 (1,000,000マイクロ秒) の値に設定しなければなりません (MUST)。これは, Up でない BFD セッションによって消費される帯域幅が無視できることを保証することを意図しています。特に, 隣接システムが BFD を実行していない可能性がある場合です。

ローカルシステムが bfd.RemoteMinRxInterval が減少したことにより送信間隔を減少させる場合 (リモートシステムが Required Min RX Interval で減少した値をアドバタイズした), およびリモートシステムが Demand mode でない場合, ローカルシステムは新しい間隔を即座に尊重しなければなりません (MUST)。つまり, ローカルシステムは, 前のパケット送信と次のパケット送信の間に新しい間隔よりも長く待つことはできません。この間隔がすでに最後の送信から経過している場合 (新しい間隔が大幅に短いため), ローカルシステムは実行可能な限り早く次の定期的な BFD Control パケットを送信しなければなりません (MUST)。

Echo function がアクティブな場合, システムは bfd.RequiredMinRxInterval を1秒以上 (1,000,000マイクロ秒) の値に設定すべきです (SHOULD)。これは, 実際の検出機能が BFD Echo パケットを使用して実行されているため, 受信した BFD Control トラフィックを無視できるレベルに保つことを意図しています。

上記で明示的に呼び出された場合以外の場合, タイミングパラメータの変更は即座に実行されなければなりません (MUST) (送信レートおよび/または検出時間を変更します)。

Poll Sequence メカニズムは, Poll Sequence の使用を必要とする複数のパラメータ変更が行われ, それらの複数の変更が複数のパケットに分散されている場合に曖昧であることに注意してください (返される Final のセマンティクスが不明確であるため)。したがって, Poll Sequence の使用を必要とする複数の変更が行われた場合, 3つの選択肢があります: 1) それらは単一の BFD Control パケットで通信されなければなりません (MUST) (Final 応答のセマンティクスが明確になるように), または 2) Poll Sequence が完了してから状況を明確にするのに十分な時間が経過していなければなりません (最後のポールが送信されてから少なくともラウンドトリップ時間), または 3) Poll Sequence が完了した後, 別の Poll Sequence の開始前に Final (F) ビットが クリア された追加の BFD Control パケットが受信されなければなりません (MUST) (このオプションは Demand mode がアクティブな場合は利用できません)。

6.8.4. Calculating the Detection Time (検出時間の計算)​

検出時間 (BFD パケットを受信せずにセッションが失敗したと判断される期間) は, プロトコルで明示的に運ばれません。むしろ, ネゴシエートされた送信間隔と検出乗数に基づいて, 各方向で受信システムによって独立して計算されます。各方向で異なる検出時間が存在する可能性があることに注意してください。

検出時間の計算は, Demand mode と Asynchronous mode では若干異なります。

Asynchronous mode では, ローカルシステムで計算される検出時間は, リモートシステムから受信した Detect Mult の値に, リモートシステムの合意された送信間隔 (bfd.RequiredMinRxInterval と最後に受信した Desired Min TX Interval のうち大きい方) を掛けたものに等しくなります。Detect Mult 値は (ジッタのために大まかに言えば), セッションがダウンしていると宣言するために連続して失われる必要があるパケットの数です。

Demand mode がアクティブでなく, 検出時間に等しい期間がリモートシステムから BFD Control パケットを受信せずに経過し, bfd.SessionState が Init または Up の場合, セッションはダウンしています。ローカルシステムは bfd.SessionState を Down に設定し (MUST), bfd.LocalDiag を 1 (Control Detection Time Expired) に設定しなければなりません (MUST)。

Demand mode では, ローカルシステムで計算される検出時間は, bfd.DetectMult に, ローカルシステムの合意された送信間隔 (bfd.DesiredMinTxInterval と bfd.RemoteMinRxInterval のうち大きい方) を掛けたものに等しくなります。bfd.DetectMult は (ジッタのために大まかに言えば), セッションがダウンしていると宣言するために連続して失われる必要があるパケットの数です。

Demand mode がアクティブで, Poll Sequence の開始 (Poll ビットがセットされた最初の BFD Control パケットの送信) 後に検出時間に等しい期間が経過した場合, セッションはダウンしています。ローカルシステムは bfd.SessionState を Down に設定し (MUST), bfd.LocalDiag を 1 (Control Detection Time Expired) に設定しなければなりません (MUST)。

(パケットは, 検出時間の期限切れの目的で受信されたと見なされるのは, セクション 6.8.6 のルールに従って "破棄" されていない場合のみであることに注意してください)。

6.8.5. Detecting Failures with the Echo Function (エコー機能による障害検出)​

Echo function がアクティブで, 十分な数の Echo パケットが本来到着すべき時に到着しなかった場合, セッションはダウンしています。ローカルシステムは bfd.SessionState を Down に設定し (MUST), bfd.LocalDiag を 2 (Echo Function Failed) に設定しなければなりません (MUST)。

Echo function の障害が検出される手段は, この仕様の範囲外です。通信障害を検出するあらゆる手段が受け入れられます。

6.8.6. Reception of BFD Control Packets (BFD制御パケットの受信)​

BFD Control パケットが受信されると, 以下の手順が指定された順序で実行されなければなりません (MUST)。これらのルールに従ってパケットが破棄された場合, パケットの処理はその時点で停止しなければなりません (MUST)。

  • バージョン番号が正しくない (1) 場合, パケットは破棄されなければなりません (MUST)。

  • Length フィールドが最小正値 (A ビットがクリアの場合は 24, A ビットがセットの場合は 26) よりも小さい場合, パケットは破棄されなければなりません (MUST)。

  • Length フィールドがカプセル化プロトコルのペイロードよりも大きい場合, パケットは破棄されなければなりません (MUST)。

  • Detect Mult フィールドがゼロの場合, パケットは破棄されなければなりません (MUST)。

  • Multipoint (M) ビットが非ゼロの場合, パケットは破棄されなければなりません (MUST)。

  • My Discriminator フィールドがゼロの場合, パケットは破棄されなければなりません (MUST)。

  • Your Discriminator フィールドが非ゼロの場合, この BFD パケットが関連付けられているセッションを選択するために使用されなければなりません (MUST)。セッションが見つからない場合, パケットは破棄されなければなりません (MUST)。

  • Your Discriminator フィールドがゼロで, State フィールドが Down または AdminDown でない場合, パケットは破棄されなければなりません (MUST)。

  • Your Discriminator フィールドがゼロの場合, セッションは他のフィールドの組み合わせに基づいて選択されなければなりません (MUST)。これには, 送信元アドレス情報, My Discriminator フィールド, およびパケットが受信されたインターフェースが含まれる可能性があります。選択の正確な方法はアプリケーション固有であり, したがってこの仕様の範囲外です。一致するセッションが見つからない場合, 新しいセッションが作成されてもかまいません (MAY)。または, パケットが破棄されてもかまいません (MAY)。この選択は, この仕様の範囲外です。

  • A ビットがセットされており, 認証が使用されていない (bfd.AuthType がゼロ) 場合, パケットは破棄されなければなりません (MUST)。

  • A ビットがクリアされており, 認証が使用されている (bfd.AuthType が非ゼロ) 場合, パケットは破棄されなければなりません (MUST)。

  • A ビットがセットされている場合, パケットは使用されている認証タイプ (bfd.AuthType) に基づいて, セクション 6.7 のルールに従って認証されなければなりません (MUST)。これにより, パケットが破棄される可能性があります。

  • bfd.RemoteDiscr を My Discriminator の値に設定します。

  • bfd.RemoteState を State (Sta) フィールドの値に設定します。

  • bfd.RemoteDemandMode を Demand (D) ビットの値に設定します。

  • bfd.RemoteMinRxInterval を Required Min RX Interval の値に設定します。

  • Required Min Echo RX Interval フィールドがゼロの場合, Echo パケットの送信 (存在する場合) は停止しなければなりません (MUST)。

  • Poll Sequence がローカルシステムによって送信されており, 受信したパケットの Final (F) ビットがセットされている場合, Poll Sequence は終了しなければなりません (MUST)。

  • セクション 6.8.2 に記載されているように送信間隔を更新します。

  • セクション 6.8.4 に記載されているように検出時間を更新します。

  • bfd.SessionState が AdminDown の場合

    • パケットを破棄

  • 受信した状態が AdminDown の場合

    • bfd.SessionState が Down でない場合
      • bfd.LocalDiag を 3 (Neighbor signaled session down) に設定
      • bfd.SessionState を Down に設定

  • それ以外

    • bfd.SessionState が Down の場合

      • 受信した State が Down の場合
        • bfd.SessionState を Init に設定
      • それ以外で受信した State が Init の場合
        • bfd.SessionState を Up に設定

    • それ以外で bfd.SessionState が Init の場合

      • 受信した State が Init または Up の場合
        • bfd.SessionState を Up に設定

    • それ以外 (bfd.SessionState が Up)

      • 受信した State が Down の場合
        • bfd.LocalDiag を 3 (Neighbor signaled session down) に設定
        • bfd.SessionState を Down に設定

  • Demand mode がアクティブになるかどうかを確認します (セクション 6.6 参照)。

  • bfd.RemoteDemandMode が 1 で, bfd.SessionState が Up で, bfd.RemoteSessionState が Up の場合, Demand mode がリモートシステムでアクティブであり, ローカルシステムは BFD Control パケットの定期送信を停止しなければなりません (MUST) (セクション 6.8.7 参照)。

  • bfd.RemoteDemandMode が 0, または bfd.SessionState が Up でない, または bfd.RemoteSessionState が Up でない場合, Demand mode はリモートシステムでアクティブではなく, ローカルシステムは定期的な BFD Control パケットを送信しなければなりません (MUST) (セクション 6.8.7 参照)。

  • Poll (P) ビットがセットされている場合, Poll (P) ビットをクリアし, Final (F) ビットをセットして, BFD Control パケットをリモートシステムに送信します (セクション 6.8.7 参照)。

  • パケットが破棄されなかった場合, セクション 6.8.4 の検出時間期限切れルールの目的でパケットが受信されました。

6.8.7. Transmitting BFD Control Packets (BFD制御パケットの送信)​

このセクションの残りの部分にリストされている例外を除いて, システムは bfd.DesiredMinTxInterval と bfd.RemoteMinRxInterval のうち大きい方の値から適用されるジッタを引いた値 (以下参照) よりも短い間隔で BFD Control パケットを送信してはなりません (MUST NOT)。言い換えれば, より遅いレートを報告するシステムが送信レートを決定します。

BFD Control パケットの定期送信は, パケットごとに最大25%までジッタを加えなければなりません (MUST)。つまり, 同じサブネットワーク上の他のシステムとの自己同期を避けるために, 間隔は0から25%のランダムな値だけ減少されなければなりません (MUST)。したがって, パケット間の平均間隔は, ネゴシエートされた値よりも約12.5%短くなります。

bfd.DetectMult が 1 に等しい場合, 送信される BFD Control パケット間の間隔は, ネゴシエートされた送信間隔の90%以下でなければならず (MUST), ネゴシエートされた送信間隔の75%以上でなければなりません (MUST)。これは, リモートシステムで計算された検出時間が次の BFD Control パケットの受信前に経過しないことを保証するためです。

送信間隔は, bfd.DesiredMinTxInterval が変更されるか, bfd.RemoteMinRxInterval が変更されるたびに再計算されなければならず (MUST), これら2つの値のうち大きい方に等しくなります。送信タイマーの詳細については, セクション 6.8.2 および 6.8.3 を参照してください。

システムは, bfd.RemoteDiscr がゼロで, システムが Passive role を取っている場合, BFD Control パケットを送信してはなりません (MUST NOT)。

システムは, bfd.RemoteMinRxInterval がゼロの場合, 定期的に BFD Control パケットを送信してはなりません (MUST NOT)。

システムは, リモートシステムで Demand mode がアクティブ (bfd.RemoteDemandMode が 1, bfd.SessionState が Up, bfd.RemoteSessionState が Up) で, Poll Sequence が送信されていない場合, 定期的に BFD Control パケットを送信してはなりません (MUST NOT)。

Poll (P) ビットが 1 に設定された BFD Control パケットが受信された場合, 受信システムは送信タイマー, その他の送信制限, セッション状態, およびどちらのシステムで Demand mode がアクティブであるかに関係なく, 実行可能な限り早く Poll (P) ビットをクリアし Final (F) ビットをセットした BFD Control パケットを送信しなければなりません (MUST)。システムは, このようなパケットが送信されるレートを制限してもかまいません (MAY)。レート制限が有効な場合, Desired Min TX Interval のアドバタイズされた値は, レート制限機能によって課される送信パケット間の間隔以上でなければなりません (MUST)。

システムは, bfd.DemandMode が 1, bfd.SessionState が Up, bfd.RemoteSessionState が Up でない限り, Demand (D) ビットを設定してはなりません (MUST NOT)。

以前に送信されたパケット (Poll と Final ビットを除く) とは異なる内容を持つパケットが定期的な Control パケット送信間の間隔中に送信されるべきです (SHOULD)。これにより, 状態変更をより迅速に通信できます。

送信される BFD Control パケットの内容は以下のように設定されなければなりません (MUST):

Version

現在のバージョン番号 (1) に設定します。

Diagnostic (Diag)

bfd.LocalDiag に設定します。

State (Sta)

bfd.SessionState によって示される値に設定します。

Poll (P)

ローカルシステムが Poll Sequence を送信している場合は 1 に設定, そうでない場合は 0 に設定します。

Final (F)

ローカルシステムが Poll (P) ビットがセットされた受信 Control パケットに応答している場合は 1 に設定, そうでない場合は 0 に設定します。

Control Plane Independent (C)

ローカルシステムの BFD 実装がコントロールプレーンから独立している (コントロールプレーンの中断を通じて機能し続けることができる) 場合は 1 に設定します。

Authentication Present (A)

このセッションで認証が使用されている (bfd.AuthType が非ゼロ) 場合は 1 に設定, そうでない場合は 0 に設定します。

Demand (D)

bfd.SessionState が Up で bfd.RemoteSessionState が Up の場合は bfd.DemandMode に設定します。それ以外の場合は 0 に設定します。

Multipoint (M)

0 に設定します。

Detect Mult

bfd.DetectMult に設定します。

Length

固定ヘッダー長 (24) に Authentication Section を加えた適切な長さに設定します。

My Discriminator

bfd.LocalDiscr に設定します。

Your Discriminator

bfd.RemoteDiscr に設定します。

Desired Min TX Interval

bfd.DesiredMinTxInterval に設定します。

Required Min RX Interval

bfd.RequiredMinRxInterval に設定します。

Required Min Echo RX Interval

このセッションの最小必要 Echo パケット受信間隔に設定します。このフィールドがゼロに設定されている場合, ローカルシステムは BFD Echo パケットをリモートシステムにループバックすることを望まないか不可能であり, リモートシステムは Echo パケットを送信しません。

Authentication Section

認証が使用されている (bfd.AuthType が非ゼロ) 場合, セクション 6.7 のルールに従って含まれ設定されます。それ以外の場合, このセクションは存在しません。

6.8.8. Reception of BFD Echo Packets (BFDエコーパケットの受信)​

受信した BFD Echo パケットは, 処理のために適切なセッションにデマルチプレクスされなければなりません (MUST)。失われた Echo パケットを検出する手段が実装されなければならず (MUST), これは受信された Echo パケットの処理を伴う可能性が高いです。受信した Echo パケットの処理は, それ以外はこの仕様の範囲外です。

6.8.9. Transmission of BFD Echo Packets (BFDエコーパケットの送信)​

bfd.SessionState が Up でない場合, BFD Echo パケットを送信してはなりません (MUST NOT)。リモートシステムから受信した最後の BFD Control パケットの Required Min Echo RX Interval に非ゼロ値が含まれていない限り, BFD Echo パケットを送信してはなりません (MUST NOT)。

bfd.SessionState が Up の場合, BFD Echo パケットを送信してもかまいません (MAY)。送信される BFD Echo パケット間の間隔は, リモートシステムが Required Min Echo RX Interval でアドバタイズした値よりも短くてはならず (MUST NOT), ただし以下の場合を除きます:

  • 25%のジッタが送信レートに適用されてもかまいません (MAY)。実際の間隔がアドバタイズされた値の75%から100%の間になるようにします。通常のスケジュールされた Echo 送信間隔の間に, 単一の BFD Echo パケットが送信されてもかまいません (MAY)。

BFD Echo パケットの送信は, それ以外はこの仕様の範囲外です。