Zenn
🌊

RFC 4271: ボーダー・ゲートウェイ・プロトコル4 (BGP-4) part2

2024/09/10に公開
RFC
bgp
tech

8. BGP有限状態マシン (FSM)

本文書で説明するデータ構造とFSMは概念的なものであり、実装が説明している機能をサポートし、外部から見える動作が同じであれば、ここで説明しているとおりに正確に実装する必要はない。

このセクションでは、有限状態マシン(FSM)の観点からBGPの動作を規定する。このセクションは2つの部分に分けられる:

  1. ステート・マシンのイベントの説明(セクション8.1)
  2. FSMの説明(セクション8.2)

各接続に必要な(必須の)セッション属性は次のとおりである:

  1. State
  2. ConnectRetryCounter
  3. ConnectRetryTimer
  4. ConnectRetryTime
  5. HoldTimer
  6. HoldTime
  7. KeepaliveTimer
  8. KeepaliveTime

Stateセッション属性は、BGP FSMの現在の状態を示す。ConnectRetryCounterは、BGPピアがピア・セッションの確立を試みた回数を表す。

タイマーに関連する必須属性については、セクション10で説明する。各タイマーに、「Timer(タイマー)」と「Time(時間)」(初期値)がある。

オプションのセッション属性を以下に示す。これらのオプション属性は、接続ごとまたはローカル・システムごとにサポートする場合がある:

  1. AcceptConnectionsUnconfiguredPeers
  2. AllowAutomaticStart
  3. AllowAutomaticStop
  4. CollisionDetectEstablishedState
  5. DampPeerOscillations
  6. DelayOpen
  7. DelayOpenTime
  8. DelayOpenTimer
  9. IdleHoldTime
  10. IdleHoldTimer
  11. PassiveTcpEstablishment
  12. SendNOTIFICATIONwithoutOPEN
  13. TrackTcpState

オプションのセッション属性は、BGP FSMの状態遷移に影響を与えるBGP機能のさまざまな特徴をサポートする。タイマーに関連する属性の2つのグループは以下のとおりである:

グループ1: DelayOpen、DelayOpenTime、DelayOpenTimer
グループ2: DampPeerOscillations、IdleHoldTime、IdleHoldTimer

最初のパラメータ(DelayOpen、DampPeerOscillations)は、タイマー機能が有効であることを示すオプションの属性である。「時間」値は、「タイマー」(DelayOpenTime、IdleHoldTime)の初期値を指定する。「タイマー」は実際のタイマーを規定する。

これらのオプション属性とステート・マシンに通知されるイベントとの相互作用については、セクション8.1.1を参照のこと。セクション8.2.1.3では、さまざまなタイプのオプション属性(フラグまたはタイマー)の概要も簡単に説明する。

8.1. BGP FSMのイベント

8.1.1. オプション・セッション属性にリンクされたオプション・イベント

BGP FSMへの入力はイベントである。イベントは必須またはオプションのいずれかである。一部のオプション・イベントは、オプションのセッション属性に結び付いている。オプション・セッション属性は、FSM機能のいくつかのグループが有効となる。

FSM機能、イベント、オプション・セッション属性の関連性については、以下で説明する。

グループ1: 自動管理イベント (開始/停止)

  • オプション・セッション属性: AllowAutomaticStart、AllowAutomaticStop、DampPeerOscillations、IdleHoldTime、IdleHoldTimer

  • オプション1: AllowAutomaticStart

  • 説明: BGPピア接続は、管理制御によって開始および停止することができる。この管理制御は、オペレータの介入に基づく手動、またはBGP実装に固有のロジックの制御下で行うことができる。 「自動」という用語は、BGPピア接続を再起動する必要があるとロジックが判断した場合に、BGPピア接続FSMに開始を指示したことを指す。

    AllowAutomaticStart属性は、このBGP接続がBGP接続の自動起動をサポートすることを指定する。

    BGP実装がAllowAutomaticStartをサポートしている場合、ピアは繰り返し再起動する可能性がある。自動再起動が発生する頻度は、DampPeerOscillations、IdleHoldTime、IdleHoldTimerの3つのオプションで制御する。

    DampPeerOscillationsオプションは、自動開始と自動停止のシーケンスが発生した場合に、実装が追加のロジックを使用してBGPピアの振動の抑制を指定する。IdleHoldTimeは、次の自動再起動を許可する前に、BGPピアをIdle状態に保持する時間を指定する。IdleHoldTimerは、ピアをIdle状態に保持するタイマーである。

    DampPeerOscillationsロジックの例としては、BGPピアが一定期間内に接続(接続/切断)を繰り返し変動する場合、IdleHoldTime値を増やすことが挙げられる。このロジックを適用するには、ピアが5分以内に10回接続と切断を繰り返す必要がある。IdleHoldTime値は0秒から120秒にリセットされる。

  • 値: TRUEまたはFALSE

  • オプション2: AllowAutomaticStop

  • 説明: このBGPピア・セッションのオプション属性は、BGP接続が「自動」停止を許可していることを示す。「自動」停止とは、実装固有のロジックの制御下での停止と定義する。実装固有のロジックは、この仕様の範囲外である。

  • 値: TRUEまたはFALSE

  • オプション3: DampPeerOscillations

  • 説明: DampPeerOscillationsオプション・セッション属性は、BGP接続がIdle状態のBGPピアの振動を抑制するロジックを使用していることを示す。

  • 値: TRUEまたはFALSE

  • オプション4: IdleHoldTime

  • 説明: IdleHoldTimeは、IdleHoldTimerに設定する値である。

  • 値: 秒単位の時間

  • オプション5: IdleHoldTimer

  • 説明: IdleHoldTimerは、BGPピアの振動の制御に役立つ。IdleHoldTimerはある期間、BGPピアをIdle状態に保つために使用する。IdleHoldTimer_Expiresイベントは、セクション8.1.3で説明している。

  • 値: 秒単位の時間

グループ2: 未設定のピア

  • オプション・セッション属性: AcceptConnectionsUnconfiguredPeers
  • オプション1: AcceptConnectionsUnconfiguredPeers
  • 説明: BGP FSMは、事前設定されていないネイバーのBGPピア接続をオプションで受け入れることを許可する。オプション・セッション属性「AcceptConnectionsUnconfiguredPeers」により、FSMは、実装がこれらの未設定ピアの接続を受け入れるか拒否するかを可能にする状態遷移をサポートできる。

    AcceptConnectionsUnconfiguredPeersにはセキュリティ上の影響がある。詳細は、BGPの脆弱性に関する文書[RFC4272]を参照のこと。
  • 値: TrueまたはFalse

グループ3: TCP処理

  • オプション・セッション属性: PassiveTcpEstablishment、TrackTcpState

  • オプション1: PassiveTcpEstablishment

  • 説明: このオプションは、リモートBGPピアがBGP TCP 接続を確立するまで、BGP FSMが受動的に待機することを示す。

  • 値: TRUEまたはFALSE

  • オプション2: TrackTcpState

  • 説明: BGP FSMは通常、個々のTCPメッセージではなく、TCP接続試行の最終結果を追跡する。オプションで、BGP FSMはTCP接続ネゴシエーションとの追加のやり取りをサポートできる。TCPイベントとのやり取りによって、BGPピア接続に必要なログの量やBGP FSMの遷移回数が増える可能性がある。

  • 値: TRUEまたはFALSE

グループ4: BGPメッセージ処理

  • オプション・セッション属性: DelayOpen、DelayOpenTime、DelayOpenTimer、SendNOTIFICATIONwithoutOPEN、CollisionDetectEstablishedState

  • オプション1: DelayOpen

  • 説明: DelayOpenオプション・セッション属性は、実装に対してOPENメッセージの送信をある時間 (DelayOpenTime)遅らせる設定ができる。この遅延によって、リモートBGPピアは最初のOPENメッセージを送信する時間を確保できる。

  • 値: TRUEまたはFALSE

  • オプション2: DelayOpenTime

  • 説明: DelayOpenTimeは、DelayOpenTimerに設定する初期値である。

  • 値: 秒単位の時間

  • オプション3: DelayOpenTimer

  • 説明: DelayOpenTimerオプション・セッション属性は、接続上でのOPENメッセージの送信を遅らせるために使用する。DelayOpenTimer_Expiresイベント(イベント12)については、セクション8.1.3で説明する。

  • 値: 秒単位の時間

  • オプション4: SendNOTIFICATIONwithoutOPEN

  • 説明: SendNOTIFICATIONwithoutOPENは、最初にOPENメッセージを送信せずにNOTIFICATIONを送信することができる。このオプション・セッション属性がない場合、BGP接続は、ピアがNOTIFICATIONメッセージを送信する前に、ピアからOPENメッセージが送信しなければならないと想定する。

  • 値: TrueまたはFalse

  • オプション5: CollisionDetectEstablishedState

  • 説明: 通常、Established状態では衝突検出(セクション6.8を参照)を無視する。このオプション・セッション属性は、このBGP接続がEstablished状態で衝突を処理することを示す。

  • 値: TrueまたはFalse

注記: オプション・セッション属性は、BGP実装の既存の機能に対するBGP FSMの説明を明確にする。オプション・セッション属性は、実装に対してあらかじめ定義されていて、既存の正しい実装のための管理インタフェースを介して読み取ることができない場合がある。新しいBGP MIB(バージョン2以降)がサポートされるようになると、これらのフィールドは管理インタフェースからアクセスできるようになる。

8.1.2. 管理イベント

管理イベントは、オペレータ・インタフェースとBGPポリシー・エンジンがBGP有限状態マシンに、BGP状態マシンを開始または停止するよう信号を送るイベントである。基本的な開始と停止の指示は、BGP FSMに特定のタイプの開始または停止メカニズムを通知するオプション接続属性によって補強される。この組み合わせの例は、イベント5、AutomaticStart_with_PassiveTcpEstablishmentである。このイベントで、BGP実装はBGP FSMに、実装がパッシブTCP確立を使用するオプションを持つ自動開始を使用していることを通知する。パッシブTCP確立は、このBGP FSMがリモート側にTCP確立を開始するのを待機することを通知する。

イベント1 (ManualStart)とイベント2 (ManualStop)のみが必須の管理イベントであることに留意すること。他のすべての管理イベントはオプションである(イベント3～8)。以下の各イベントは、名前、定義、ステータス(必須またはオプション)、および各ステージで設定する必要があるオプション・セッション属性を持つ。BGP FSMのイベント1～8を生成するとき、「オプション属性ステータス」セクションで指定された条件を検証する。これらの条件のいずれかが満たされない場合、ローカル・システムはFSMエラーをログに記録する必要がある。

オプション・セッション属性の設定は、実装によっては暗黙的なものである場合があり、したがって、外部オペレータの操作によって明示的に設定されないかもしれない。セクション8.2.1.5では、オプション・セッション属性の暗黙的な設定について説明する。以下で説明する管理状態も、実装によっては暗黙的なものの場合があり、外部オペレータが直接設定することはできない。

イベント1: ManualStart

  • 定義: ローカル・システムの管理者が手動でピア接続を開始する。
  • ステータス: 必須
  • オプション属性ステータス: PassiveTcpEstablishment属性はFALSEに設定する必要がある(SHOULD)。

イベント2: ManualStop

  • 定義: ローカル・システム管理者が手動でピア接続を停止する。
  • ステータス: 必須
  • オプション属性ステータス: オプション属性とのやり取りはない。

イベント3: AutomaticStart

  • 定義: ローカル・システムが自動的にBGP接続を開始する。
  • ステータス: オプション(ローカル・システムによって異なる)
  • オプション属性ステータス:
    1. このイベントが発生した場合、AllowAutomaticStart属性はTRUEに設定する必要がある(SHOULD)。
    2. PassiveTcpEstablishmentオプション・セッション属性がサポートされている場合は、FALSEに設定する必要がある(SHOULD)。
    3. DampPeerOscillationsがサポートされている場合、このイベントが発生したときにFALSEに設定する必要がある(SHOULD)。

イベント4: ManualStart_with_PassiveTcpEstablishment

  • 定義: ローカル・システム管理者が手動でピア接続を開始したが、PassiveTcpEstablishmentが有効になっている。PassiveTcpEstablishmentオプション属性は、ピアが接続を確立する前に待機することを示す。
  • ステータス: オプション、ローカル・システムによって異なる。
  • オプション属性ステータス:
    1. このイベントが発生した場合、PassiveTcpEstablishment属性は TRUEに設定する必要がある(SHOULD)。
    2. このイベントが発生した場合、DampPeerOscillations属性はFALSEに設定する必要がある(SHOULD)。

イベント5: AutomaticStart_with_PassiveTcpEstablishment

  • 定義: ローカル・システムは、PassiveTcpEstablishmentを有効にしてBGP接続を自動的に開始する。PassiveTcpEstablishmentオプション属性は、ピアが接続を確立する前に待機することを示す。
  • ステータス: オプション、ローカル・システムによって異なる
  • オプション属性ステータス:
    1. AllowAutomaticStart属性はTRUEに設定する必要がある(SHOULD)。
    2. PassiveTcpEstablishment属性はTRUEに設定する必要がある(SHOULD)。
    3. DampPeerOscillations属性がサポートされている場合、DampPeerOscillationsはFALSE に設定する必要がある(SHOULD)。

イベント6: AutomaticStart_with_DampPeerOscillations

  • 定義: ローカル・システムは、ピア振動減衰を有効にして、BGPピア接続を自動的に開始する。持続的なピア振動を減衰させる厳密な方法は実装が決定し、本文書の範囲外である。
  • ステータス: オプション(ローカル・システムによって異なる)。
  • オプション属性ステータス:
    1. AllowAutomaticStart属性はTRUEに設定する必要がある(SHOULD)。
    2. DampPeerOscillations属性はTRUEに設定する必要がある(SHOULD)。
    3. PassiveTcpEstablishment 属性はFALSEに設定する必要がある(SHOULD)。

イベント7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment

  • 定義: ローカル・システムは、ピア振動減衰が有効で、PassiveTcpEstablishmentが有効になっている状態で、BGPピア接続を自動的に開始する。持続的なピアの振動を減衰させる正確な方法は実装が決定し、本文書の範囲外である。
  • ステータス: オプション、ローカル・システムによって異なる
  • オプション属性ステータス:
    1. AllowAutomaticStart 属性はTRUEに設定する必要がある(SHOULD)。
    2. DampPeerOscillations 属性はTRUEに設定する必要がある(SHOULD)。
    3. PassiveTcpEstablishment 属性はTRUEに設定する必要がある(SHOULD)。

イベント8: AutomaticStop

  • 定義: ローカル・システムはBGP接続を自動的に停止する。
    自動停止イベントの例としては、ピアのプレフィックス数の上限を超え、ローカル・システムが自動的にピアを切断することが挙げられる。
  • ステータス: ローカル・システムに応じてオプション
  • オプション属性ステータス:
    1. AllowAutomaticStop 属性はTRUEに設定する必要がある(SHOULD)。

8.1.3. タイマー・イベント

イベント9: ConnectRetryTimer_Expires

  • 定義: ConnectRetryTimerの有効期限が切れたときに生成するイベント。
  • ステータス: 必須

イベント10: HoldTimer_Expires

  • 定義: ホールド時間の有効期限が切れたときに生成するイベント。
  • ステータス: 必須

イベント11: KeepaliveTimer_Expires

  • 定義: キープアライブ・タイマーの有効期限が切れたときに生成するイベント。
  • ステータス: 必須

イベント12: DelayOpenTimer_Expires

  • 定義: DelayOpenTimerの有効期限が切れたときに生成するイベント。
  • ステータス: オプション
  • オプション属性ステータス: このイベントが発生した場合、
    1. DelayOpen 属性をTRUEに設定する必要がある(SHOULD)。
    2. DelayOpenTime 属性をTRUEにサポートする必要がある(SHOULD)。
    3. DelayOpenTimerをTRUEにサポートする必要がある(SHOULD)。

イベント13: IdleHoldTimer_Expires

  • 定義: IdleHoldTimerの有効期限が切れたときに生成するイベント。これは、BGP接続がBGPピアの振動を防止するためのバックオフ期間の待機を完了したことを示す。

    IdleHoldTimerは、DampPeerOscillationsオプション属性をTRUEに設定することで、永続的なピア振動減衰機能が有効になっている場合にのみ使用する。

    永続的なピア振動減衰機能を実装していない実装は、IdleHoldTimerを持たない場合がある。
  • ステータス: オプション
  • オプション属性ステータス: このイベントが発生した場合:
    1. DampPeerOscillations 属性をTRUEに設定する必要がある(SHOULD)。
    2. IdleHoldTimerがちょうど期限切れになっている必要がある(SHOULD)。

8.1.4. TCP接続ベースのイベント

イベント14: TcpConnection_Valid

  • 定義: 有効な送信元IPアドレス、送信元TCPポート、宛先IPアドレス、宛先TCPポートを持つTCP接続リクエストをローカル・システムが受信したことを示すイベント。無効な送信元IPアドレスと無効な宛先IPアドレスの定義は、実装によって決まる。

    BGPの宛先ポートは、IANAが定義しているように、ポート179の必要がある(SHOULD)。

    TCP接続リクエストは、ローカル・システムがTCP SYNを受信したことを意味する。
  • ステータス: オプション
  • オプション属性ステータス:
    1. このイベントが発生した場合、TrackTcpState属性はTRUEに設定する必要がある(SHOULD)。

イベント15: Tcp_CR_Invalid

  • 定義: 無効な送信元アドレスまたはポート番号、あるいは無効な宛先アドレスまたはポート番号のいずれかを持つTCP接続リクエストをローカル・システムが受信したことを示すイベント。

    BGP宛先ポート番号は、IANAが定義しているように、ポート179の必要がある(SHOULD)。

    TCP接続リクエストは、ローカル・システムがTCP SYNを受信するときに発生する。
  • ステータス: オプション
  • オプション属性ステータス:
    1. このイベントが発生した場合、TrackTcpState属性はTRUEに設定する必要がある(SHOULD)。

イベント16: Tcp_CR_Acked

  • 定義: ローカル・システムがリモート・ピアとのTCP接続を確立する要求を示すイベント。

    ローカル・システムのTCP接続はTCP SYNを送信し、TCP SYN/ACKメッセージを受信し、TCP ACKを送信した。
  • ステータス: 必須

イベント17: TcpConnectionConfirmed

  • 定義: ローカル・システムが、リモート・サイトからのTCP接続が確立されたことの承認を受信したことを示すイベント。

    リモート・ピアのTCPエンジンがTCP SYNを送信した。ローカル・ピアのTCPエンジンが SYN、ACKメッセージを送信し、最終的なACKを受信した。
  • ステータス: 必須

イベント18: TcpConnectionFails

  • 定義: ローカル・システムがTCP接続失敗通知を受信したことを示すイベント。

    リモートBGPピアのTCPマシンがFINを送信した可能性がある。ローカル・ピアはFIN-ACKで応答する。もう一つの可能性としては、ローカル・ピアがTCP接続のタイムアウトを示し、接続をダウンさせたことが考えられる。
  • ステータス: 必須

8.1.5. BGPメッセージに基づくイベント

イベント19: BGPOpen

  • 定義: 有効なOPENメッセージを受信するとイベントが生成される。
  • ステータス: 必須
  • オプション属性ステータス:
    1. DelayOpenオプション属性はFALSEに設定する必要がある(SHOULD)。
    2. DelayOpenTimerは実行すべきではない(SHOULD NOT)。

イベント20: DelayOpenTimerが実行中のBGPOpen

  • 定義: このイベントは、正常に確立されたトランスポート接続を持ち、現在BGP Openメッセージの送信を遅延しているピアに対して、有効なOPENメッセージが受信されたときに生成される。
  • ステータス: オプション
  • オプション属性ステータス:
    1. DelayOpen 属性はTRUEに設定する必要がある(SHOULD)。
    2. DelayOpenTimerは実行されている必要がある(SHOULD)。

イベント21: BGPHeaderErr

  • 定義: 受信したBGPメッセージ・ヘッダが有効でない場合、イベントが生成される。
  • ステータス: 必須

イベント22: BGPOpenMsgErr

  • 定義: OPENメッセージがエラーを伴って受信されたときにイベントが生成される。
  • ステータス: 必須

イベント23: OpenCollisionDump

  • 定義: 受信OPENメッセージの処理中に接続衝突が検出され、この接続を切断するように選択した場合に管理上生成されるイベント。衝突検出の詳細については、セクション6.8を参照のこと。

    イベント23は、セクション6.8のルールに従ってこの接続を切断する必要があるかどうかを判断する実装ロジックによって生成される管理アクションである。このイベントは、FSMが2つのリンクされたステート・マシンとして実装されている場合に発生する可能性がある。
  • ステータス: オプション
  • オプション属性ステータス: ステート マシンがEstablished状態で、このイベントを処理する場合、
    1. CollisionDetectEstablishedStateオプション属性をTRUEに設定する必要がある(SHOULD)。

注意: OpenCollisionDumpイベントは、オプション属性が設定されていなくても、Idle、Connect、Active、OpenSent、OpenConfirmで発生する可能性がある。

イベント24: NotifMsgVerErr

  • 定義: 「バージョン・エラー」のNOTIFICATIONメッセージを受信し、イベントが生成される。
  • ステータス: 必須

イベント25: NotifMsg

  • 定義: NOTIFICATIONメッセージを受信し、エラー・コードが「バージョン・エラー」以外の場合、イベントが生成される。
  • ステータス: 必須

イベント26: KeepAliveMsg

  • 定義: KEEPALIVEメッセージを受信し、イベントが生成される。
  • ステータス: 必須

イベント27: UpdateMsg

  • 定義: 有効なUPDATEメッセージを受信し、イベントが生成される。
  • ステータス: 必須

イベント28: UpdateMsgErr

  • 定義: 無効なUPDATEメッセージを受信し、イベントが生成される。
  • ステータス: 必須

8.2. FSMの説明

8.2.1. FSMの定義

BGPは、設定されたピアごとに個別のFSMを維持しなければならない(MUST)。潜在的な接続でペアを組んだ各BGPピアは、Idle状態を維持するように設定されていない限り、またはパッシブ状態を維持するよう設定されていない限り、他のピアへの接続を試みる。この説明では、TCP接続のアクティブ側または接続側(最初のTCP SYNパケットを送信するTCP接続の側)を発信と呼ぶ。パッシブ側またはリスニング側(最初のSYN/ACKの送信側)は、着信接続と呼ぶ。(以下で使用されるアクティブとパッシブという用語の詳細については、セクション8.2.1.1を参照のこと。)

BGP実装は、ピアへの接続を試みることに加えて、着信接続用にTCPポート179に接続し、接続を待機しなければならない(MUST)。各着信接続に対し、状態マシンはインスタンス化しなければならない(MUST)。着信接続の相手側のピアの識別子は分かっているが、BGP識別子は分からない期間が存在する。この間、同じ設定のピアリングに対して、着信接続と発信接続の両方が存在することがある。これを接続衝突と呼ぶ(セクション6.8を参照)。

BGP実装は、設定されたピアリングごとに最大1つのFSMがあり、ピアがまだ識別されていない着信TCP接続ごとに1つのFSMを持つ。各FSMは、正確に1つのTCP接続に対応する。

接続が異なるIPアドレスのペアを使用するように設定されている場合、ピアのペア間に複数の接続が存在する可能性がある。これは、同じピアに対する複数の「設定済みピアリング」と呼ぶ。

8.2.1.1. 「アクティブ」と「パッシブ」という用語

アクティブとパッシブという用語は、ほぼ10年前からインターネット・オペレータの語彙に存在し、有用であることが証明されている。アクティブとパッシブという言葉は、TCP接続やピアに適用される場合、少し意味が異なる。上記の定義と以下の状態マシンに従って、1つのTCP接続にはアクティブ側とパッシブ側が1つずつしかない。BGPスピーカーがアクティブに構成されている場合、最終的に確立される接続のアクティブ側またはパッシブ側のどちらかになる。TCP接続が完了すると、どちらがアクティブで、どちらがパッシブだったかは問題にならない。唯一の違いは、TCP接続のどちらがポート番号179を持つかである。

8.2.1.2. FSMと衝突検出

BGP接続ごとに1つのFSMが存在する。接続がどのピアに関連付けられているかを判断する前に接続衝突が起こると、1つのピアに対して2つの接続が存在する可能性がある。接続衝突が解決された後(セクション6.8を参照)、クローズされた接続のFSMは破棄する必要がある(SHOULD)。

8.2.1.3. FSMとオプション・セッション属性

オプション・セッション属性は、フラグとして機能する属性(TRUEまたはFALSE)またはオプションのタイマーを指定する。フラグとして機能するオプション属性の場合、システム上でオプションのセッション属性がTRUEに設定できる場合、対応するBGP FSMアクションがサポートされていなければならない。例えば、BGP実装でAutoStartとPassiveTcpEstablishmentのオプションを設定できる場合、イベント3、4、5をサポートしなければならない。オプション・セッション属性をTRUEに設定できない場合は、そのオプション・セットをサポートするイベントをサポートする必要はない。

オプションのタイマー(DelayOpenTimerとIdleHoldTimer)には、それぞれ以下の属性のグループがある:

  • サポートを示すフラグ
  • タイマーに設定された時間
  • タイマー

2つのオプション・タイマーは以下の形式を示す:

DelayOpenTimer: DelayOpen、DelayOpenTime、DelayOpenTimer
IdleHoldTimer: DampPeerOscillations、IdleHoldTime、IdleHoldTimer

オプションのタイマー(DelayOpenまたはDampPeerOscillations)のサポートを示すフラグをTRUEに設定できない場合、そのオプションをサポートするタイマーとイベントをサポートする必要はない。

8.2.1.4. FSMイベント番号

この状態マシンの説明で使用されるイベント番号(1～28)は、BGP状態マシンの動作を指定するのに役立つ。実装は、ネットワーク管理情報を提供するためにこれらの番号を使用することができる(MAY)。FSMまたはFSMイベントの正確な形式は、各実装に固有である。

8.2.1.5. 実装に依存するFSMアクション

ある時点で、BGP FSMはBGPの初期化が行われるか、BGPリソースが削除されることを指定する。BGP FSMの初期化と関連リソースは、BGP実装のポリシー部分に依存する。これらのアクションの詳細は、FSM文書の範囲外である。

8.2.2. 有限状態マシン

⚠️ BGP有限状態マシン

bgp-fsm-2

BGP有限状態マシンは、以下の6つの状態で構成されている:

  1. Idle (アイドル): BGPセッションが開始されていない状態。この状態ではBGPは何もせず、次のイベントを待機する。セッションを確立するためにTCP接続を開こうとするか、管理者が明示的にセッションをリセットした場合にこの状態に戻る。
  2. Connect (接続): この状態は、BGPはTCP接続を確立しようとする。接続が成功すれば次の「OpenSent」に進む。接続が失敗した場合はタイマーが起動し、リトライする。
  3. Active (アクティブ): TCP接続の試行が再び行われる状態。接続が確立すれば「OpenSent」状態に進むが、再度失敗した場合、リトライを試みるか「Idle」状態に戻る。
  4. OpenSent (オープン送信): TCP接続が成功した後、BGPの「OPENメッセージ」を送信し、相手からの「OPENメッセージ」を待つ状態。相手のOPENメッセージを受信したら、次の「OpenConfirm」状態に進む。
  5. OpenConfirm (オープン確認): OPENメッセージを相互に交換し、BGPピアが接続確認 (Keepaliveメッセージ)を待つ状態。Keepaliveメッセージが正常に交換されると、BGPピアリングが確立され、「Established」状態に進む。
  6. Established (確立): BGPピア間で経路情報を交換できる状態。この状態では、BGPピア同士が定期的にKeepaliveメッセージを交換し、経路アップデート情報をやり取りする。何らかの理由で接続が切断されると、FSMは再び「Idle」状態に戻る。

Idle状態:

初期状態では、BGPピアのFSMはIdle状態である。これ以降、BGPピアのFSMはBGP FSMと略すこととする。

この状態では、BGP FSMはこのピアに対するすべての着信BGP接続を拒否する。このピアにリソースが割り当てられない。ManualStartイベント(イベント1)またはAutomaticStartイベント (イベント3)に応答し、ローカル・システムは以下の処理を実行する。

  • ピア接続のすべてのBGPリソースを初期化する、
  • ConnectRetryCounterをゼロに設定する、
  • ConnectRetryTimerを初期値で開始する、
  • 他のBGPピアへのTCP接続を開始する、
  • リモート・ピアが開始する可能性のある接続を待機する、
  • 状態をConnectに変更する。

ManualStopイベント(イベント2)とAutomaticStop (イベント8)イベントは、Idle状態では無視する。

ManualStart_with_PassiveTcpEstablishmentイベント (イベント4)または AutomaticStart_with_PassiveTcpEstablishmentイベント(イベント5)に応答して、ローカル・システムは以下の処理を実行する。

  • すべての BGPリソースを初期化する、
  • ConnectRetryCounterをゼロに設定する、
  • ConnectRetryTimerを初期値で開始する、
  • リモート・ピアが開始する可能性のある接続を待機する、
  • 状態をActiveに変更する。

ConnectRetryTimerの正確な値はローカルの問題だが、TCPの初期化を可能にするのに十分な大きさにする必要がある(SHOULD)。

DampPeerOscillations属性がTRUEに設定されている場合、Idle状態で以下の3つの追加イベントが発生する可能性がある。

  • AutomaticStart_with_DampPeerOscillations (イベント6)、
  • AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment (イベント7)、
  • IdleHoldTimer_Expires (イベント13)。

これらの3つのイベントを受信すると、ローカル・システムはこれらのイベントを使用してピアの振動を防ぐ。ピアの持続的な振動を防ぐ方法は、本文書の範囲外である。

Idle状態で受信した他のイベント(イベント9～12、15～28)は、ローカル・システムの状態を変化させない。

Connect状態:

この状態では、BGP FSMはTCP接続が完了するのを待機する。

Connect状態では開始イベント(イベント1、3～7)を無視する。

ManualStopイベント(イベント2)に応答して、ローカル・システムは以下の操作を実行する。

  • TCP 接続を切断する、
  • すべてのBGPリソースを解放する、
  • ConnectRetryCounterをゼロに設定する、
  • ConnectRetryTimerを停止し、ConnectRetryTimerをゼロに設定する、
  • 状態をIdleに変更する。

ConnectRetryTimer_Expiresイベント(イベント9)に応答して、ローカル・システムは以下の処理を実行する。

  • TCP 接続を切断する、
  • ConnectRetryTimerを再起動する、
  • DelayOpenTimerを停止し、タイマーをゼロにリセットする、
  • 他のBGPピアへのTCP接続を開始する、
  • リモートBGPピアによって開始される可能性のある接続をリッスンし続ける、
  • Connect状態を維持する。

Connect状態でDelayOpenTimer_Expiresイベント(イベント12)が発生した場合、ローカル・システムは以下の処理を実行する。

  • ピアにOPEN メッセージを送信する、
  • HoldTimerを大きな値に設定する、
  • 状態をOpenSentに変更する。

BGP FSMがTcpConnection_Validイベント(イベント14)を受信すると、TCP接続が処理され、接続はConnect状態のままとなる。

BGP FSMがTcp_CR_Invalidイベント(イベント15)を受信すると、ローカル・システムはTCP接続を拒否し、接続はConnect状態を維持する。

TCP接続が成功した場合(イベント16またはイベント17)、ローカル・システムは処理の前にDelayOpen属性をチェックする。DelayOpen属性がTRUEに設定されている場合、ローカル・システムは以下の処理を行う。

  • ConnectRetryTimer(実行中の場合)を停止し、ConnectRetryTimerをゼロに設定する、
  • DelayOpenTimerを初期値に設定する、
  • Connect状態を維持する。

DelayOpen属性がFALSEに設定されている場合、ローカル・システムは以下の処理を行う。

  • ConnectRetryTimer(実行中の場合)を停止し、ConnectRetryTimerをゼロに設定する、
  • BGPの初期化を完了する、
  • OPENメッセージをピアに送信する、
  • HoldTimerを大きな値に設定する、
  • 状態をOpenSentに変更する。

HoldTimer値は4分を推奨する。

TCP接続が失敗した場合(イベント18)、ローカル・システムはDelayOpenTimerをチェックする。DelayOpenTimerが実行中の場合、ローカル・システムは以下を実行する。

  • ConnectRetryTimerを初期値で再起動する、
  • DelayOpenTimerを停止し、その値をゼロにリセットする、
  • リモートBGPピアによって開始される可能性のある接続の待機を継続する、
  • 状態をActiveに変更する。

DelayOpenTimerが実行中でない場合、ローカル・システムは以下を実行する。

  • ConnectRetryTimerをゼロに停止する、
  • TCP接続を切断する、
  • すべてのBGP リソースを解放する、
  • 状態をIdleに変更する。

DelayOpenTimerの実行中にOPENメッセージが受信された場合(イベント20)、ローカル・システムは以下の処理を実行する。

  • ConnectRetryTimer(実行中の場合)を停止し、ConnectRetryTimerをゼロに設定する、
  • BGPの初期化を完了する、
  • DelayOpenTimerを停止してクリアする(値をゼロに設定する)、
  • OPENメッセージを送信する、
  • KEEPALIVEメッセージを送信する、
  • HoldTimerの初期値がゼロ以外の場合、
    • KeepaliveTimerを初期値で開始する、
    • HoldTimerをネゴシエートされた値にリセットする、
  • そうでなければ、HoldTimerの初期値がゼロの場合、
    • KeepaliveTimerをリセットする、
    • HoldTimer値をゼロにリセットする、
  • そして、状態をOpenConfirmに変更する。

自律システム・フィールドの値がローカル自律システム番号と同じ場合、Connectステータスを内部接続に設定する。それ以外の場合は、「外部」となる。

BGPメッセージ・ヘッダのチェック(イベント21)またはOPENメッセージのチェックでエラー(イベント22)を検出した場合(セクション6.2を参照)、ローカル・システムは以下を実行する。

  • (オプション)SendNOTIFICATIONwithoutOPEN属性がTRUEに設定されている場合、ローカル・システムは最初に適切なエラー コードを含むNOTIFICATIONメッセージを送信し、その後、
  • ConnectRetryTimer(実行中の場合)を停止し、ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

バージョン・エラー(イベント24)を含むNOTIFICATIONメッセージが受信した場合、ローカル・システムはDelayOpenTimerをチェックする。DelayOpenTimerが実行中の場合、ローカル・システムは以下を実行する。

  • ConnectRetryTimer(実行中の場合)を停止し、ConnectRetryTimerをゼロに設定する、
  • DelayOpenTimerを停止してリセットする(ゼロに設定)、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • 状態をIdleに変更する。

DelayOpenTimerが実行されていない場合、ローカルシステムは以下の処理を実行する:

  • ConnectRetryTimerを停止し、ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する。
  • DampPeerOscillations属性がTrueに設定されている場合、ピア振動減衰を実行する。
  • 状態をIdleに変更する。

その他のイベント(イベント8、10-11、13、19、23、25-28)に応答して、ローカル・システムは以下の処理を実行する。

  • ConnectRetryTimerが実行中の場合は、ConnectRetryTimerを停止してリセットする(ゼロに設定)、
  • DelayOpenTimerが実行中の場合、DelayOpenTimerを停止してリセットする(ゼロに設定)、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • DampPeerOscillations属性がTrueに設定されている場合、ピア振動減衰を実行する。
  • 状態をIdleに変更する。

Active状態:

この状態では、BGP FSMはTCP接続をリッスンして受け入れることで、ピアの獲得を試みる。

Active状態では、開始イベント(イベント1、3-7)は無視される。

ManualStopイベント(イベント2)に応答して、ローカル・システムは以下の処理を実行する。

  • DelayOpenTimerが実行中でSendNOTIFICATIONwithoutOPENセッション属性が設定されている場合、ローカル・システムはCeaseを含むNOTIFICATIONを送信する、
  • DelayOpenTimerの停止を含むすべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterをゼロに設定する、
  • ConnectRetryTimerを停止し、ConnectRetryTimerをゼロに設定する、
  • 状態をIdleに変更する。

ConnectRetryTimer_Expiresイベント(イベント9)に応答して、ローカル・システムは以下の処理を実行する。

  • ConnectRetryTimerを(初期値で)再起動する、
  • 他のBGPピアへのTCP接続を開始する、
  • リモートBGPピアによって開始される可能性のあるTCP接続を待機を続ける、
  • 状態をConnectに変更する。

ローカル・システムがDelayOpenTimer_Expiresイベント(イベント12)を受信した場合、ローカル・システムは以下の処理を実行する。

  • ConnectRetryTimerをゼロに設定する、
  • DelayOpenTimerを停止してクリアする(ゼロに設定)、
  • BGP初期化を完了する、
  • OPENメッセージをリモート・ピアに送信する、
  • HoldTimerを大きな値に設定する、
  • 状態をOpenSentに変更する。

この状態遷移には、4分のHoldTimer値を推奨する。

ローカル・システムがTcpConnection_Validイベント(イベント14)を受信すると、ローカル・システムはTCP接続フラグを処理し、Active状態に留まる。

ローカル・システムがTcp_CR_Invalidイベント(イベント15)を受信した場合、ローカル・システムはTCP接続を拒否し、Active状態に留まる。

TCP接続の成功(イベント16またはイベント17)に応じて、ローカル・システムは処理の前にDelayOpenオプション属性をチェックする。

DelayOpen属性がTRUEに設定されている場合、ローカル・システムは以下の処理を行う。

  • ConnectRetryTimerを停止し、ConnectRetryTimerをゼロに設定する、
  • DelayOpenTimerを初期値(DelayOpenTime)に設定する、
  • Active状態を維持する。
    DelayOpen属性がFALSEに設定されている場合、ローカル・システムは以下の処理を行う。
  • ConnectRetryTimerをゼロに設定する、
  • BGP初期化を完了する、
  • OPENメッセージをピアに送信する、
  • HoldTimerを大きな値に設定する、
  • 状態をOpenSentに変更する。

HoldTimerの「大きな値」として、4分のHoldTimer値を推奨する。

ローカル・システムがTcpConnectionFailsイベント(イベント18)を受信すると、ローカル・システムは以下の処理を行う:

  • ConnectRetryTimerを(初期値で)再起動する、
  • DelayOpenTimerを停止してクリアする(値をゼロに設定する)。
  • すべてのBGPリソースを解放する、
  • ConnectRetryCounterを1増分する、
  • DampPeerOscillations属性がTRUEに設定されている場合、オプションでピア振動減衰を実行する、
  • 状態をIdleに変更する。

OPENメッセージを受信し、DelayOpenTimerが実行中の場合(イベント20)、ローカル・システムは以下の処理を行う:

  • ConnectRetryTimer(実行中の場合)を停止し、ConnectRetryTimerをゼロに設定する、
  • DelayOpenTimerを停止してクリア(ゼロに設定する)、
  • BGP初期化を完了する、
  • OPENメッセージを送信する、
  • KEEPALIVEメッセージを送信する、
  • HoldTimer値がゼロではない場合、
    • KeepaliveTimerを初期値に戻す、
    • HoldTimerをネゴシエートされた値にリセットする、
  • HoldTimerがゼロの場合、
    • KeepaliveTimerをリセット(ゼロに設定)する、
    • HoldTimerをゼロにリセットする、
  • 状態をOpenConfirmに変更する。

自律システム・フィールドの値がローカル自律システム番号と同じ場合、接続ステータスを内部接続に設定する。それ以外の場合は外部接続となる。

BGPメッセージ・ヘッダ・チェック(イベント21)またはOPENメッセージ・チェックでエラーが検出された場合(イベント22)(セクション6.2を参照)、ローカル・システムは以下の処理を行う。

  • (オプション)SendNOTIFICATIONwithoutOPEN属性がTRUEに設定されている場合、適切なエラーコードを含むNOTIFICATIONメッセージを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

バージョン・エラー(イベント24)を含むNOTIFICATIONメッセージを受信した場合、ローカル・システムはDelayOpenTimerをチェックする。DelayOpenTimerが実行中の場合、ローカル・システムは以下の処理を行う:

  • ConnectRetryTimer(実行中の場合)を停止し、ConnectRetryTimerをゼロに設定する、
  • DelayOpenTimerを停止してリセットする(ゼロに設定する)。
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • 状態をIdleに変更する。

DelayOpenTimerが実行中ではない場合、ローカル・システムは以下の処理を行う:

  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

その他のイベント(イベント8、10-11、13、19、23、25-28)に応答して、ローカル・システムは以下の処理を実行する。

  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

OpenSent状態:

この状態では、BGP FSMはピアからのOPENメッセージを待機する。

OpenSent状態では、開始イベント(イベント1、3-7)は無視される。

ManualStopイベント(イベント2)が OpenSent状態で発行された場合、ローカル・システムは以下の処理を行う。

  • CeaseとともにNOTIFICATIONを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterをゼロに設定する、
  • 状態をIdleに変更する。

AutomaticStopイベント(イベント8)がOpenSent状態で発行された場合、ローカル・システムは以下の処理を行う。

  • CeaseとともにNOTIFICATIONを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

HoldTimer_Expires(イベント10)の場合、ローカル・システムは以下の処理を実行する。

  • エラーコード「Hold Timer Expired」を含むNOTIFICATIONメッセージを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

TcpConnection_Valid(イベント14)、Tcp_CR_Acked(イベント16)、またはTcpConnectionConfirmedイベント(イベント17)を受信した場合、2番目のTCP接続が進行中の可能性がある。この2番目のTCP接続は、OPENメッセージが受信するまで、接続衝突処理(セクション6.8)に従って追跡される。

無効なポートに対するTCP接続要求(Tcp_CR_Invalid(イベント15))を無視する。

TcpConnectionFailsイベント(イベント18)を受信した場合、ローカル・システムは以下の処理を実行する。

  • BGP接続をクローズする、
  • ConnectRetryTimerを再起動する、
  • リモートBGPピアによって開始されるかもしれない接続を待機を続ける、
  • 状態をActiveに変更する。

OPENメッセージを受信すると、すべてのフィールドの正しさ(correctness)がチェックされる。OPENメッセージ(イベント19)にエラーがない場合、ローカル・システムは以下の処理を実行する。

  • DelayOpenTimerをゼロにリセットする、
  • BGP ConnectRetryTimerをゼロに設定する、
  • KEEPALIVEメッセージを送信する、
  • KeepaliveTimerを設定する(以下の文章を参照)、
  • ネゴシエートされた値に従って、HoldTimerを設定する(セクション4.2を参照)、
  • 状態をOpenConfirmに変更する。

ネゴシエートされたホールド時間の値がゼロの場合、HoldTimerとKeepaliveTimerは開始されない。自律システム・フィールドの値がローカル自律システム番号と同じ場合、接続は「内部」接続である。それ以外の場合は、「外部」接続である。(これは、後述するようにUPDATE処理に影響する。)

BGPメッセージ・ヘッダ・チェック(イベント21)またはOPENメッセージ・チェックでエラーが検出された場合(イベント22)(セクション6.2を参照)、ローカル・システムは以下の処理を実行する。

  • 適切なエラー コードを含むNOTIFICATIONメッセージを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEの場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

有効なBGP OPENメッセージ(イベント19またはイベント20)を受信した場合、衝突検出メカニズム(セクション6.8)を適用する必要がある。比較の詳細については、セクション6.8を参照のこと。CollisionDetectDumpイベントは、BGP 実装がこの文書の範囲外の手段で、接続衝突が発生したと判断したときに発生する。

OpenSent状態にある接続がクローズしなければならない接続であると判断された場合、OpenCollisionDump(イベント23)を状態マシンに通知する。OpenSent状態で、このようなイベントを受信した場合、ローカル・システムは以下の処理を行う。

  • CeaseとともにNOTIFICATIONを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

バージョン・エラー(イベント24)を含むNOTIFICATIONメッセージを受信した場合、ローカル・システムは以下の処理を行う。

  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • 状態をIdleに変更する。

その他のイベント(イベント9、11-13、20、25-28)に応答して、ローカル・システムは以下の処理を実行する。

  • エラーコード有限状態マシン・エラーを含むNOTIFICATIONを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

OpenConfirm 状態:

この状態では、BGPはKEEPALIVEまたはNOTIFICATIONメッセージを待機する。

OpenConfirm状態では、開始イベント(イベント1、3-7)はすべて無視する。

オペレータによって開始されたManualStopイベント(イベント2)に応答して、ローカル・システムは以下の処理を行う。

  • Cease とともにNOTIFICATIONメッセージを送信する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterをゼロに設定する、
  • ConnectRetryTimerをゼロに設定する、
  • 状態をIdleに変更する。

システムによって開始されたAutomaticStopイベント(イベント8)に応答して、ローカル・システムは以下の処理を行う。

  • Cease とともにNOTIFICATIONメッセージを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

KEEPALIVEメッセージを受信する前にHoldTimer_Expiresイベント(イベント10)が発生した場合、ローカル・システムは以下の処理を実行する。

  • エラーコードHold Timer ExpiredとともにNOTIFICATIONメッセージを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

ローカル・システムがKeepaliveTimer_Expiresイベント(イベント11)を受信した場合、ローカル・システムは以下の処理を実行する。

  • KEEPALIVEメッセージを送信する、
  • KeepaliveTimerを再起動する、
  • OpenConfirmed状態を維持する。

TcpConnection_Validイベント(イベント14)が発生した場合、またはOpenConfirm中にTCP接続が成功した場合(イベント16またはイベント17)、ローカル・システムは2番目の接続を追跡する必要がある。

無効なポートでTCP接続が試行された場合(イベント15)、ローカル・システムは2番目の接続試行を無視する。

ローカル・システムが、基礎となるTCPからTcpConnectionFailsイベント(イベント18)またはNOTIFICATIONメッセージ(イベント25)を受信した場合、ローカル・システムは以下を実行する:

  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

ローカル・システムがバージョン・エラー(NotifMsgVerErr(イベント24))を持つNOTIFICATIONメッセージを受信した場合、ローカル・システムは以下の処理を行う。

  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • 状態をIdleに変更する。

ローカル・システムが有効なOPENメッセージ(BGPOpen(イベント19))を受信した場合、セクション6.8に従って、衝突検出機能を処理する。接続の衝突によりこの接続を切断する場合、ローカル・システムは以下の処理を行う。

  • CeaseとともにNOTIFICATIONを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する(TCP FINを送信する)、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

OPENメッセージを受信した場合、すべてのフィールドが正しいかどうかチェックする。BGPメッセージ・ヘッダ・チェック(BGPHeaderErr (イベント21))またはOPENメッセージ・チェックでエラー(セクション6.2を参照)(BGPOpenMsgErr (イベント 22))を検出した場合 、ローカル・システムは以下の処理を実行する。

  • 適切なエラー・コードを含むNOTIFICATIONメッセージを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

別のOPENメッセージの処理中に、BGP実装が本文書の範囲外の手段で接続衝突が発生し、この接続をクローズする必要があると判断した場合、ローカル・システムはOpenCollisionDumpイベント(イベント23)を発行する。ローカル・システムがOpenCollisionDumpイベント(イベント23)を受信すると、ローカル・システムは以下の処理を実行する。

  • CeaseとともにNOTIFICATIONを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

ローカル・システムがKEEPALIVEメッセージ(KeepAliveMsg(イベント26))を受信した場合、ローカル・システムは以下の処理を実行する。

  • HoldTimerを再起動する、
  • 状態をEstablishedに変更する。

他のイベント(イベント9、12～13、20、27～28)に応答して、ローカル・システムは以下の処理を実行する。

  • 有限状態マシン・エラー・コードを含むNOTIFICATIONを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

Established状態:

Established状態では、BGP FSMはピアとUPDATE、NOTIFICATION、KEEPALIVEメッセージを交換できる。

Established状態では、Start イベント (イベント1、3～7)を無視する。

ManualStopイベント(オペレータによって開始) (イベント2)に応答して、ローカル・システムは以下の処理を行う。

  • Cease とともにNOTIFICATIONメッセージを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • この接続に関連付けられているすべての経路を削除する、
  • BGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterをゼロに設定する、
  • 状態をIdleに変更する。

AutomaticStopイベント(イベント8)に応答して、ローカル・システムは以下の処理を行う。

  • Cease とともにNOTIFICATIONを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • この接続に関連付けられているすべての経路を削除する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

AutomaticStopイベントが発生する理由の1つは、BGPがピアのプレフィックス数を含むUPDATEメッセージを受信し、受信したプレフィックスの合計が設定されているプレフィックスの最大数を超えていることからである。その場合、ローカル・システムは自動的にピアを切断する。

HoldTimer_Expiresイベントが発生した場合(イベント10)、ローカル・システムは以下の処理を実行する。

  • この接続に関連付けられているすべての経路を削除する、
  • エラーコードHold Timer Expiredを含むNOTIFICATIONメッセージを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

KeepaliveTimer_Expiresイベントが発生した場合(イベント11)、ローカル・システムは以下の処理を実行する。

  • KEEPALIVEメッセージを送信する、
  • ネゴシエートされたホールド時間の値がゼロでない限り、KeepaliveTimerを再起動する。

ローカル・システムがKEEPALIVEまたはUPDATEメッセージを送信するたびに、ネゴシエートされたホールド時間値がゼロでない限り、KeepaliveTimerを再起動する。

有効なポートに対して受信したTcpConnection_Valid(イベント14)は、2番目の接続が追跡される原因となる。

無効なTCP接続(Tcp_CR_Invalidイベント(イベント15))を無視する。

TCP接続が正常に確立されたこと(イベント16またはイベント17)の通知に応答して、2番目の接続はOPENメッセージを送信するまで追跡されなければならない(SHALL)。

有効なOPENメッセージ (BGPOpen (イベント19))を受信し、CollisionDetectEstablishedStateオプション属性がTRUEの場合、OPENメッセージは他の接続と衝突していないかどうか(セクション6.8)をチェックする。BGP実装でこの接続を終了する必要があると判断した場合、OpenCollisionDumpイベント(イベント23)を処理する。この接続を終了する必要がある場合、ローカル・システムは以下の処理を実行する。

  • CeaseとともにNOTIFICATIONを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • この接続に関連付けられているすべての経路を削除する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillationsがTRUEに設定されている場合、ピア振動切断を実行する、
  • 状態をIdleに変更する。

ローカル・システムが、基礎となるTCPからNOTIFICATIONメッセージ(イベント24またはイベント25)またはTcpConnectionFails(イベント18)を受信した場合、ローカル・システムは以下の処理を行う。

  • ConnectRetryTimerをゼロに設定する、
  • この接続に関連付けられたすべての経路を削除する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • 状態をIdleに変更する。

ローカル・システムがKEEPALIVEメッセージ(イベント26)を受信した場合、ローカル・システムは以下の処理を行う。

  • ネゴシエートされたホールド時間の値がゼロでなければ、HoldTimerを再起動する、
  • Established状態を維持する。

ローカル・システムがUPDATEメッセージ(イベント27)を受信した場合、ローカル・システムは以下の処理を行う。

  • メッセージを処理する、
  • ネゴシエートされたホールド時間の値がゼロでなければ、HoldTime を再起動する、
  • Established状態を維持する。

ローカル・システムがUPDATEメッセージを受信し、UPDATEメッセージのエラー処理手順 (セクション6.3を参照)がエラー(イベント28)を検出した場合、ローカル・システムは以下の処理を実行する。

  • 更新エラーとともにNOTIFICATIONメッセージを送信する、
  • ConnectRetryTimerをゼロに設定する、
  • この接続に関連付けられているすべての経路を削除する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounterを1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。

他のイベント(イベント9、12～13、20～22)に応答して、ローカル・システムは以下の処理を実行する。

  • エラーコードFinite State Machine Errorを含むNOTIFICATIONメッセージを送信する。
  • この接続に関連付けられているすべての経路を削除する、
  • ConnectRetryTimerをゼロに設定する、
  • すべてのBGPリソースを解放する、
  • TCP接続を切断する、
  • ConnectRetryCounter を1増分する、
  • (オプション)DampPeerOscillations属性がTRUEに設定されている場合、ピア振動減衰を実行する、
  • 状態をIdleに変更する。
⚠️ FSMの図

bgp-fsm
<https://nwktimes.blogspot.com/2017/07/border-gateway-protocol-finite-state.html>

管理上のイベント:
イベント1. ManualStart
イベント2. ManualStop
イベント3. AutomaticStart
イベント4. ManualStart_with_PassiveTcpOpen
イベント5. AutomaticStart_with_PassiveTcpOpen
イベント6. AutomaticStart_with_DampPeerOscillations
イベント7. AutomaticStart_with_DampPeerOscillations_andPassiveTcpEstablishment
イベント8. AutomaticStop

タイマー・イベント:
イベント9. ConnectRetryTimer_Expires
イベント10. HoldTimer_Expires
イベント11. KeepaliveTimer_Expires
イベント12. DelayOpenTimer_Expires
イベント13. IdleHoldTimer_Expires

TCP接続ベースのイベント:
イベント14. TcpConnection_Valid
イベント15. Tcp_CR_Invalid
イベント16. Tcp_CR_Acked
イベント17. TcpConnectionConfirmed
イベント18. TcpConnectionFails

BGPメッセージ・ベースのイベント:
イベント19. TcpConnection_Valid
イベント20. BGPOpen with DelayOpenTimer running
イベント21. BGPHeaderErr
イベント22. BGPOpenMsgErr
イベント23. OpenCollisionDump
イベント24. NotiMsgVerErr
イベント25. NotiMsg
イベント26. KeepAliveMsg
イベント27. UpdateMsg
イベント28. UpdateMsgErr

9. UPDATE メッセージの処理

UPDATEメッセージは、Established状態でのみ受信できる。それ以外の状態でUPDATEメッセージを受信するとエラーになる。UPDATEメッセージを受信すると、セクション6.3で規定定しているように、各フィールドの有効性をチェックする。

オプション非推移的属性が認識されなければ、その属性を無視する。オプション推移的属性が認識されない場合、属性フラグ・オクテットの部分ビット(上位3ビット)は1に設定され、属性は他のBGPスピーカーへの伝播のために保持される。

オプション属性が認識され、有効な値を持つ場合、オプション属性のタイプに応じて、ローカルで処理され、保持され、必要に応じて更新され、他のBGPスピーカーに伝播することが可能になる。

UPDATEメッセージに空でないWITHDRAWN ROUTESフィールドが含まれている場合、このフィールドに含まれる宛先(IPプレフィックスとして表現)を持つ前に広告された経路は、Adj-RIB-Inから削除しなければならない(SHALL)。この BGPスピーカーは前に広告された経路がもはや使用できなくなったため、その決定プロセスを実行しなければならない(SHALL)。

UPDATEメッセージがフィージブル経路を含む場合、Adj-RIB-Inは以下のようにこの経路で更新する。新しい経路のNLRIが、現在Adj-RIB-Inに格納されている経路のNLRIと同一であれば、新しい経路はAdj-RIB-Inの古い経路を置き換え、暗黙的に古い経路をサービスから撤回する。そうでなければ、Adj-RIB-Inに新しい経路と同じNLRIを持つ経路がない場合、新しい経路はAdj-RIB-Inに置かなければならない(SHALL)。

BGPスピーカーがAdj-RIB-Inを更新すると、スピーカーはその決定プロセスを実行しなければならない(SHALL)。

9.1. 決定プロセス

決定プロセスは、ローカル・ポリシー情報ベース(PIB)のポリシーをAdj-RIBs-Inに格納されている経路に適用することで、後続の広告のための経路を選択する。決定プロセスの出力は、ピアに広告される経路セットである。選択された経路は、ポリシーに従ってローカル・スピーカーのAdj-RIBs-Outに格納される。

ここで説明するBGP決定プロセスは概念的なものであり、実装が説明する機能をサポートし、外部から見える動作が同じであれば、説明したとおりに正確に実装する必要はない。

選択プロセスは、与えられた経路の属性を引数として受け取り、(a) 経路の優先度を示す負でない整数、または(b) この経路がLoc-RIBにインストールする資格がなく、次の経路選択フェーズから除外されることを示す値のいずれかを返す関数を定義することで形式化できる。

与えられた経路の優先度を計算する関数は、他の経路の存在、他の経路の非存在、他の経路のパス属性のいずれかを入力として使用してはならない(SHALL NOT)。経路選択は、各フィージブル経路に優先度関数を個別に適用し、優先度が最も高い経路を選択するという形で行われる。

決定プロセスは、Adj-RIBs-Inに含まれる経路に対して実行され、以下の処理を行う。

  • スピーカーがローカルで使用する経路を選択
  • 他のBGPピアに広告する経路の選択
  • 経路集約と経路情報削減

決定プロセスは、3つの異なるフェーズで行われ、それぞれが異なるイベントが引き金となる。

a) フェーズ1は、ピアから受信した各経路の優先度を計算する処理を行う。

b) フェーズ2は、フェーズ1の完了時に呼び出す。これは、各宛先に対して利用可能なすべての経路の中から最適な経路を選択し、選択した各経路をLoc-RIBにインストールする責任を負う。

c) フェーズ3は、Loc-RIBが変更された後に呼び出す。これは、PIBに含まれるポリシーに従って、Loc-RIB内の経路を各ピアに配布する処理を担う。経路集約と情報削減は、オプションでこのフェーズで実行できる。

9.1.1. フェーズ1: 優先度の計算

フェーズ1の決定関数は、ローカルBGPスピーカーがピアから、新しい経路、代替経路、または撤回経路を広告するUPDATEメッセージを受信するたびに呼び出す。

フェーズ 1の決定関数は別プロセスであり、これ以上の作業がなくなると完了する。

フェーズ1の決定機能は、Adj-RIB-Inに含まれる経路を操作する前にAdj-RIB-Inをロックし、Adj-RIB-Inに含まれるすべての新しい経路またはアンフィージブル経路を操作した後にロックを解除する。

新しく受信した経路または代替フィージブル経路について、ローカルBGPスピーカーは以下のように優先度を決定する。

経路が内部ピアから学習した場合、LOCAL_PREF属性の値を優先度として使用するか、ローカル・システムが事前に設定したポリシー情報に基づいて経路の優先度を計算する。後者の場合、永続的なルーティング・ループを形成する可能性があることに留意する。

経路が外部ピアから学習した場合、ローカルBGPスピーカーは事前設定したポリシー情報に基づいて優先度を計算する。戻り値がその経路が不適格であることを示す場合、その経路は経路選択の次のフェーズの入力として使用してはならない(MAY NOT)。それ以外の場合、その戻り値はIBGP再広告のLOCAL_PREF値として使用しなければならない(MUST)。

このポリシー情報の正確な性質と、関連する計算はローカルの問題である。

9.1.2. フェーズ2: 経路選択

フェーズ2の決定関数は、フェーズ1の完了時に呼び出す。フェーズ2の関数は別のプロセスで、それ以上の作業がなくなると完了する。フェーズ2のプロセスは、Adj-RIBs-Inで適格なすべての経路が考慮する。

フェーズ 3の決定関数の処理中は、フェーズ2の決定関数は実行がブロックされる。フェーズ2関数は、その関数を開始する前にすべてのAdj-RIBs-Inをロックし、完了するとロックを解除する。

BGP経路のNEXT_HOP属性が解決できないアドレスを表現する場合、あるいは経路がルーティング・テーブルにインストールされると解決できなくなる場合、そのBGP経路はフェーズ2の決定関数から除外しなければならない(MUST)。

BGP経路のAS_PATH属性にASループが含まれている場合、そのBGP経路はフェーズ2の決定関数から除外する必要がある。ASループの検出は、(AS_PATH属性で指定された)ASパス全体をスキャンし、ローカル・システムの自律システム番号がASパスに現れないことを確認することで行う。ASパスに自身の自律システム番号を持つ経路を受け入れるように設定しているBGPスピーカーの動作は、本文書の範囲外である。

AS内のBGPスピーカーが、フォワーディング・ループを発生させるような経路選択に関する矛盾する決定を下さないようにすることが重要である。

Adj-RIBs-Inにフィージブル経路が存在する宛先の各セットについて、ローカルBGPスピーカーは次の条件を満たす経路を特定する。

a) 同じ宛先セットへの経路の中で最も優先度が高い、または
b) その宛先への唯一の経路である、または
c) セクション9.1.2.2で規定しているフェーズ2のタイブレーク・ルールの結果として選択する。

次に、ローカル・スピーカーは、その経路をLoc-RIBにインストールし、現在Loc-RIBに保持している同じ宛先への経路を置き換える。新しいBGP経路がルーティング・テーブルにインストールするとき、既存の無効とみなされる同じ宛先への既存経路がルーティング・テーブルから削除するように注意しなければならない。新しいBGP経路がルーティング・テーブルの既存の非BGP経路を置き換えるかどうかは、BGPスピーカーに設定されているポリシーによって異なる。

ローカル・スピーカーは、選択された経路のNEXT_HOP属性から、直近のネクストホップ・アドレスを決定しなければならない(セクション5.1.3を参照)。直近のネクストホップまたは NEXT_HOPへのIGPコスト(NEXT_HOPがIGP経路を通じて解決される場合)のいずれかが変更になった場合、フェーズ2の経路選択を再度実行しなければならない(MUST)。

BGP経路をすぐ前のネクストホップとともにルーティング・テーブルにインストールする必要はないが、実装はBGP経路でパケットがフォワードされる前に、関連するNEXT_HOPアドレスは直近(直接接続された)のネクストホップ・アドレスで解決され、このアドレス(または複数のアドレス)が実際のパケット転送に最終的に使用するよう注意しなければならない(MUST)。

解決できない経路は、Loc-RIBとルーティング・テーブルから削除しなければならない(SHALL)。ただし、対応する解決できない経路は、解決可能になった場合に備えてAdj-RIBs-Inに保持する必要がある(SHOULD)。

9.1.2.1. 経路解決可能条件

セクション9.1.2で示されているように、BGPスピーカーは解決できない経路をフェーズ 2の決定から除外する必要がある(SHOULD)。これにより、有効な経路だけがLoc-RIBとルーティング・テーブルにインストールされる。

経路解決可能条件は以下のように定義する:

  1. 中間ネットワーク・アドレスのみを参照する経路Rte1は、Rte1の中間ネットワーク・アドレスに一致し、Rte1を介して再帰的に(直接的または間接的に)解決されない、解決可能な経路Rteをルーティング・テーブルに少なくとも1つ含んでいれば、解決可能と見なす。複数の一致する経路がある場合、最長一致の経路のみを考慮する必要がある(SHOULD)。

  2. インタフェースを参照する経路(中間アドレスの有無にかかわらず)は、参照先のインタフェースの状態がUPであり、このインタフェースでIP処理が有効になっていれば、解決可能と見なされる。

BGP経路はインタフェースを参照しないが、ルーティング・テーブルの経路を通して解決することができ、両方のタイプ(インタフェースを指定するものとしないもの)がある。IGP経路と直接接続されたネットワークへの経路は、アウトバウンド・インタフェースを指定することが想定されている。静的経路は、アウトバウンド・インタフェース、中間アドレス、またはその両方を指定できる。

BGPスピーカーのルーティング・テーブルにBGP経路のNEXT_HOPに一致する経路がない場合、BGP経路は解決不可能と見なされることに留意する。相互に再帰的な経路(相互に解決する経路、またはそれ自体を解決する経路)も解決可能性チェックに失敗する。

また、実装では、ルーティング・テーブルにインストールされた場合に解決不可能になる実行可能がある経路を、NEXT_HOPがルーティング・テーブルの現在の内容を使用して解決可能であっても、フィージブル経路として考慮しないことも重要である(このような経路の例としては、相互に再帰的な経路がある)。このチェックにより、BGPスピーカーがスピーカーによって削除され、使用されなくなる経路をルーティング・テーブルにインストールされないことが保証される。したがって、このチェックは、ローカルのルーティング・テーブルの安定性に加えて、ネットワークにおけるプロトコル動作も改善する。

BGPスピーカーが相互再帰のために解決可能性チェックに失敗した経路を特定した場合は常に、エラー・メッセージをログに記録する必要がある(SHOULD)。

9.1.2.2. タイブレーク (フェーズ2)

BGPスピーカーのAdj-RIBs-Inでは、同じ宛先への同じ優先度の経路を複数持っているかもしれない。ローカル・スピーカーは、関連するLoc-RIBに含まれるために、これらの経路のうち1つだけを選択できる。ローカル・スピーカーは、内部ピアから受信した経路も、外部ピアから受信した経路の両方についても、優先度が同じすべての経路を考慮する。

以下のタイブレーク手順は、各候補経路について、自律システム内のすべてのBGPスピーカーが、経路のNEXT_HOP属性で示されるアドレスへのパスのコスト(内部距離)を突き止め、同じ経路選択アルゴリズムに従うことを前提としている。

タイブレーク・アルゴリズムは、同じ宛先へのすべての等しく好ましい経路をすべて検討することから始まり、その後、検討から除外する経路を選択する。検討対象経路が1つだけになると、アルゴリズムは終了する。基準は指定された順番で適用しなければならない(MUST)。

いくつかの基準は、擬似コードを用いて詳細な説明が行われている。示された擬似コードは、分かりやすさのために選ばれたもので、効率性のためではないことに留意する。これは特定の実装を規定するためのものではない。BGP実装は、ここで説明されているものと同じ結果を生成する任意のアルゴリズムを使用できる(MAY)。

a) AS_PATH属性に存在する AS番号の数が最少でどう数ではない経路をすべて検討から除外する。この数を数えるとき、そのセット内のASの数に関係なく、AS_SETは1として数えなければならないことに留意する。

b) Origin属性のOrigin番号が最も小さい経路以外をすべて検討から除外します。

c) 優先度の低いMULTI_EXIT_DISC属性を持つ経路を検討から除外する。MULTI_EXIT_DISCは、同じ隣接ASから学習した経路間でのみ比較できる(隣接ASはAS_PATH属性から決定する)。MULTI_EXIT_DISC属性を持たない経路は、可能な限り小さいMULTI_EXIT_DISC値を持つものと見なされる。

これについては、以下の手順でも説明する。

for m = all routes still under consideration
    for n = all routes still under consideration
        if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
            remove route m from consideration

上記の疑似コードでは、MED(n)は経路nのMULTI_EXIT_DISC属性の値を返す関数である。経路nにMULTI_EXIT_DISC属性がない場合、関数は可能な限り小さいMULTI_EXIT_DISC値(つまり0)を返す。

同様に、neighborAS(n)は経路を受信した隣接ASを返す関数である。経路をがIBGP経由で学習し、他方のIBGPスピーカーが経路を発信していない場合、それがもう片方のIBGPスピーカーが経路を学習した隣接ASである。経路をIBGP経由で学習し、もう一方のIBGPスピーカーが (a) 経路を発信したか、(b) 集約によって経路を作成し、集約経路のAS_PATH属性が空かAS_SETで始まる場合、それはローカルASである。

IBGPに経路を再広告する前にMULTI_EXIT_DISC属性が削除された場合でも、受信したEBGP MULTI_EXIT_DISC属性に基づく比較はまだ実行することができる(MAY)。実装がMULTI_EXIT_DISCを削除することを選択した場合、MULTI_EXIT_DISCに関するオプションの比較が実行された場合は、EBGPで学習した経路間でのみ実行しなければならない(MUST)。最適なEBGPで学習した経路は、MULTI_EXIT_DISC属性を削除した後にIBGPで学習した経路と比較できる。MULTI_EXIT_DISC がEBGPから学習した経路のサブセットから削除され、選択された「最適な」EBGPから学習した経路がMULTI_EXIT_DISCを削除しない場合、MULTI_EXIT_DISCはIBGPから学習した経路との比較で使用しなければならない。IBGPから学習した経路の場合、決定プロセスのこのステップに到達する経路比較でMULTI_EXIT_DISCを使用しなければならない(MUST)。EBGPで学習した経路のMULTI_EXIT_DISCをIBGPから学習した経路との比較に含めることで、その後MULTI_EXIT_DISC属性を削除し、経路を広告することは、経路ループを引き起こすことが証明されている。

d) 候補経路の少なくとも1つがEBGP経由で受信した場合、IBGP経由で受信したすべての経路を検討から除外する。

e) 優先順位の低い内部コストを持つ経路を検討から除外する。経路の内部コストは、ルーティング・テーブルを使用して経路のNEXT_HOPへのメトリックを計算することで決定する。経路のNEXT_HOPホップに到達可能だが、コストを決定できない場合、この手順をスキップする必要がある(つまり、すべての経路のコストが等しいと見なす)。

これは、以下の手順でも説明している。

for m = all routes still under consideration
      for n = all routes in still under consideration
          if (cost(n) is lower than cost(m))
              remove m from consideration

上記の疑似コードでは、cost(n)は、経路のNEXT_HOP属性で指定されたアドレスまでのパスのコスト(内部距離)を返す関数である。

f) 最も小さいBGP識別子値を持つBGPスピーカーから広告された経路以外のすべての経路を検討から除外する。

g) 最も小さいピア・アドレスから受信した経路を優先する。

9.1.3.フェーズ3: 経路の伝播

フェーズ3の決定関数は、フェーズ2の完了時、または以下のいずれかのイベントが発生したときに呼び出す:

a) Loc-RIB内のローカル宛の経路が変更されたとき、
b) BGP以外の手段で学習したローカル生成経路が変更されたとき、
c) 新しいBGPスピーカー接続が確立したとき

フェーズ3関数は、それ以上の作業がなくなったときに完了する別のプロセスである。フェーズ3のルーティング決定関数は、フェーズ2の決定関数が処理中の間は、実行をブロックする。

Loc-RIBのすべての経路は、設定されたポリシーに従ってAdj-RIBs-Outの処理を行う。このポリシーは、Loc-RIBの経路が特定のAdj-RIB-Outにインストールされることを除外してもよい(MAY)。この経路が記述する宛先とNEXT_HOPがルーティング・テーブルによって適切に転送される可能性がない限り、経路はAdj-Rib-Outにインストールしてはならない(SHALL NOT)。Loc-RIBの経路を特定のAdj-RIB-Outから除外する場合、そのAdj-RIB-Outで以前に広告された経路は、UPDATEメッセージによってサービスから取り下げられなければならない(MUST)(9.2 を参照)。

経路集約と情報削減手法(セクション9.2.2.1を参照)はオプションで適用できる。

ローカルBGPスピーカーのフォワーディング・テーブルに追加されることなく、Adj-RIB-Outに経路が追加されるようなローカル・ポリシーは、この文書の範囲外である。

Adj-RIBs-Outとルーティング・テーブルの更新が完了すると、ローカルBGPスピーカーは9.2のUpdate-Sendプロセスを実行する。

9.1.4. 重複経路

BGPスピーカーは、ネットワーク層到達可能性情報(NLRI)が重複する経路を別のBGPスピーカーに送信することがある。NLRIの重複は、宛先セットが一致しない複数の経路で識別される場合に発生する。BGPはIPプレフィックスを使って、NLRIを符号化するため、重複は常にサブセット関係を示す。小さい宛先セット(プレフィックスが長い)を記述する経路は、より大きい宛先セット(プレフィックスが短い)を記述する経路よりもモア・スペシフィックと言われる。同様に、大きい宛先セットを記述する経路は、小さい宛先セットを記述する経路よりもレス・スペシフィックと言われる。

優先順位の関係により、レス・スペシフィックな経路は実質的に2つに分けられる:

  • レス・スペシフィックな経路のみで記述される宛先セット、そして
  • レス・スペシフィックな経路とモア・スペシフィックな経路の重複によって記述される宛先セット

重複によって記述される宛先セットは、レス・スペシフィックな経路のうち、フィージブルな部分を表しているが、現在は使用されていない。モア・スペシフィックな経路が後で撤回された場合、重複によって記述された宛先セットは、モア・スペシフィックな経路を使用して到達可能である。

BGPスピーカーが重複する経路を受信した場合、決定プロセスは、設定した受け入れポリシーに基づいて両方の経路を考慮しなければならない(MUST)。レス・スペシフィックな経路とモア・スペシフィックな経路の両方が受け入れられた場合、決定プロセスは、レス・スペシフィックな経路とモア・スペシフィックな経路の両方をLoc-RIBにインストールするか、2つの経路を集約して、集約した経路をLoc-RIBにインストールしなければならない。ただし、両方の経路が同じNEXT_HOP属性値を持つ。

BGPスピーカーが集約を選択する場合、集約を形成するために使用されたすべてのASをAS_SETに含めるか、経路にATOMIC_AGGREGATE属性を追加する必要がある(SHOULD)。この属性は現在、主に情報用である。クラスレス・ルーティングをサポートしないIPルーティング・プロトコルの廃止、およびクラスレス・ルーティングをサポートしないルータとホストの実装の廃止により、集約を解除する必要性は無くなった。経路は集約解除すべきではない(SHOULD NOT)。特に、ATOMIC_AGGREGATE属性を伝える経路は、集約解除(de-aggregate)してはならない(MUST NOT)。つまり、この経路のNLRIはモア・スペシフィックであってはならない。このような経路での転送は、IPパケットが実際に経路のAS_PATH属性にリストされているASだけを実際に通過することが保証されるわけではない。

9.2. Update-Sendプロセス

Update-Sendプロセスは、すべてのピアにUPDATEメッセージを広告する役割を担う。例えば、決定プロセスで選択された経路を、同じ自律システムまたは隣接する自律システムに位置する他のBGPスピーカーに配布する。

BGPスピーカーが内部ピアからUPDATEメッセージを受信した場合、受信側のBGPスピーカーは、そのUPDATEメッセージに含まれるルーティング情報を他の内部ピアに再配布してはならない(SHALL NOT)(スピーカーがBGPルート・リフレクタ[RFC2796]として動作する場合を除く)。

経路選択プロセスのフェーズ3の一部として、BGPスピーカーはAdj-RIBs-Outを更新した場合、新しくインストールされたすべての経路と、代替ルートが存在しないすべての新しいアンフィージブル経路は、UPDATEメッセージによってピアに広告しなければならない(SHALL)。

BGPスピーカーは、以前に広告した経路と同じBGP経路を含むUPDATEメッセージを生成する場合、Adj-RIB-OutからフィージブルなBGP経路を広告してはならない(SHOULD NOT)。

アンフィージブルとマークされたLoc-RIB内の経路はすべて削除しなければならない(SHALL)。自身の自律システム内の到達可能な宛先の変更も、UPDATEメッセージで広告しなければならない(SHALL)。

UPDATEメッセージの最大サイズに制限があるため(セクション4を参照)、1つの経路がメッセージに収まらない場合、BGPスピーカーはその経路をピアに広告してはならず(MUST)、ローカルでエラーをログに記録することを選択できる(MAY)。

⚠️ 1つの経路がメッセージに収まらない

BGPのUPDATEメッセージに収まらないほど大きな経路は、以下のようなケースで発生すると思われる(実際には意図的なものでない限り、このような経路は発生しないと思われる)。

  1. 非常に多くのASパスを含む経路
  2. 多数の属性を持つ経路(複雑な構成や細かなポリシーを持つ経路)
  3. 多数のプレフィックスを持つ経路: BGPアップデートは、同じ属性を持つ複数のプレフィックスを一度に送ることができる。大量のプレフィックスが1つのUPDATEメッセージに詰め込んだ場合、サイズを超過する可能性がある。

9.2.1. ルーティング・トラフィック・オーバーヘッドの制御

BGPプロトコルは、UPDATEメッセージの広告に必要なリンク帯域幅と、UPDATEメッセージに含まれる情報を処理するために決定プロセスが必要とする処理能力の両方を制限するため、ルーティング・トラフィック(つまり、UPDATEメッセージ)の量を制限している。

9.2.1.1. 経路広告の頻度

パラメータMinRouteAdvertisementIntervalTimerは、BGPスピーカーがピアに対して宛先への経路を広告および/または撤回との間に経過しなければならない最小時間を決定する。このレート制限手順は宛先ごとに適用されるが、MinRouteAdvertisementIntervalTimerの値はBGPピアごとに設定する。

⚠️ 最小経路広告間隔(MRAI)

Minimum Route Advertisement Interval (MRAI) は、ルータが隣接ルータに対して経路情報を再送信する間隔をいう。具体的には、ルータが隣接ピアに同じ経路を再度広告するまでに待つ最小時間を制御する。

役割:

  1. ネットワークの安定性の向上: MRAIは、ネットワークのフラッピングを抑えるために重要である。頻繁に変動する経路を短い間隔で広告し続けると、ルータに大きな負荷がかかり、ネットワーク全体のパフォーマンスに悪影響を与える可能性がある。そこで、MRAIを設定することで、ルータが短期間に多くの経路を再広告するのを防ぐことができ、ネットワークの安定性を保つことができる。
  2. 帯域幅の効率的な使用: 経路広告の頻度を抑えることで、BGPメッセージの送受信に使用される帯域幅の消費を減らす。これにより、他の重要なトラフィックに対するネットワークリソースを確保できる。
  3. 収束時間のバランス: MRAIは、BGPの収束時間にも影響する。MRAIが短いと収束が速くなる可能性があるが、頻繁な広告がネットワークに負担をかける可能性がある。一方、MRAIが長すぎると、経路の変更がゆっくりと反映され、経路の反映に遅延が生じる可能性がある。適切にMRAIを設定することで、これらのトレードオフを最適化できる。

多くのBGP実装では、MRAIのデフォルト値は30秒である。RFC4271では、MRAI値をピアごとに調整できるとなっている。

  • Junos: デフォルト0秒
  • IOS-XR: デフォルト0秒(IBGP)、30秒(EBGP)

参考

MRAIの実装例

bgp-mrai

  • IBGPピアのMRAIタイムライン。
  • t7のベストパス変化#1は直ちに送信される。
  • MRAIタイマーはt7で開始し、t12で終了する。
  • t10でのベストパス変化#2は、MRAIが終了するt12まで待たなければならない。
  • t12にベストパス変化#2が送信される。
  • MRAIタイマーはt12に開始、t17で終了する。
  • MRAIはt12で終了... アップデートは保留されていない。

BGPスピーカーがピアに送信するフィージブル経路の広告および/またはある共通の宛先セットに対するアンフィージブル経路の撤回を広告する2つのUPDATEメッセージは、少なくともMinRouteAdvertisementIntervalTimerの間隔を空けなければならない(MUST)。これは、共通の宛先セットごとに個別のタイマーを保持することでしか実現できない。これは不当な(unwarranted)オーバーヘッドである。BGPスピーカーからピアに送信される2つのUPDATEメッセージの間隔が、フィージブル経路の広告および/または共通の宛先セットに対するアンフィージブル経路の撤回を広告する間隔が、少なくともMinRouteAdvertisementIntervalTimerの間隔で行うことを保証し、その間隔の上限が一定であることも保証する技術である。

自律システム内では高速コンバージェンスが必要なため、(a) 内部ピアに使用される MinRouteAdvertisementIntervalTimerは、外部ピアに使用されるMinRouteAdvertisementIntervalTimerよりも短くする必要がある(SHOULD)。あるいは、(b) このセクションで説明する手順は、内部ピアに送信される経路には適用すべきではない(SHOULD NOT)。

この手順は、経路選択のレートを制限せず、経路広告のレートのみを制限する。MinRouteAdvertisementIntervalTimerの有効期限が切れるのを待つ間に新しい経路が複数回選択された場合、MinRouteAdvertisementIntervalTimerの終了時に最後に選択された経路を広告しなければならない(SHALL)。

9.2.1.2. 経路発信の頻度

パラメータMinASOriginationIntervalTimerは、広告するBGPスピーカー自身の自律システム内の変更を報告するUPDATEメッセージを連続して広告する間に経過しなければならない最小時間を決定する。

9.2.2. ルーティング情報の効率的な編成

広告するルーティング情報を選択した後、BGPスピーカーはこの情報を効率的な方法で編成するために、いくつかの方法を利用することができる。

9.2.2.1. 情報の削減

情報の削減は、ポリシー制御の粒度の縮小を意味するかもしれない。情報が圧縮された後、同じポリシーが等価クラス内のすべての宛先とパスに適用される。

決定プロセスは、オプションで以下のいずれかの方法でAdj-RIBs-Outに配置する情報量を減らすことができる。

a) ネットワーク層到達可能性情報(NLRI):

宛先IPアドレスは、IPアドレス・プレフィックスとして表すことができる。アドレス構造と自律システム管理者の管理下にあるシステムとの間に対応関係(correspondence)がある場合、UPDATEメッセージで伝送されるNLRIのサイズを小さくすることができる。

b) AS_PATH:

ASパス情報は、通過したASを順番通りに並べた(ordered)AS_SEQUENCEまたは通過したAS番号を順不同でグループ化した(unordered)AS_SETとして表すことができる。AS_SETは、セクション9.2.2.2で説明する経路集約アルゴリズムで使用する。AS_SETは、集約された複数のAS_PATHに何回出現したかに関係なく、各AS番号を1回だけリスト化することで、AS_PATH情報のサイズを縮小する。

⚠️ AS_SEQUENCEとAS_SET

ASパスのパスタイプには、AS_SEQUENCEとAS_SETの2つがある。

  1. AS_SEQUENCE:

    • 順番通りに並べられたAS番号のリスト。
    • BGPルータは、通過したAS番号を順番に追加していく。これにより、経路がたどったASの順番が明確に記録される。
    • 通常の経路更新で使われ、経路がどのASを経由して到達しているかが正確に分かる。
    • 例: AS_SEQUENCE = 64500 64501 64502 (AS64500 → AS64501 → AS64502)

  2. AS_SET:

    • 通過したAS番号を順不同でグループ化したリスト。
    • 経路集約の際に使用する。集約される複数の経路が異なるASを通過している場合、それらをセットとして記録し、どのASが経路に関与しているかを示すが、順序は保証しない。
    • ASベクトルのループ防止のために、どのASが通過したかは分かるが、その順番は分からない。
    • 例: AS_SET = {64500, 64501, 64502} (順番は関係なし)

AS_SEQUENCEは、通過したASを順番通りに記録し、経路の具体的な順序を示すのに使われる。AS_SET は、順番に関係なく、どのASを経由したかを示すために使用され、主に経路集約時に使われる。

AS_SETは、NLRIにリストされた宛先が、構成する自律システムの少なくともいくつかを通過するパスを通して到達できることを意味する。AS_SETは、ルーティング情報のループを回避するのに十分な情報を提供するが、AS_SETを使用すると、そのようなパスがAS_SEQUENCEの形で個別にリストされなくなるため、潜在的なフィージブル・パスが刈り込まれる可能性がある。実際には、IPパケットが自律システムのグループの端に到着すると、BGPスピーカーはより詳細なパス情報を持っている可能性が高く、宛先から個々のパスを区別することができるため、これは問題にならないと思われる。

9.2.2.2. ルーティング情報の集約

集約(aggregation)とは、単一の経路を広告できるように、複数の異なる経路の特性を組み合わせるプロセスである。集約は、Adj-RIBs-Outに配置されるルーティング情報の量を減らすために、決定プロセスの一部として実行される場合がある。

集約により、BGPスピーカーが保存し、他のBGPスピーカーと交換しなければならない情報の量を削減できる。経路は、同じタイプのパス属性とネットワーク層到達可能性情報に対して、個別に以下の手順を適用することで集約できる。

異なるMULTI_EXIT_DISC属性を持つ経路は集約してはならない(SHALL NOT)。

集約された経路がAS_PATH属性の最初の要素としてAS_SETを持つ場合、その経路の発信元ルータは、その経路でMULTI_EXIT_DISC属性を広告すべきではない(SHOULD NOT)。

異なるタイプコードを持つパス属性は、一緒に集約することはできない。同じタイプコードのパス属性は、以下のルールに従って集約することができる。

NEXT_HOP:
異なるNEXT_HOP属性を持つ経路を集約する場合、集約経路のNEXT_HOP属性は、集約を実行するBGPスピーカー上のインタフェースを識別しなければならない(SHALL)。

ORIGIN属性:
集約経路のうち少なくとも1つの経路のORIGINの値がINCOMPLETEを持つ場合、集約経路のORIGINの値はINCOMPLETEを持たなければならない(MUST)。それ以外の場合、集約経路のうち少なくとも1つの経路のORIGINの値がEGPを持つ場合、集約経路のORIGIN属性の値はEGPを持たなければならない(MUST)。その他のすべての場合、集約経路のORIGIN属性の値はIGPである。

AS_PATH属性:
集約経路のAS_PATH属性が同一の場合、集約経路のAS_PATH属性は、各個別の経路のAS_PATH属性と同じである。

AS_PATH属性を集約する目的で、AS_PATH属性内の各ASをタプル<type, value>としてモデル化する。ここで、「type」はASが属するパス・セグメントのタイプ(AS_SEQUENCE、AS_SETなど)を識別し、「value」はAS番号を識別する。集約経路が異なるAS_PATH属性を持つ場合、集約されたAS_PATH属性は以下の条件すべてを満たさなければならない(SHALL)。

  • 集約されたAS_PATHのAS_SEQUENCEタイプのタプルはすべて、集約される初期の経路セットのすべてのAS_PATHに表示しなければならない(SHALL)。

  • 集約されたAS_PATHのAS_SETタイプのタプルはすべて、初期セットのAS_PATHの少なくとも1つに表示しなければならない(SHALL)(AS_SETタイプまたはAS_SEQUENCEタイプのいずれかで表示される可能性がある)。

  • 集約されたAS_PATH内のAS_SEQUENCEタイプのタプルXは、集約されたAS_PATH内のタプルYより前に位置する場合、Yのタイプに関係なく、Yを含む初期セット内の各AS_PATHにおいて、XはYより前に位置する。

  • 同じ値を持つAS_SETタイプのタプルは、集約されたAS_PATH 内に複数回現れてはならない(SHALL)。

  • 同じ値を持つ複数のAS_SEQUENCEタイプのタプルは、同じタイプと値を持つ別のタプルに隣接する場合に限り、集約されたAS_PATH 内に現れることがある。

実装は、これらのルールに準拠する任意のアルゴリズムを選択することができる。準拠した実装は少なくとも、上記の条件をすべて満たす以下のアルゴリズムを実行できなければならない(SHALL)。

  • 集約経路のすべてのAS_PATH属性に共通するタプル(上記で定義)の最長の先行シーケンスを決定する。このシーケンスを集約されたAS_PATH属性の先行シーケンスとする。

  • 集約する経路のAS_PATH属性の残りのタプルのタイプをAS_SETに設定し、それらを集約されたAS_PATH属性に追加する。

  • 集約されたAS_PATHに同じ値を持つタプルが複数ある場合(タプルのタイプに関係なく)、集約されたAS_PATH属性からAS_SETタイプのタプルを削除し、そのようなタプルを1つだけ残す。

  • 集約されたAS_PATH内の隣接するタプルの各ペアについて、両方のタプルが同じタイプである場合、長さが255を超えるセグメントが生成されない限り、それらを結合する。

付録FのセクションF.6では、条件を満たし、より複雑なポリシー設定を可能にする別のアルゴリズムを提示している。

ATOMIC_AGGREGATE:
集約経路の少なくとも1つにATOMIC_AGGREGATEパス属性がある場合、集約経路にもこの属性が設定されるものとする。

AGGREGATOR:
集約経路のAGGREGATOR属性は、集約経路に含めてはならない。経路集約を実行するBGPスピーカーは、新しいAGGREGATOR属性を追加することができる(MAY)(セクション5.1.7を参照)。

9.3. 経路選択の基準

一般的に、複数の選択肢の中から経路を比較するための追加のルールは、本文書の範囲外である。ただし、例外が2つある。

  • もし、検討中の新しい経路のASパスにローカルASが含まれている場合、その新しい経路は他のどの経路よりも優先度が高いとは見なされない(スピーカーがそのような経路を受け入れるように設定されている場合)。そのような経路が使用された場合、ルーティング・ループが発生する可能性がある。

  • 分散オペレーションを成功させるためには、安定性の見込める経路のみを選択することができる。したがって、ASは不安定な経路の使用を避けるべきであり、また、経路の選択を急激かつ自発的に変更すべきではない(SHOULD NOT)。 前出の文章の「不安定」(unstable)と「急速」(rapid)という用語を定量化するには経験が必要だが、原則は明確である。不安定な経路は「ペナルティ」を課すことができる(例えば、[RFC2439]に記載されている手順を使用するなど)。

9.4. BGP経路の発信

BGPスピーカーは、他の手段(例えばIGP経由)で取得したルーティング情報をBGPに注入することで、BGP経路を発信することができる。BGP経路を発信するBGPスピーカーは、これらの経路を決定プロセス(セクション9.1を参照)に渡すことで、これらの経路に優先度(例えば、ローカル設定に従って)を割り当てる。また、これらの経路は、更新プロセスの一部として、ローカルAS内の他のBGPスピーカーに配布することができる(セクション9.2参照)。BGP経由でAS内でBGP以外で取得した経路を配布するかどうかの決定は、AS内の環境(IGPのタイプなど)に依存し、設定によって制御する必要がある(SHOULD)。

10. BGPタイマー

BGPは次の5つのタイマーを採用している: ConnectRetryTimer(セクション8参照)、HoldTimer(セクション4.2参照)、KeepaliveTimer(セクション8参照)、MinASOriginationIntervalTimer(セクション9.2.1.2参照)、MinRouteAdvertisementIntervalTimer(セクション 9.2.1.1参照)。

オプションで2つのタイマーをサポートすることができる(MAY): DelayOpenTimer、IdleHoldTimer (セクション8参照)。セクション8では、これらの使用方法を説明する。これらのオプション・タイマーの完全な動作は、本文書の範囲外である。

ConnectRetryTimeは、ConnectRetryTimerの初期値を格納する必須のFSM属性である。ConnectRetryTimeの推奨デフォルト値は120秒である。

ホールド時間は、HoldTimerの初期値を格納する必須のFSM属性である。ホールド時間の推奨デフォルト値は90秒である。

状態マシンの一部(セクション8参照)では、HoldTimerは大きな値に設定される。この大きな値の推奨デフォルト値は4分である。

KeepaliveTimeは、KeepaliveTimerの初期値を格納する必須のFSM属性である。KeepaliveTimeの推奨デフォルト値は、ホールド時間の1/3である。

MinASOriginationIntervalTimerの推奨デフォルト値は15秒である。

EBGP接続のMinRouteAdvertisementIntervalTimerの推奨デフォルト値は30秒である。

IBGP接続のMinRouteAdvertisementIntervalTimerの推奨デフォルト値は5秒である。

BGPの実装では、HoldTimerをピアごとに設定できるようにしなければならない(MUST)。また、他のタイマーについても設定できるようにしてよい(MAY)。

特定のBGPスピーカーによるBGPメッセージの配信にピークが含まれる可能性を最小限に抑えるために、MinASOriginationIntervalTimer、KeepaliveTimer、MinRouteAdvertisementIntervalTimer、ConnectRetryTimerに関連付けられたタイマーにジッターを適用する必要がある(SHOULD)。特定のBGPスピーカーは、アップデートの送信先に関係なく、これらの各量に同じジッターを適用することもできる(MAY)。つまり、ジッターをピアごとに設定する必要はない。

推奨されるデフォルトのジッター量は、適切なタイマーの基本値に、0.75から1.0の範囲で均一に分散されるランダムな係数を乗算して決定しなければならない(SHALL)。タイマーを設定するたびに、新しいランダム値を選択する必要がある(SHOULD)。ジッターのランダム値の範囲は設定することができる(MAY)。

付録A. RFC 1771との比較

[RFC1771]と比較すると、多くの編集上の変更点がある(多過ぎてここに記載できない)。

以下に、技術的な変更点を列挙する:

  • TCP MD5[RFC2385]、BGPルート・リフレクタ[RFC2796]、BGPコンフェデレーション[RFC3065]、BGPルート・リフレッシュ[RFC2918]などの機能の使用を反映するための変更。

  • AGGREGATOR属性でのBGP識別子の使用の明確化。

  • BGPスピーカーがピアから受け入れるプレフィックス数に上限を課す手順。

  • AS間トラフィック・エンジニアリングの目的で、BGPスピーカーがAS_PATH属性に自身のASの複数のインスタンスを含める機能。

  • さまざまなタイプのNEXT_HOPの明確化。

  • ATOMIC_AGGREGATE属性の使用の明確化。

  • 直近(immediate)ネクストホップとNEXT_HOPパス属性で指定されたネクストホップとの関係。

  • タイブレーク手順の明確化。

  • 経路広告の頻度の明確化。

  • オプションのパラメータ・タイプ1(認証情報)は廃止となった。

  • UPDATEメッセージ・エラー・サブコード7(ASルーティング・ループ)は廃止となった。

  • OPENメッセージ・エラー・サブコード5(認証失敗)は廃止となった。

  • 認証のためのマーカー・フィールドの使用は廃止となった。

  • 実装は、認証のためにTCP MD5[RFC2385]をサポートしなければならない(MUST)。

  • BGP FSMの明確化。

付録B. RFC 1267との比較

付録Aに記載されているすべての変更点と、以下の変更点がある。

BGP-4は、到達可能な宛先セットが単一のIPプレフィックスで表現される環境で動作することができる。ネットワーク・クラス、つまりサブネット化の概念は、BGP-4とは無関係である。これらの機能に対応するために、BGP-4はAS_PATH属性に関連付けられたセマンティクスと符号化を変更する。IPプレフィックスに関連付けられたセマンティクスを定義するために、新しい文章を追加した。これらの機能により、BGP-4は提案されているスーパーネット化スキーム[RFC1518, RFC1519]をサポートすることができる。

設定を簡素化するために、このバージョンでは経路選択手順を容易にする新しい属性LOCAL_PREFが導入している。

INTER_AS_METRIC属性はMULTI_EXIT_DISCに名前が変更された。

新しい属性ATOMIC_AGGREGATEは、特定の集約が集約解除されないことを保証するために導入した。もう一つの新しい属性AGGREGATORは、どのASとそのAS内のどのBGPスピーカーが集約を引き起こしたかを広告するために、集約経路に追加できる。

ホールド・タイマーが対称的であることを保証するため、ホールド・タイマーは接続ごとにネゴシエートされるようになった。ゼロのホールド・タイマーがサポートされるようになった。

付録C. RFC 1163との比較

付録AとBに記載されているすべての変更に加えて、以下が追加された。

BGP接続の衝突を検出して回復するために、OPENメッセージに新しいフィールド(BGP識別子)が追加された。新しい文章(セクション6.8)が追加され、衝突の検出と回復手順を規定した。

新しい文書では、NEXT_HOPパス属性で渡されるルータが、BGPスピーカーと同じ自律システムに属することが制限しなくなった。

新しい文書は、以前に到達可能だった経路に関する情報の交換を最適化し、簡素化している。

付録D. RFC 1105との比較

付録A、B、Cに記載されているすべての変更に加え、以下の変更がある。

[RFC1105]の有限状態マシンに対するマイナーな変更は、BSDバージョン4.3が提供するTCPユーザ・インタフェースに対応するために必要だった。

RFC 1105で提示されたUp/Down/Horizontal関係の概念はプロトコルから削除した。

RFC 1105からのメッセージ・フォーマットの変更は以下のとおりである。

  1. ホールド時間フィールドをBGPヘッダから削除し、OPENメッセージに追加した。
  2. バージョン・フィールドをBGPヘッダから削除し、OPENメッセージに追加した。
  3. OPENメッセージからLink Typeフィールドを削除した。
  4. OPEN CONFIRMメッセージを削除し、KEEPALIVEメッセージによる暗黙の確認に置き換えた。
  5. UPDATEメッセージのフォーマットを大幅に変更した。複数のパス属性をサポートするために、UPDATEメッセージに新しいフィールドを追加した。
  6. マーカー・フィールドを拡張し、その認証をサポートするためにその役割を拡大した。

RFC 1105で規定されているBGPはBGP-1、[RFC1163]で規定されているBGPはBGP-2、RFC 1267で規定されているBGPはBGP-3と呼び、本文書で規定されているBGPはBGP-4と呼ぶことが多いことに留意する。

付録E. BGPで使用できるTCPオプション

ローカル・システムのTCPユーザ・インタフェースがTCP PUSH機能をサポートしている場合、各BGPメッセージはPUSHフラグを設定して送信する必要がある(SHOULD)。PUSHフラグを設定することで、BGPメッセージが速やかに受信者に送信する。

ローカル・システムのTCPユーザ・インタフェースがTCP接続のDSCPフィールド [RFC2474]の設定をサポートしている場合、BGPが使用するTCP接続はDSCPフィールドのビット0～2を110(バイナリ)に設定してオープンする必要がある(SHOULD)。

実装では、TCP MD5オプション[RFC2385]をサポートしなければならない(MUST)。

付録F. 実装の推奨事項

このセクションでは、実装上の推奨事項をいくつか示す。

付録F.1. メッセージごとに複数のネットワーク

BGPプロトコルでは、同じパス属性を持つ複数のアドレス・プレフィックスを1つのメッセージで指定することができる。この機能を使用することを強く推奨する。メッセージごとに1つのアドレス・プレフィックスを使用すると、受信側のオーバーヘッドが大幅に増加する。複数のメッセージを受信することで、システムのオーバーヘッドが増加するだけでなく、BGPピアや他のルーティング・プロトコルへのアップデートのためにルーティング・テーブルをスキャンする(そして、関連するメッセージを送信する)オーバーヘッドも複数回発生する。

パス属性セットごとに編成されていないルーティング・テーブルから、パス属性セットごとに多数のアドレス・プレフィックスを含むメッセージを構築する方法の1つは、ルーティング・テーブルをスキャンしながら多数のメッセージを構築することである。各アドレス・プレフィックスを処理するたびに、関連付けられたパス属性セットのメッセージを割り当て(存在しない場合)、新しいアドレス・プレフィックスをそのメッセージに追加する。そのようなメッセージが存在する場合、新しいアドレス・プレフィックスをそのメッセージに追加する。メッセージに新しいアドレス・プレフィックスを格納するスペースがない場合、そのメッセージを送信し、新しいメッセージを割り当て、新しいアドレス・プレフィックスを新しいメッセージに挿入する。ルーティング・テーブル全体をスキャンする場合、割り当てられたすべてのメッセージを送信し、そのリソースが解放する。アドレス・プレフィックスがカバーするすべての宛先が共通のパス属性セットを共有する場合、最大限の圧縮が実現され、1つの4096バイト・メッセージで多数のアドレス・プレフィックスを送信することが可能になる。

複数のアドレス・プレフィックスを1つのメッセージに圧縮しないBGP実装でピアリングする場合、ピアの獲得時やネットワーク・トポロジに大幅な変更が発生したときに受信する大量のデータによるオーバーヘッドを削減するための手順を踏む必要があるかもしれない。その方法の1つは、アップデート・レートを制限することである。これにより、BGPピアや他のルーティング・プロトコルにフラッシュ・アップデートを提供するためのルーティング・テーブルの冗長スキャンを取り除くことができる。このアプローチの欠点は、ルーティング情報の伝播遅延が増加することである。複数のメッセージを処理にかかる時間よりも大きくない最小のフラッシュ・アップデート間隔を選択することで、この遅延は最小限に抑える必要がある。より優れた方法は、アップデートを送信する前に受信したすべてのメッセージを読み取ることである。

付録F.2. 経路フラッピングの削減

過度の経路フラッピング(ばたつき)を回避するには、宛先の撤回と、モア・スペシフィック経路またはレス・スペシフィック経路に関するアップデートの送信が必要なBGPスピーカーは、それらを同じUPDATEメッセージにまとめるべきである。

付録F.3. パス属性の順序付け

(セクション6.1で説明したように)アップデート・メッセージを結合する実装は、すべてのパス属性を既知の順序で送り出すことを好むかもしれない。これは、異なるアップデート・メッセージから、意味的に同じ属性セットをすばやく識別することを可能にする。これを容易にするため、タイプコードに従ってパス属性を順序付けることは有用な最適化である。この最適化は完全にオプションである。

付録F.4. AS_SETのソート

この状況を簡素化するために実行できるもう1つの有用な最適化は、AS_SETにあるAS番号をソートすることである。この最適化は完全にオプションである。

付録F.5. バージョン・ネゴシエーションの制御

BGP-4は、BGP-3では適切に表現できない集約経路を伝送できるため、BGP-4と別のBGPバージョンをサポートする実装では、ピアごとにBGP-4のみを話す機能を提供する必要がある。

付録F.6. 複雑なAS_PATH集約

大量のパス情報を保持するパス集約アルゴリズムの提供を選択する実装は、以下の手順を使用することを望むかもしれない。

2つの経路のAS_PATH属性を集約するために、各ASをタプル<type, value>としてモデル化する。ここで、「type」はASが属するパス・セグメントのタイプ(AS_SEQUENCE、AS_SETなど) を識別し、「value」はAS番号である。対応する<type, value>タプルが同じ場合、2つのASは同一と見なされる。

2つのAS_PATH属性を集約するアルゴリズムは、以下のように機能する。

a) 各AS_PATH属性内で、両方のAS_PATH属性内で同じ相対順序にある同じAS(上記で定義)を識別する。2つのAS、XとYは、以下のいずれかの場合は同じ順序とみなされる。

  • 両方のAS_PATH属性でXがYに先行する、または
  • 両方のAS_PATH属性でYがXに先行する。

b) 集約されたAS_PATH属性は、集約されるAS_PATH属性に現れるのとまったく同じ順序で、(a) で識別されたASで構成される。(a)で識別された2つの連続するASが、集約されるAS_PATH 属性の両方において互いに直後に続かない場合、両属性における介在するAS(同じ2つの連続するASの間にあるAS)は、両AS_PATH属性からなるAS_SETパス・セグメントに結合する。次に、このセグメントは、集約属性の(a)で識別された2つの連続するASの間に配置する。(a)で識別された2つの連続するASが、1つの属性では互いにすぐに続いているが、別の属性では続かない場合、後者の介在ASはAS_SETパス・セグメントに結合する。このセグメントは、集約属性の(a)で識別される2つの連続するASの間に配置する。

c) 集約AS_PATHの隣接するタプルの各ペアについて、両タプルが同じタイプである場合、そうすることで255を超えるASパス長のセグメントが生成されない限り、それらを結合する。

上記の手順の結果、AS番号が集約AS_PATH属性内で複数回出現する場合、そのAS番号の最後のインスタンス(右端の出現)を除くすべてを、集約AS_PATH属性から削除する必要がある。

セキュリティに関する考慮事項

BGP実装は、RFC 2385[RFC2385]で規定されている認証メカニズムをサポートしなければならない(MUST)。このメカニズムが提供する認証は、ピアごとに実行できる。

BGPは、ピア・ルータ間のトラフィックにおける信頼性の高い伝送にTCPを使用する。ポイントツーポイント・ベースでコネクション指向の完全性とデータ発信元認証を提供するため、BGPはRFC 2385で定義されているメカニズムの使用を規定する。これらのサービスは、ルータ間のTCP接続に対するアクティブな盗聴攻撃を検出して拒否することを目的としている。これらのセキュリティ・サービスに影響を与えるメカニズムを使用しない場合、攻撃者はこれらのTCP接続を妨害したり、正当なピア・ルータになりすますことができる。RFCで定義されているメカニズムはピア・エンティティ認証を提供しないため、これらの接続は、TCP層で検出されない、何らかの形式のリプレイ攻撃を受ける可能性がある。このような攻撃は、「壊れた」または「偽装された」BGPメッセージを(TCPから)配信する結果になるかもしれない。

RFC 2385で定義されているメカニズムは通常のTCPチェックサムを、TCPチェックサムと同じデータ上で計算される16バイトのメッセージ認証コード(MAC)で補強する。このMACは、一方向ハッシュ関数(MD5)と秘密鍵の使用に基づいている。この鍵はピア・ルータ間で共有され、鍵にアクセスできない攻撃者は攻撃者が容易に計算できないMAC値を生成するために使用される。準拠する実装は、このメカニズムをサポートし、ネットワーク管理者がピアごとにこのメカニズムを有効にしなければならない。

RFC 2385は、MACの計算に使用する鍵の管理 (例えば、生成、配布、置換など)の手段は規定されていない。RFC 3562[RFC3562] (情報文書)は、この領域に関するいくつかのガイダンスを提供し、このガイダンスをサポートする根拠を示している。保護された各ピアとの通信には、異なる鍵を使用する必要があるとされている。複数のピアに同じ鍵を使用すると、提供されるセキュリティ・サービスが低下する可能性がある。例えば、1つのルータで危殆化のリスクが高まり、それが他のルータに悪影響が及ぶ可能性がある。

MACの計算に使用する鍵は、鍵の漏洩や暗号解読攻撃の成功による影響を最小限に抑えるために、定期的に変更する必要がある。RFC 3562は、暗号化期間(鍵が使用される間隔)を最大90日とすることを推奨している。鍵の変更頻度が高ければ高いほど、(前述のような)リプレイ攻撃がフィージブルになる可能性を減らすことができる。ただし、このような変更をピア間で協調して実行する標準的メカニズムがない場合、このRFCに準拠するBGP-4実装が頻繁な鍵の変更をサポートするとは想定することはできない。

当然ながら、各鍵も攻撃者が推測しにくいように選ぶべきである。RFC 1750で規定されている乱数生成の手法は、鍵として使用できる値を生成するための指針を提供する。RFC 2385では、「80バイト以下の印字可能なASCII文字列で構成される」鍵をサポートするよう実装に求めている。RFC 3562は、この文脈で使用される鍵は12～24バイトのランダム(疑似ランダム)ビットであることを推奨している。これは、通常16～20バイトの範囲の鍵を使用する類似のMACアルゴリズムの提案とほぼ一致している。この範囲の下限で十分なランダム・ビットを提供するには、RFC 3562は、一般的なACSIIテキスト文字列はRFC 2385で規定されている鍵長の上限に近いものにならざるを得ないとも指摘している。

BGPの脆弱性分析は、[RFC4272]で説明する。

IANAの考慮事項

すべてのBGPメッセージは8ビットのメッセージ・タイプを含んでおり、IANAはこれに対して「BGPメッセージ・タイプ」というレジストリを作成し、管理している。本文書では以下のメッセージ・タイプを定義する:

名前 値 定義
OPEN 1 セクション4.2参照
UPDATE 2 セクション4.3参照
NOTIFICATION 3 セクション4.5参照
KEEPALIVE 4 セクション4.4参照

将来的な割り当ては、[RFC2434]で定義されている標準化活動プロセス、または[RFC4020]で定義されている早期IANA割り当てプロセスのいずれかを使用して行われる。割り当ては、名前と値で構成される。

BGP UPDATEメッセージは1つ以上のパス属性を運ぶことができ、各属性に8ビットの属性タイプコードを含む。IANAはすでに、「BGPパス属性」というレジストリを管理している。本文書では、以下のパス属性タイプコードを定義する:

名前 値 定義
ORIGIN 1 セクション5.1.1参照
AS_PATH 2 セクション5.1.2参照
NEXT_HOP 3 セクション5.1.3参照
MULTI_EXIT_DISC 4 セクション5.1.4参照
LOCAL_PREF 5 セクション5.1.5参照
ATOMIC_AGGREGATE 6 セクション5.1.6参照
AGGREGATOR 7 セクション5.1.7参照

将来的な割り当ては、[RFC2434]で定義されている標準化活動プロセス、または[RFC4020]で定義されている早期IANA割り当てプロセスのいずれかを使用して行われる。割り当ては、名前と値で構成される。

BGP NOTIFICATIONメッセージは8ビットのエラーコードを持ち、IANAはこのエラーコードに対して「BGPエラーコード」というレジストリを作成し、管理している。本文書では、以下のエラーコードを定義する:

名前 値 定義
メッセージ・ヘッダ・エラー 1 セクション6.1
OPENメッセージ・エラー 2 セクション6.2
UPDATEメッセージ・エラー 3 セクション6.3
ホールドタイマーの期限切れ 4 セクション6.5
有限状態マシン・エラー 5 セクション6.6
停止 6 セクション6.7

将来的な割り当ては、[RFC2434]で定義されている標準化活動プロセス、または[RFC4020]で定義されている早期IANA割り当てプロセスのいずれかを使用して行われる。割り当ては名前と値で構成される。

BGP NOTIFICATIONメッセージには8ビットのエラー・サブコードを持ち、各サブコードは、特定のエラーコードのコンテキスト内で定義しなければならない。したがって、そのコンテキスト内でのみ一意でなければならない。

IANAは、各BGPエラーコードごとに個別のレジストリを持つ「エラー・サブコード」レジストリ・セットを作成し、維持している。将来の割り当ては、[RFC2434]で定義されている標準アクション・プロセス、または[RFC4020]で定義されている早期IANA割り当てプロセスを使用して行われる。割り当ては名前と値で構成される。

本文書は、以下のメッセージ・ヘッダ・エラー・サブコードを定義する:

名前 値 定義
接続が同期されていない 1 セクション6.1参照
メッセージの長さが間違っている 2 セクション6.1参照
メッセージの種類が間違っている 3 セクション6.1参照

本文書は、次のOPENメッセージ・エラー・サブコードを定義する:

名前 値 定義
サポートされていないバージョン番号 1 セクション6.2参照
ピアASが間違っている 2 セクション6.2参照
BGP識別子が間違っている 3 セクション6.2参照
オプションのパラメータがサポートされていない 4 セクション6.2参照
[非推奨] 5 付録A参照
ホールド時間が許容範囲外 6 セクション6.2参照

本文書は、以下のUPDATEメッセージ・エラー・サブコードを定義する:

名前 値 定義
属性リストが不正 1 セクション6.3参照
認識されない既知の属性 2 セクション6.3参照
既知の属性が欠落している 3 セクション6.3参照
属性フラグ エラー 4 セクション6.3参照
属性の長さエラー 5 セクション6.3参照
無効なORIGIN 属性 6 セクション6.3参照
[非推奨] 7 付録Aを参照
無効なNEXT_HOP属性 8 セクション6.3参照
オプション属性エラー 9 セクション6.3参照
無効なネットワーク・フィールド 10 セクション6.3参照
不正なAS_PATH 11 セクション6.3参照

引用規格

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981, <https://www.rfc-editor.org/rfc/rfc791>.

[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981, <https://www.rfc-editor.org/rfc/rfc793>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998, <https://www.rfc-editor.org/rfc/rfc2385>.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998, <https://www.rfc-editor.org/rfc/rfc2434>.

参考規格

[RFC904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984, <https://www.rfc-editor.org/rfc/rfc904>.

[RFC1092] Rekhter, J., "EGP and policy based routing in the new NSFNET backbone", RFC 1092, February 1989, <https://www.rfc-editor.org/rfc/rfc1092>.

[RFC1093] Braun, H., "NSFNET routing architecture", RFC 1093, February 1989, <https://www.rfc-editor.org/rfc/rfc1093>.

[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989, <https://www.rfc-editor.org/rfc/rfc1105>.

[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990, <https://www.rfc-editor.org/rfc/rfc1163>.

[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991, https://www.rfc-editor.org/rfc/rfc1267>.

[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995, <https://www.rfc-editor.org/rfc/rfc1771>.

[RFC1772] Rekhter, Y. and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995, <https://www.rfc-editor.org/rfc/rfc1772>.

[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993, <https://www.rfc-editor.org/rfc/rfc1518>.

[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993, <https://www.rfc-editor.org/rfc/rfc1519>.

[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996, <https://www.rfc-editor.org/rfc/rfc1930>.

[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996, <https://www.rfc-editor.org/rfc/rfc1997>.

[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998, <https://www.rfc-editor.org/rfc/rfc2439>.

[RFC2474] 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, <https://www.rfc-editor.org/rfc/rfc2474>.

[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000, <https://www.rfc-editor.org/rfc/rfc2796>.

[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000, <https://www.rfc-editor.org/rfc/rfc2858>.

[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002, <https://www.rfc-editor.org/rfc/rfc3392>.

[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000, <https://www.rfc-editor.org/rfc/rfc2918>.

[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001, <https://www.rfc-editor.org/rfc/rfc3065>.

[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003, <https://www.rfc-editor.org/rfc/rfc3562>.

[IS10747] "Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993, <https://www.iso.org/obp/ui/en/#iso:std:iso-iec:10747:ed-1:v1:en>.

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006, <https://www.rfc-editor.org/rfc/rfc4272>.

[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005, <https://www.rfc-editor.org/rfc/rfc4020>.

編集者のアドレス

ヤコフ・レクター
Juniper Networks
メールアドレス: <yakov@juniper.net>

トニー・リー
メールアドレス: <tony.li@tony.li>

スーザン・ハレス
NextHop Technologies, Inc.
825 Victors Way
Ann Arbor, MI 48108
電話: (734)222-1610
メールアドレス: <skh@nexthop.com>

完全な著作権に関する声明

著作権 (C) The Internet Society (2006)。

本文書は、BCP 78に含まれる権利、ライセンス、制限に従うものであり、そこに規定されている場合を除き、著者はすべての権利を保持する。

本文書およびここに含まれる情報は「現状のまま」で提供されるものであり、寄稿者、寄稿者が代表または後援する組織(存在する場合)、インターネット協会およびインターネット・エンジニアリング・タスク・フォースは、すべての保証を否認する。これは、明示または黙示を問わず、ここに記載された情報の使用がいかなる権利も侵害しないという保証、または商品性や特定の目的への適合性の黙示的な保証を含むが、これに限定されない。

知的財産

IETFは、本文書に記載されたテクノロジーの実装または使用に関連すると主張されうる知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスがどの程度利用可能か不可能かに関して、いかなる立場も取らない。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを表明するものでもない。RFC文書の権利に関する手続きに関する情報は、BCP 78およびBCP 79に記載されている。

IETF事務局に対して行われたIPR開示の写し、および利用可能になるライセンスの保証、または本仕様の実装者や利用者がそのような保有権の使用するための一般ライセンスや許可を取得しようとする試みの結果は、IETFのオンラインIPRリポジトリ(<http://www.ietf.org/ipr>) から入手できる。

IETFは、本規格の実装に必要とされる技術をカバーする著作権、特許、特許出願、その他の保有権について、利害関係者に対して注意を喚起するよう求める。情報はIETF(<ietf-ipr@ietf.org>)に送っていただきたい。

謝辞

RFCエディタ機能の資金は、IETF管理支援活動(IASA)が提供している。

更新履歴

  • 2024.8.19
GitHubで編集を提案

Discussion