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

9. UPDATE Message Handling (UPDATEメッセージ処理)

  1. UPDATE Message Handling (UPDATEメッセージ処理)

    UPDATEメッセージはEstablished状態でのみ受信できます。他の状態でUPDATEメッセージを受信することはエラーです。UPDATEメッセージを受信すると、セクション6.3で指定されているように、各フィールドの妥当性がチェックされます。

    オプションの非推移属性が認識されない場合、それは静かに無視されます。オプションの推移属性が認識されない場合、属性フラグオクテットのPartialビット（3番目の上位ビット）が1に設定され、その属性は他のBGPスピーカーへの伝播のために保持されます。

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

    UPDATEメッセージに空でないWITHDRAWN ROUTESフィールドが含まれている場合、このフィールドに含まれる宛先（IPプレフィックスとして表現）を持つ、以前にアドバタイズされたルートは、Adj-RIB-Inから削除されなければなりません (SHALL)。以前にアドバタイズされたルートが使用できなくなったため、このBGPスピーカーはそのDecision Processを実行しなければなりません (SHALL)。

    UPDATEメッセージに実行可能なルートが含まれている場合、Adj-RIB-Inは次のようにこのルートで更新されます: 新しいルートのNLRIが、Adj-RIB-Inに現在格納されているルートのNLRIと同一である場合、新しいルートはAdj-RIB-In内の古いルートを置き換えなければならず (SHALL)、したがって古いルートを暗黙的にサービスから撤回します。それ以外の場合、Adj-RIB-Inに新しいルートと同一のNLRIを持つルートがない場合、新しいルートはAdj-RIB-Inに配置されなければなりません (SHALL)。

    BGPスピーカーがAdj-RIB-Inを更新すると、スピーカーはそのDecision Processを実行しなければなりません (SHALL)。

9.1. Decision Process (決定プロセス)

Decision Processは、ローカルPolicy Information Base (PIB)のポリシーをAdj-RIBs-Inに格納されたルートに適用することで、後続のアドバタイズメントのためのルートを選択します。Decision Processの出力は、ピアにアドバタイズされるルートのセットです。選択されたルートは、ポリシーに従って、ローカルスピーカーのAdj-RIBs-Outに格納されます。

ここで説明するBGP Decision Processは概念的なものであり、記述されたとおりに正確に実装する必要はありません。実装が記述された機能をサポートし、同じ外部から見える動作を示す限り。

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

指定されたルートの優先度を計算する関数は、以下のいずれもその入力として使用してはなりません (SHALL NOT): 他のルートの存在、他のルートの非存在、または他のルートのパス属性。次に、ルート選択は、各実行可能なルートへの優先度関数の個別の適用と、それに続く最高の優先度を持つものの選択で構成されます。

Decision ProcessはAdj-RIBs-Inに含まれるルートで動作し、以下の責任があります:

  • スピーカーによってローカルで使用されるルートの選択

  • 他のBGPピアにアドバタイズされるルートの選択

  • ルート集約とルート情報削減

Decision Processは、それぞれ異なるイベントによってトリガーされる3つの異なるフェーズで行われます:

a) フェーズ1は、ピアから受信した各ルートの優先度の計算を担当します。

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

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

9.1.1. Phase 1: Calculation of Degree of Preference (フェーズ1: 優先度の計算)

フェーズ1決定関数は、ローカルBGPスピーカーがピアから新しいルート、置換ルート、または撤回されたルートをアドバタイズするUPDATEメッセージを受信するたびに呼び出されます。

フェーズ1決定関数は別個のプロセスであり、それ以上の作業がない場合に完了します。

フェーズ1決定関数は、その中に含まれるルートで動作する前にAdj-RIB-Inをロックし、その中に含まれるすべての新しいまたは実行不可能なルートで動作した後にロックを解除します。

新しく受信されたまたは置換された実行可能なルートごとに、ローカルBGPスピーカーは次のように優先度を決定します:

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

ルートが外部ピアから学習された場合、ローカルBGPスピーカーは事前設定されたポリシー情報に基づいて優先度を計算します。戻り値がルートが資格がないことを示す場合、ルートはルート選択の次のフェーズへの入力として機能してはなりません (MAY NOT)。それ以外の場合、戻り値はIBGP再アドバタイズメントでLOCAL_PREF値として使用されなければなりません (MUST)。

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

9.1.2. Phase 2: Route Selection (フェーズ2: ルート選択)

フェーズ2決定関数は、フェーズ1の完了時に呼び出されます。フェーズ2関数は別個のプロセスであり、それ以上の作業がない場合に完了します。フェーズ2プロセスは、Adj-RIBs-Inで資格のあるすべてのルートを考慮します。

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

BGPルートのNEXT_HOP属性が解決できないアドレスを示している場合、またはルートがルーティングテーブルにインストールされた場合に解決できなくなる場合、BGPルートはフェーズ2決定関数から除外されなければなりません (MUST)。

BGPルートのAS_PATH属性にASループが含まれている場合、BGPルートはフェーズ2決定関数から除外されるべきです (SHOULD)。ASループ検出は、完全なASパス（AS_PATH属性で指定）をスキャンし、ローカルシステムの自律システム番号がASパスに表示されないことを確認することで行われます。ASパスに独自の自律システム番号を持つルートを受け入れるように構成されたBGPスピーカーの動作は、この文書の範囲外です。

AS内のBGPスピーカーが、転送ループが発生する原因となるルート選択に関して矛盾した決定を下さないことが重要です。

Adj-RIBs-Inに実行可能なルートが存在する宛先のセットごとに、ローカルBGPスピーカーは次のようなルートを識別します:

a) 同じ宛先セットへの任意のルートの中で最高の優先度を持つ、または

b) その宛先への唯一のルートである、または

c) セクション9.1.2.2で指定されたフェーズ2タイブレーキングルールの結果として選択された

ローカルスピーカーは、Loc-RIBにそのルートをインストールし、現在Loc-RIBに保持されている同じ宛先へのルートを置き換えなければなりません (SHALL)。新しいBGPルートがルーティングテーブルにインストールされるとき、現在無効と見なされている同じ宛先への既存のルートがルーティングテーブルから削除されることを確認するために注意する必要があります。新しいBGPルートがルーティングテーブル内の既存の非BGPルートを置き換えるかどうかは、BGPスピーカーで構成されたポリシーに依存します。

ローカルスピーカーは、選択されたルートのNEXT_HOP属性から即座の次のホップアドレスを決定しなければなりません (MUST)（セクション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. Route Resolvability Condition (ルート解決可能性条件)

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

ルート解決可能性条件は次のように定義されます:

  1. 中間ネットワークアドレスのみを参照するルートRte1は、ルーティングテーブルにRte1の中間ネットワークアドレスと一致する少なくとも1つの解決可能なルートRte2が含まれており、Rte1を通じて（直接的または間接的に）再帰的に解決されていない場合、解決可能と見なされます。複数の一致するルートが利用可能な場合、最長一致ルートのみが考慮されるべきです (SHOULD)。

  2. インターフェイス（中間アドレスの有無にかかわらず）を参照するルートは、参照されるインターフェイスの状態がupであり、このインターフェイスでIP処理が有効になっている場合、解決可能と見なされます。

BGPルートはインターフェイスを参照しませんが、両方のタイプ（インターフェイスを指定するものとそうでないもの）のルーティングテーブル内のルートを通じて解決できます。IGPルートと直接接続されたネットワークへのルートは、アウトバウンドインターフェイスを指定することが期待されます。スタティックルートは、アウトバウンドインターフェイス、中間アドレス、またはその両方を指定できます。

BGPルートは、BGPスピーカーのルーティングテーブルにBGPルートのNEXT_HOPと一致するルートが含まれていない状況では、解決不可能と見なされることに注意してください。相互再帰ルート（お互いまたは自分自身を解決するルート）も解決可能性チェックに失敗します。

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

BGPスピーカーが相互再帰のために解決可能性チェックに失敗するルートを識別するたびに、エラーメッセージをログに記録すべきです (SHOULD)。

9.1.2.2. Breaking Ties (Phase 2) (タイブレーキング（フェーズ2）)

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

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

タイブレーキングアルゴリズムは、同じ宛先へのすべての同等に好ましいルートを考慮することから始まり、次に考慮から削除するルートを選択します。アルゴリズムは、考慮中のルートが1つだけ残るとすぐに終了します。基準は指定された順序で適用されなければなりません (MUST)。

いくつかの基準は疑似コードを使用して説明されています。示されている疑似コードは効率ではなく明確さのために選択されたことに注意してください。特定の実装を指定することを意図していません。BGP実装は、ここで説明されているものと同じ結果を生成する任意のアルゴリズムを使用できます (MAY)。

a) AS_PATH属性に存在するAS番号の最小数でタイになっていないすべてのルートを考慮から削除します。この数をカウントするとき、AS_SETは、セット内のAS数に関係なく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です。

MULTI_EXIT_DISC属性がIBGPにルートを再アドバタイズする前に削除される場合、受信した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はDecision Processのこのステップに到達するルート比較で使用されなければなりません (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 Identifier値を持つBGPスピーカーによってアドバタイズされたルート以外のすべてのルートを考慮から削除します。

g) 最小のピアアドレスから受信したルートを優先します。

9.1.3. Phase 3: Route Dissemination (フェーズ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. Overlapping Routes (重複ルート)

BGPスピーカーは、重複するNetwork Layer Reachability Information (NLRI)を持つルートを別のBGPスピーカーに送信できます。NLRI重複は、一致しない複数のルートで宛先のセットが識別されるときに発生します。BGPはIPプレフィックスを使用してNLRIをエンコードするため、重複は常にサブセット関係を示します。より小さな宛先セット（より長いプレフィックス）を記述するルートは、より大きな宛先セット（より短いプレフィックス）を記述するルートよりも具体的であると言われます。同様に、より大きな宛先セットを記述するルートは、より小さな宛先セットを記述するルートよりも一般的であると言われます。

優先関係は、より一般的なルートを効果的に2つの部分に分解します:

  • より一般的なルートのみによって記述される宛先のセット、および

  • より一般的なルートとより具体的なルートの重複によって記述される宛先のセット

重複によって記述される宛先のセットは、実行可能であるが現在使用されていないより一般的なルートの一部を表します。より具体的なルートが後で撤回された場合でも、重複によって記述される宛先のセットは、より一般的なルートを使用して到達可能です。

BGPスピーカーが重複するルートを受信する場合、Decision Processは構成された受け入れポリシーに基づいて両方のルートを考慮しなければなりません (MUST)。より一般的なルートとより具体的なルートの両方が受け入れられる場合、Decision Processは、Loc-RIBに、より一般的なルートとより具体的なルートの両方をインストールするか、2つのルートを集約し、Loc-RIBに集約されたルートをインストールしなければなりません (MUST)。ただし、両方のルートがNEXT_HOP属性の同じ値を持つ場合に限ります。

BGPスピーカーが集約を選択する場合、集約を形成するために使用されるすべてのASをAS_SETに含めるか、ATOMIC_AGGREGATE属性をルートに追加すべきです (SHOULD)。この属性は現在主に情報提供です。クラスレスルーティングをサポートしないIPルーティングプロトコルの廃止、およびクラスレスルーティングをサポートしないルーターとホスト実装の廃止により、非集約化の必要性はもはやありません。ルートは非集約化されるべきではありません (SHOULD NOT)。特に、ATOMIC_AGGREGATE属性を持つルートは非集約化されてはなりません (MUST NOT)。つまり、このルートのNLRIはより具体的にすることはできません。そのようなルートに沿った転送は、IPパケットがルートのAS_PATH属性にリストされているASのみを実際に通過することを保証しません。

9.2. Update-Send Process (Update-Sendプロセス)

Update-SendプロセスはUPDATEメッセージをすべてのピアにアドバタイズする責任があります。たとえば、Decision Processによって選択されたルートを、同じ自律システムまたは隣接する自律システムに配置される可能性のある他のBGPスピーカーに配布します。

BGPスピーカーが内部ピアからUPDATEメッセージを受信すると、受信BGPスピーカーはそのUPDATEメッセージに含まれるルーティング情報を他の内部ピアに再配布してはなりません (SHALL NOT)（スピーカーがBGP Route Reflector [RFC2796]として機能しない限り）。

ルート選択プロセスのフェーズ3の一部として、BGPスピーカーはそのAdj-RIBs-Outを更新しました。新しくインストールされたすべてのルートと、置換ルートがないすべての新しく実行不可能なルートは、UPDATEメッセージによってピアにアドバタイズされなければなりません (SHALL)。

BGPスピーカーは、以前にアドバタイズされたものと同じBGPルートを含むUPDATEメッセージを生成する場合、Adj-RIB-Outから指定された実行可能なBGPルートをアドバタイズすべきではありません (SHOULD NOT)。

Loc-RIBで実行不可能としてマークされたルートは削除されなければなりません (SHALL)。独自の自律システム内の到達可能な宛先への変更も、UPDATEメッセージでアドバタイズされなければなりません (SHALL)。

UPDATEメッセージの最大サイズの制限（セクション4を参照）のために、単一のルートがメッセージに収まらない場合、BGPスピーカーはピアにルートをアドバタイズしてはならず (MUST NOT)、ローカルでエラーをログに記録することを選択できます (MAY)。

9.2.1. Controlling Routing Traffic Overhead (ルーティングトラフィックオーバーヘッドの制御)

BGPプロトコルは、UPDATEメッセージをアドバタイズするために必要なリンク帯域幅と、UPDATEメッセージに含まれる情報を処理するために必要な処理能力の両方を制限するために、ルーティングトラフィックの量（つまり、UPDATEメッセージ）を制約します。

9.2.1.1. Frequency of Route Advertisement (ルートアドバタイズメントの頻度)

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

いくつかの共通の宛先セットへの実行可能なルートおよび/または実行不可能なルートの撤回をアドバタイズするBGPスピーカーからピアに送信される2つのUPDATEメッセージは、少なくともMinRouteAdvertisementIntervalTimerで区切られなければなりません (MUST)。これは、共通の宛先セットごとに別々のタイマーを保持することによってのみ達成できます。これは不当なオーバーヘッドになります。いくつかの共通の宛先セットへの実行可能なルートおよび/または実行不可能なルートの撤回をアドバタイズするBGPスピーカーからピアに送信される2つのUPDATEメッセージ間の間隔が少なくともMinRouteAdvertisementIntervalTimerであることを保証し、間隔に一定の上限も保証する任意の技術が許容されます。

自律システム内では高速収束が必要であるため、(a)内部ピアに使用されるMinRouteAdvertisementIntervalTimerは外部ピアに使用されるMinRouteAdvertisementIntervalTimerよりも短くすべき (SHOULD)、または(b)このセクションで説明する手順は内部ピアに送信されるルートに適用されるべきではありません (SHOULD NOT)。

この手順はルート選択のレートを制限するのではなく、ルートアドバタイズメントのレートのみを制限します。MinRouteAdvertisementIntervalTimerの有効期限を待っている間に新しいルートが複数回選択される場合、MinRouteAdvertisementIntervalTimerの終了時に最後に選択されたルートがアドバタイズされなければなりません (SHALL)。

9.2.1.2. Frequency of Route Origination (ルート発信の頻度)

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

9.2.2. Efficient Organization of Routing Information (ルーティング情報の効率的な組織)

アドバタイズするルーティング情報を選択した後、BGPスピーカーはこの情報を効率的な方法で組織するためにいくつかの方法を利用できます。

9.2.2.1. Information Reduction (情報削減)

情報削減は、ポリシー制御の粒度の削減を意味する可能性があります - 情報が折りたたまれた後、同じポリシーが等価クラス内のすべての宛先とパスに適用されます。

Decision Processは、次のいずれかの方法でAdj-RIBs-Outに配置する情報の量をオプションで削減できます:

a) Network Layer Reachability Information (NLRI):

宛先IPアドレスはIPアドレスプレフィックスとして表現できます。アドレス構造と自律システム管理者の制御下にあるシステムとの間に対応がある場合、UPDATEメッセージで運ばれるNLRIのサイズを減らすことができます。

b) AS_PATHs:

ASパス情報は、順序付けられたAS_SEQUENCEまたは順序付けられていないAS_SETとして表現できます。AS_SETは、セクション9.2.2.2で説明されているルート集約アルゴリズムで使用されます。複数のAS_PATHが集約されたときに各AS番号が何回出現したかに関係なく、各AS番号を1回だけリストすることで、AS_PATH情報のサイズを減らします。

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

9.2.2.2. Aggregating Routing Information (ルーティング情報の集約)

集約は、いくつかの異なるルートの特性を組み合わせて、単一のルートをアドバタイズできるようにするプロセスです。集約は、Adj-RIBs-Outに配置される情報の量を削減するために、Decision Processの一部として発生する可能性があります。

集約により、BGPスピーカーが保存し、他のBGPスピーカーと交換する必要がある情報の量が削減されます。ルートは、同じタイプのパス属性とNetwork Layer Reachability Informationに次の手順を個別に適用することで集約できます。

異なるMULTI_EXIT_DISC属性を持つルートは集約されてはなりません (SHALL NOT)。

集約されたルートがAS_PATH属性の最初の要素としてAS_SETを持つ場合、ルートを発信するルーターは、このルートでMULTI_EXIT_DISC属性をアドバタイズすべきではありません (SHOULD NOT)。

異なるタイプコードを持つパス属性は一緒に集約できません。同じタイプコードのパス属性は、次のルールに従って集約できます:

NEXT_HOP: 異なるNEXT_HOP属性を持つルートを集約する場合、集約されたルートのNEXT_HOP属性は、集約を実行するBGPスピーカー上のインターフェイスを識別しなければなりません (SHALL)。

ORIGIN attribute: 集約されるルートの中の少なくとも1つのルートがINCOMPLETEの値を持つORIGINを持つ場合、集約されたルートはINCOMPLETEの値を持つORIGIN属性を持たなければなりません (MUST)。それ以外の場合、集約されるルートの中の少なくとも1つのルートがEGPの値を持つORIGINを持つ場合、集約されたルートはEGPの値を持つORIGIN属性を持たなければなりません (MUST)。他のすべての場合、集約されたルートのORIGIN属性の値はIGPです。

AS_PATH attribute: 集約されるルートが同一の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に表示されなければなりません。

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

  • 集約されたAS_PATH内でタプルYに先行する集約されたAS_PATH内のタイプAS_SEQUENCEの任意のタプルXについて、Yを含む初期セット内の各AS_PATH内でXはYに先行します。Yのタイプに関係なく。

  • 同じ値を持つタイプAS_SETのタプルは、集約されたAS_PATH内に複数回表示されてはなりません。

  • 同じ値を持つタイプ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パス属性を持つ場合、集約されたルートもこの属性を持たなければなりません (SHALL)。

AGGREGATOR: 集約されるルートからのAGGREGATOR属性は、集約されたルートに含めてはなりません (MUST NOT)。ルート集約を実行するBGPスピーカーは、新しいAGGREGATOR属性を添付できます (MAY)（セクション5.1.7を参照）。

9.3. Route Selection Criteria (ルート選択基準)

一般に、いくつかの代替案の間でルートを比較するための追加のルールは、この文書の範囲外です。2つの例外があります:

  • 考慮されている新しいルートのASパスにローカルASが表示される場合、その新しいルートは他のルートよりも優れているとは見なされません（スピーカーがそのようなルートを受け入れるように構成されている場合）。そのようなルートが使用された場合、ルーティングループが発生する可能性があります。

  • 成功した分散動作を達成するために、安定性の可能性があるルートのみを選択できます。したがって、ASは不安定なルートの使用を避けるべきであり (SHOULD)、ルートの選択に迅速で自発的な変更を行うべきではありません (SHOULD NOT)。「不安定」および「迅速」という用語（前の文から）を定量化するには経験が必要ですが、原則は明確です。不安定なルートは「ペナルティ化」できます（例えば、[RFC2439]で説明されている手順を使用）。

9.4. Originating BGP routes (BGPルートの発信)

BGPスピーカーは、他の手段（例えば、IGPを介して）によって取得したルーティング情報をBGPに注入することにより、BGPルートを発信できます。BGPルートを発信するBGPスピーカーは、Decision Processを通過させることにより、これらのルートに優先度（例えば、ローカル構成に従って）を割り当てます（セクション9.1を参照）。これらのルートは、更新プロセスの一部として、ローカルAS内の他のBGPスピーカーに配布されることもあります (MAY)（セクション9.2を参照）。AS内で非BGP取得ルートをBGPを介して配布するかどうかの決定は、AS内の環境（例えば、IGPのタイプ）に依存し、構成を介して制御されるべきです (SHOULD)。

に最終更新