Network Working Group D. Haskin Request For Comments: 1863 Bay Networks, Inc. Category: Experimental October 1995 フルメッシュ型の経路制御に対する BGP/IDRP ルートサーバという選択肢 このメモのステータス このメモはインターネットコミュニティに対する Experimental なプロトコルを 定義する。このメモはいかなる種類のインターネットスタンダードをも指定しない。 改善のための議論と提案が求められる。このメモの配布は無制限である。 概略 本文書は、BGP/IDRP を話すルータ間における経路制御情報配布を目的とした ルートサーバの設計の詳細と仕様について記述する。 紹介される技術の内容は、オーバヘッドと多数の直接的な BGP/IDRP セッションを 管理する複雑さを削減する。単一の経路制御ドメイン内のルータ間や、共通の スイッチ型 fabric (ATM 雲のような) で接続された異なるドメインのルータ間では、 BGP/IDRP セッション以外のものが必要とされ、望まれるかもしれない。 1. 概観 Border Gateway Protocol [BGP4] や ISO Inter-Domain Routing Protocol [IDRP]を 改変したもののような、いわゆる Exterior 経路制御プロトコルでは、ドメイン間の 経路制御に関与し (ボーダルータであり)、かつ同じ経路制御ドメインに属する 全 BGP/IDRP ルータはフルメッシュの接続性を確立することが求められる。 これは他の経路制御ドメインから獲得した経路制御情報を交換するためである。 大規模な経路制御ドメインでは、このボーダルータを維持するために必要とされる ドメイン内のコネクション数が著しい数になり得る。 更に、ボーダルータは共有している通信メディアを通して到達可能な他の ドメイン内の全ボーダルータと経路制御セッションを確立することを求められる ことがある。本文書では共用しているメディアを通じて直接到達可能なルータを adjacent ルータと呼ぶ。このような直接的な peering によって、ルータは adjacent ルータから直接到達可能な送信先に関して `直接的な' 情報を獲得する ことができ、その送信先への最適な直接のパスを選択することができるようになる。 BGP/IDRP セッションを全ての adjacent ボーダルータの間で確立すると、 フルメッシュ状の経路制御コネクティビティになる。不幸なことに、莫大な数を 接続する ATM,SMDS,フレームリレーネットワークのようなスイッチ型の メディアでは、ルータ間でフルメッシュ状の直接的な peering を維持するためには 多数のコネクションが必要とされるので、このアプローチは実際的なものでは なくなっている。 `フルメッシュ' 問題を軽減するために、本稿ではクライアントルータ間で、 external な経路を全属性を含めて中継する IDRP/BGP ルートサーバの使用を 提案する。クライアントは割り当てられたルートサーバとだけ IDRP/BGP セッションを維持する。(冗長性が望まれるのであれば、2 つ以上のサーバと セッションを持つことが必要になる)。あるクライアントが受信した全経路は ルートサーバによって他のクライアントに伝播される。全ての external な経路と その属性は何も変更されずにクライアントルータ間を中継されるので、クライアント ルータは自分が直接的な peering をして得られるのと同じ経路制御情報を 獲得することができる。このような関係を virtual peering と呼ぶ。 virtual peering によって、クライアントルータは、直接的な peering が確立する のであれば適用したであろうローカルなポリシに基づいた独自の選択基準を、 獲得した external な経路に対して適用することができる。 本稿で述べられる経路制御のアプローチは、ボーダルータは virtual peer から 獲得したいかなる経路に対しても、ネクストホップルータのメディアアクセス アドレスを見つけられる機構を持っていることを仮定している。 公正を期すために注記しておくと、本稿で紹介するアプローチは各ボーダルータを 維持するために必要なコネクション数を削減するものであって、各ボーダルータを 維持するために必要な経路制御情報の量を減らすものではない。 `フルメッシュ' 問題を処理する他にも、本稿の提案は以下のゴールを達成しようと 試みている。 - ルートサーバとオペレーションを行なうためにクライアントに実装される必要が ある BGP/IDRP の修正を最小限にとどめること。 - ルートサーバクライアントへの経路情報配布に関して冗長性を提供すること。 - ルートサーバクライアントに送信する経路制御情報更新の量を最小化すること。 - ルートサーバ間で負荷分散する仕組みを提供すること。 - ルートサーバ間の相互作用によって極端に複雑になることを避けること。 2. 単語と頭字語 以下の単語と頭字語が本稿の中で使用されている。 経路制御ドメイン 同じ経路制御ポリシを持つルータをまとめたもの。IPv4 では、AS 番号によって 識別される。IPv6 では経路制御ドメイン識別子によって識別される。 ボーダルータ (BR) external 経路、すなわち、経路制御ドメイン外にあるインターネットポイント への経路を獲得しているルータ。 ルートサーバ (RR) ボーダルータからの経路制御情報を収集し、`クライアントルータ' に配布する 処理系。 RS クライアント (RC) 経路制御情報を獲得するために RS と peering しているルータ。サーバの クライアントはルータか、他のルートサーバである。 RS クラスタ (RSC) 同じクライアントのサブセットを持つ 2 つ以上のルートサーバ。RS クラスタは 経路制御情報の冗長性を提供する。すなわち、RS クラスタ内に少なくとも 1 つ functional なルートサーバが存在する限り、RS クラスタクライアント全てに 経路制御情報が提供される。 RCID クラスタ ID。 3. RS モデル 提案されている機構では、ルートサーバ (RS) はボーダルータから受信した経路に 関して、クライアントへの配布のために何らかの選択基準を適用することはしない。 ボーダルータもしくは他のルートサーバから獲得した全ての経路はクライアント ボーダルータに中継される。 ルートサーバには 2 つのクラスが考えられる。external 経路を単一の経路制御 ドメイン内のルータに中継するルートサーバと、異なる経路制御ドメインのボーダ ルータとの間で external 経路の中継を行なうルートサーバである。前者は イントラドメイン・ルートサーバ、後者はインタードメイン・ルートサーバである。 本文書の中で提案される RS モデルでは、イントラドメイン・ルートサーバと インタードメイン・ルートサーバの間で経路制御情報の交換は行なわれない。 ドメイン境界をまたぐ経路は、その経路に対して管理フィルタを適用するような ドメインのボーダルータを常に通過しなければならない。 イントラドメイン・ルートサーバとインタードメイン・ルートサーバの オペレーションは同一である。 1 つか、それ以上のルートサーバは RS クラスタ (RSC) を形成する。冗長性を得る ために、2 つかそれ以上の RS を 1 つの RS クラスタ内でオペレートできるよう 設定することができる。RSC 内の全ルートサーバはクライアントを共有する。 すなわち、クラスタクライアントは、経路制御情報交換のために、RSC に含まれる 全ルートサーバとコネクションを確立する。各クラスタには、2 オクテットで表現 される唯一の RSC 識別子 (RCID) が割り当てられる。 クライアントとの間に virtual なコネクティビティを提供するクラスタは、 一般に参加クライアント全てに全 external 経路が伝播されるようにクライアントと 経路制御情報の交換を行なう。 ルートサーバクライアント (RC) は複数の RSC と関係を持つことができるが、 そうすることによって得られる実質的な利益は無いように思われる。ただし、 短時間である RSC から他の RSC への切替えをきれいに行ないたい場合や、 何らかの理由で経路制御情報を交換していない複数の RS グループが存在する 場合は例外である。 クラスタ間の経路情報交換はクラスタ間でフルメッシュ状の経路制御 adjacency を 形成することによって達成可能である。このアプローチでは、以下の図に示すように 各 RSC 内の RS それぞれが他の RS クラスタ内の全 RS と経路制御コネクションを 維持することになる。ボーダルータから獲得された経路だけが他の RS クラスタ内の RS に伝播される。 BR11 BR12 BR1n BR21 BR22 BR2n | | ... | | | ... | ----------------- ------------------ ! RS11 RS12 ! --- ! RS21 RS22 ! ----------------- ------------------ \ / \ / ----------------- ! RS31 RS32 ! ----------------- | | ... | BR31 BR32 BR3n クラスタ間で経路制御情報を交換するもう 1 つの方法は、クラスタの階層を形成し、 ある RS は designated クラスタ内の RS とだけセッションを維持することである。 このアプローチでは RS は獲得した経路全てを、その経路を獲得したクラスタを除く 全クラスタの RS に広告しなければならない。それでもなお、幾つかのネット ワークで望まれる経路制御セッションの数を最小にすることができる。階層的な 構造にとって、クラスタ間の経路制御情報交換のリンクが tree を形成することは 重要である。つまり、任意の 2 つのクラスタ間の経路伝播パスは 1 つしか存在 しない。そうしないと経路制御ループが発生する可能性がある。階層化された クラスタトポロジにおいて経路制御ループを検知し、削除するために、ルートサーバ 間で送信される経路情報の更新全てに `RCID パス'(4.3.4 参照) 属性を含ませる ことを推奨する。この属性は経路伝播パスが今まで経てきた全クラスタの ID を リストする。この属性内に重複した ID が発見された場合、その誤った経路は破棄 される必要がある。 以下の図は、先に示した図からクラスタ 2、3 間の経路情報交換リンクを削除する ことによって階層的なアプローチを作成した例を描いたものである。 BR11 BR12 BR1n BR21 BR22 BR2n | | ... | | | ... | ----------------- ------------------ ! RS11 RS12 ! --- ! RS21 RS22 ! ----------------- ------------------ \ \ ----------------- ! RS31 RS32 ! ----------------- | | ... | BR31 BR32 BR3n 階層的なモデルの欠点は、クラスタ間のリンクが常に tree を形成することを保証 することによって経路制御ループや冗長な情報の流れを避けるといった、管理に 関して頭を痛めることだけであるように見える。しかし、フルメッシュモデルと 階層モデルの長所を比較調査するためには、更なる研究が必要とされる。 同じクラスタ内の RS は同じクライアントの集合と経路制御セッションを維持して いるので、同じクラスタ内の RS 間で経路制御情報を交換する必要はないように 思えるかもしれない。それでもこのような経路情報の交換はサーバがクライアントを 獲得している時や部分的な障害が一部の経路制御セッションに影響を及ぼすような 時に同一の経路制御データベースを維持するために役立つ。 同じ RS クラスタ内にあるルートサーバは、クライアントへに経路制御情報を提供 する責任を細分化しようと試みる制御メッセージを交換する。RS の設計を簡潔に するために、RS のメッセージングはルートサーバが経路制御情報を交換するために 使用する exterior プロトコルのトップで実装される。 4. オペレーション 4.1 ADVERTISER パス属性 ルートサーバはボーダルータから獲得した経路に対してコンセントレータの役割を 演じる。この際にボーダルータが 1 つか 2 つの designated ルートサーバとだけ 経路制御コネクションを維持すればいいように注意が払われる。ルートサーバは ボーダルータから提供される経路制御情報を全クライアントに配布する。 ここで、もし経路制御情報が現在 BGP-4/IDRP の仕様で定義されているパス属性 だけを付けられた UPDATE メッセージで RS クライアントに中継されると、 RS クライアントは彼らが受信した external 経路と、その経路をルートサーバに 提出したボーダルータとの関係がつかめなくなってしまう。この関係は正しい 経路の選択を決定するために必要である。そこで、新しいパス属性 ADVERTISER を を定義する。 ADVERTISER はオプショナルな他動でない属性で、ある経路をルートサーバに 提出し、他の RS クライアントへの中継を行なわせたボーダルータの識別アドレスが 定義される。ADVERTISER 属性のタイプコードは 255 である。この属性は ルートサーバに中継される全 UPDATE メッセージに含まれなければならず、 また RS クライアントに理解されなければならない。 4.2 ルートクライアントのオペレーション RS クライアントは、ルートクライアントが割り当てられた RS クラスタ内の 各ルートサーバと BGP/IDRP コネクションを確立する。 RS クライアントは、ルートサーバから受信した UPDATE メッセージすべてに 含まれる ADVERTISER パス属性を理解しなければならない。ルートサーバから 受信した UPDATE メッセージに含まれる経路は、ADVERTISER 属性で指定される ボーダルータから直接受信したかのように処理される。 RS クライアントがイントラドメイン・ルートサーバから経路を受信した場合、 ADVERTISER 属性で識別されるボーダルータは受信クライアントが属するのと 同じ経路制御ドメインに存在すると仮定される。 RS クライアントがインタードメイン・ルートサーバから経路を受信した場合、 ADVERTISER 属性で識別されるボーダルータの場所は BGP であれば AS_PATH 属性、 IDRP であれば RD_PATH 属性によってそれぞれ決定される。 ルートサーバから受信した UPDATE メッセージに ADVERTISER 属性が含まれて いない場合、ルートサーバ自身がその経路の広告者 (advertiser) であると仮定 される。 UPDATE メッセージの NEXT_HOP パス属性に受信したルータ自身がリストされて いたなら、そのような更新メッセージに運ばれてきた経路は到達不可能と宣言 されなければならない。 更に、強制ではないにしても非常に強く望まれるのが、以下に示すような RS から経路を受信する際の `標準的な' BGP/IDRP オペレーションの軽微な 修正である: RS から経路を受信し、その経路が先だって同じクラスタに属する別の RS から獲得したのと全く同じ属性を持つのであれば、先に獲得した経路は 新たに獲得した経路と置き換えられるべきである。また、このような経路の 置き換えは、いかなる経路広告アクションのトリガーにもなるべきではない。 RS は、RS クライアントが同じ経路のコピーを複数保持する必要をなくし、 ルートサーバへの冗長な BGP/IDRP 接続が消失した場合のルートフラップの 可能性を最小にするように設計されている。 1 つの RS が与えられたクライアントに向けて経路制御の更新を行なうようにして ルートサーバ間で経路の配布負荷を細分化しようと試みている。しかし、極端な 複雑さを避けるために、調停アルゴリズムは完全には競合の可能性を消しされない。 依然として 1 つのクライアントが 1 つかそれ以上のルートサーバから 更新メッセージを受信する可能性がある。したがって、クライアントに重複した 経路を破棄する能力があれば巨大な経路制御データベースの必要性を削減 することができる。 4.3 ルートサーバのオペレーション ルートサーバは、そのクライアントと BGP-4/IDRP セッションを維持する。 セッションは基本的に BGP-4/IDRP それぞれの仕様に依るが、本文書で概説した プロトコルの修正は例外とされる。 ルートサーバから送信される UPDATE メッセージは、BGP-4/IDRP それぞれと 同じフォーマットと、同じ conterparts としての意味あいを持つが、 UPDATE メッセージは更にメッセージ中で広告される経路を提出したボーダルータの BGP 拡張子を指定する ADVERTISER パス属性をも運んでいる。 更に、ルートサーバクラスタを接続するために階層化モデルを配置するのならば ルートサーバ間で送信される経路制御更新メッセージ全てに 4.3.4 で 記述されるような `RCID パス' 属性を含むことを推奨する。 ルートサーバが OPEN メッセージを交換する際、OPEN メッセージのオプショナル パラメータの中にルートサーバプロトコルのバージョン (現在のバージョンは 1) と 彼らが属するクラスタのクラスタ ID を含ませる。このパラメータのパラメータ タイプ値は 255 である。パラメータデータのデータ長は 3 オクテットである。 パラメータデータのフォーマットを以下に示す: +-----------------------+------------------------------------+ | Version = 1 (1 octet) | Cluster ID (2 octets) | +-----------------------+------------------------------------+ また、同じクラスタに属するルートサーバは、彼らが経路制御情報を提供している クライアントがリストされた LIST メッセージを互いに送信しあう。LIST メッセージ の中で、RS は経路制御の更新情報を提供する各クライアントのルータ識別子を 指定する。RS はリストの変更を通知する必要があるとき、新しく作られたリスト 全てを送信する替わりに、インクリメンタルな更新情報を生成する。こうすることに よって LIST メッセージは相対的に小さくなるので、処理の複雑さを増大させずに 済む。LIST メッセージのフォーマットは 4.3.1 で紹介される。 4.3.1 LIST メッセージのフォーマット LIST メッセージは、以下に示すフィールドの修正された BGP/IDRP ヘッダを 含む。LIST メッセージの修正されたヘッダのタイプコードは 255 である。 +----------+----------+----------+----------+ | クライアント識別アドレス | 通知されるクライアント数だけ +-------------------------------------------+ 繰り返される `クライアント識別アドレス' フィールドの数は符合化されて明示されないが、 以下のように計算することができる。 ( - <ヘッダ長> ) / <アドレス長> ここで、 は修正された BGP/IDRP ヘッダ内の符合化された 値で、<ヘッダ長> はヘッダの長さである。<アドレス長> は IPv4 は 4、IPv6 は 16 である。 4.3.2 external 経路の獲得と広告 ルートサーバはボーダルータになっている RS クライアントから external 経路を 獲得する。RS は、他の RS から external 経路を獲得するかもしれない。 ルートサーバは獲得した経路を修正せずに、クライアントに中継する。 RS クライアントへの広告に際し、一切の経路選択 (この経路は広告するが、これは しない等) は行なわれない。 ルートサーバがクライアントから経路制御データを受信し、蓄積する一方で、 同じクラスタ内の経路制御サーバは、1 つの RS だけがクライアントに対して 経路制御の更新情報を提供できることを保証しようとして、複数の RS の経路広告を 調整する。1 つの RS が失敗すると、クラスタ内の他のルートサーバが責任を 引き継ぎ、失敗した RS が経路制御の更新情報を提供していたクライアントに対して 情報を提供する。RS が切り替わることによって生じる可能性のあるルートフラップは クライアント側でルートサーバとの間の BGP4/IDRP セッションの `Hold Time' を 切り替わる時間よりも大きく設定すれば解消することができる。切り替わる時間は、 クラスタ内のルートサーバ間の BGP-4/IDRP セッションの Hold Time と、 ルートサーバ間で経路広告の責任継承を調整するために要する時間によって 決定される。調整プロトコルは 4.3.3.で述べられる。 ルートサーバの BGP-4/IDRP オペレーションは、以下の部分で `標準的な' オペレーションとは異なる。 - 他の RS から経路を受信した際に、オペレーションの RS クライアントモードが 仮定される。つまり、以前に同じクラスタに属する RS から獲得したのと全く 同じ属性を持つ経路を獲得したら、先に獲得した経路は破棄され、新たに獲得 した経路を受理すべきである。このような経路の交換はどのような形であれ 経路広告アクションのトリガーになるべきではない。 - 獲得した経路は全て、その経路を獲得したクライアントを除く全クライアントに 広告される。(no route echoing)。 - クラスタ間で経路交換を行なう階層化モデルを用いる場合、獲得された経路は 全てその経路を獲得した RSC を除く全ての RSC に広告される。フルメッシュ モデルでは、ボーダルータから獲得した経路だけが他のクラスタ内の ルートサーバに広告される。 - 同じ RS クラスタ内のルートサーバ同士が経路制御情報を交換するように 設定されている場合、ボーダルータから獲得された external 経路だけが ローカルなクラスタに広告される。 - RS に生成される全ての UPDATE メッセージは ADVERTISER パス属性を含む。 この属性は UPDATE 情報を獲得したボーダルータを識別するアドレスを指定 しなければならない。他の経路制御属性は全て無修正のまま RS の peer に 中継されなければならない。 - クライアントから RS に向けて広告されていた経路が到達不可になった場合、 その経路は全クライアントに向けて到達不可であると宣言されなければ ならない。経路を取り消すために、ルートサーバはその経路に関する UPDATE メッセージを各クライアントに送信する (その経路を獲得していた クライアントは除かれる)。UPDATE メッセージでは、NEXT_HOP パス属性が UPDATE メッセージを送信するクライアントのアドレスにセットされる。 また、取り消される経路を広告していたボーダルータのアドレスを識別する ADVERTISER パス属性もその UPDATE メッセージに含まれなければならない。 - ルートサーバクラスタを接続するために階層化モデルを展開するのであれば、 4.3.4 で述べられるようにルートサーバ間で経路制御の更新情報を送信しあう ときに RCID_PATH 属性を含むことを推奨する。RCID_PATH 属性は ボーダルータに送信される UPDATE メッセージには決して含まれてはならない。 4.3.3 クラスタ内部の調整 経路広告の活動を調整するために、同じ RS クラスタに属するルートサーバは 互いに BGP/IDRP コネクションを確立、維持し、フルメッシュ状のコネクティビティ を形成する。一般に、1 つのクラスタ内には 2, 3 台以上のルートサーバは 必要ない。 同じクラスタに属するルートサーバは LIST メッセージを互いに送信しあう。 LIST メッセージは、彼らが経路制御情報を提供するクライアントをリストする。 このクライアントを `informed クライアント' と呼ぶ。 各 RS は、その RS を含むローカルクラスタ内の RS それぞれに対する、独立した `informed クライアント' のリストを維持する。このようなリストは全て 各リスト内のクライアント数で判定される昇順でリンクされる。同数のクライアント を持つリストの順序は、対応する RS の識別アドレスを比較することによって 決定される。`同数クライアント' サブセットに含まれる RS は、より低い アドレスの RS 全ての後に置かれる。 RS は 2 つの RS の調整状態、`Initiation' と 'Active' のうちの 1 つの状態に なり得る。 4.3.3.1 Initiation 状態 この状態は RS がスタートしたときのルートサーバの初期状態である。Initiation 状態に入ると、`InitiationTimer' がスタートされる。Initiation 状態は InitiationTimer が終了した後か、ローカルな RS クラスタ内の他のサーバとの 間に設定されている BGP/IDRP コネクションが全て確立し、LIST メッセージが 受信されるとすぐに ACTIVE 状態に遷移する。 Initiation 状態において、RS は o ローカルクラスタ、リモートクラスタ内の他の RS とコネクションを確立 しようと試みる。 o クライアントルータからの BGP/IDRP コネクションを受理する。 o BGP/IDRP の更新情報を受信し、処理するが、いかなる経路制御の更新情報も 送信しない。 o ローカルクラスタ内の他の RS から受信した `informed クライアント' の リストを蓄積する。同じ RS に関して、新しく受信したリストは現在存在する リストと置換する。他の RS クラスタ内のルートサーバから LIST メッセージを 受信した場合、それは黙って無視されるべきである。 o 自分のクライアントに関する空の `informed クライアント' のリストを 初期化する。 o 同じ RS クラスタ内の RS と BGP/IDRP コネクションが確立するとすぐに、 その RS に空の LIST メッセージを送信する。 4.3.3.2 Active 状態 InitiationTimer が終了した後か、ローカルな RS クラスタ内の他のサーバとの間に 設定されている BGP/IDRP コネクションが全て確立し、LIST メッセージが受信 されるとすぐにこの状態に遷移する。 ACTIVE 状態において、RS は o 引き続き、ローカルクラスタ、リモートクラスタ内の他の RS とコネクションを 確立しようと試みる。 o 新しい BGP/IDRP コネクションを受理する。 o BGP/IDRP コネクションがローカルクラスタ内の RS と確立したらすぐに LIST メッセージを送信する。また、ローカルな `informed クライアント' の リストが変更された場合は常に LIST メッセージを送信する。 o BGP/IDRP の更新情報を受信し、処理する。 o 以下に示すように、`informed クライアント' のリストを受信し、処理する。 a) 他の RS クラスタ内のルートサーバから LIST メッセージを受信した場合、 そのリストは黙って無視されるべきである。 b) 同じ RS クラスタ内のルートサーバから LIST メッセージを受信した場合、 古いリストと新しいリストの違いが判定され、その RS に関する `informed クライアント' のリストは新しいメッセージから得られた リストに置換される。古いリストには載っているが、新しいリストには 載っていないクライアントそれぞれについて、そのサーバがその クライアントと BGP/IDRP コネクションを確立しているか、また そのクライアントが他の `informed クライアント' のリストにも載って いないかがチェックされる。両方の条件が満たされた場合、新しい クライアントのために記述されている処理が実行される (4.3.3.3 参照)。 o 新しい BGP/IDRP クライアント (Initiation 状態で確立されたコネクションも 含む) それぞれについて、そのクライアントが `informed クライアント' に なるべきかどうか、すなわち、経路制御の更新情報を送信すべきか、あるいは 既にローカルクラスタ内の他の RS によって保守がされているかが判定される。 判定処理については次のセクションで記述される。 4.3.3.3 新しいクライアントの処理 RS が新しい BGP/IDRP の peer を獲得した際には、常に全ての `informed クライアント' リストがスキャンされ、その peer が既にローカルクラスタ内の 他の RS から経路制御の更新情報を受信しているかどうかが判定される。 リスト中にその peer の識別アドレスが発見された場合、その peer には 経路制御の更新情報は送信されない。 peer のルータ ID が見つけられなかった場合、ルートサーバはその peer に対する `DelayTimer' タイマを初期化し、判定はタイマが終了するまで延期される。 遅延の値は以下のようにして算出される。 RS はリンクされている全 `informed クライアント' リスト内における、 自分の `informed クライアント' リストの相対的な位置を判定する。 1 から `リストの最大値' までの範囲内の位置を N という数で表すとすると、 遅延の値は (N-1)* にセットされる。 DelayTimer が終了すると、`informed クライアント' リストは再びスキャンされ、 対応する peer が既にローカルクラスタ内の他の RS から経路制御の更新情報を 受信していないかが確認される。新しく受信した LIST メッセージから得られた リスト内にその peer のルータ ID が存在する場合、その peer には経路制御の 更新情報は送信されない。そうでなければ、その RS に属する `informed クライアント' リストにその peer のルータ ID が加えられ、直ちに更新された LIST メッセージの送信がスケジュールされる。その後経路制御の更新情報が そのクライアントに送信される。 遅延に関する理論は、同じ RSC 内のルートサーバ間で、与えられたクライアントに 対して経路制御情報を提供する RS の判定時の競合を最小限にする。最も少数の `informed クライアント' を持つ RS が遅延時間が最も短いので、競合に勝つ 可能性が最大になる。これは、クラスタ内の RS 間で `informed クライアント' 数均等化の助けとなっている。 BGP/IDRP peer が `informed クライアント' リストに加えられた後は、その peer との BGP/IDRP コネクションが消失したときにだけリストから削除される。 RS クライアントがリストに存在する間は、全ての経路制御情報の変化にあわせて 正確に更新される。 4.3.3.5 RS 間コネクションの失敗 ルートサーバが同じクラスタ内のルートサーバとの経路制御セッションを失うと、 失敗したセッションのリモートルートサーバに `informed クライアント' リストに 含まれるクライアントへの経路広告の責任を引き継ぐことを考えなければならない。 各クライアントについて、そのサーバがクライアントと BGP/IDRP コネクションを 確立しているか、そしてクライアントが他のアクティブな RS の `informed クライアント' リストに含まれていないかがチェックされる。どちらも真であれば、 新しいクライアントに関して記述された処理が実行される (4.3.3.3 参照)。 広告の責任が調整された後は、失敗したセッションに関する `informed クライアント' リストは破棄されるべきである。 4.3.4 RCID_PATH 属性 RCID_PATH はオプショナルな他動でない属性で、RS クラスタ識別子 (RCID) の シーケンスから構成される。ここで、RCID は UPDATE メッセージに載せて経路制御 情報が通過してきた RS クラスタを識別する。RCID_PATH 属性のタイプコードは 254 である。属性値フィールドは、それぞれ 2 オクテット長のフィールドに 符号化された 1 つかそれ以上の RS クラスタ識別子を含む。 ルートサーバが他のルートサーバの UPDATE メッセージから学習した経路を伝播 するとき、RCID_PATH 属性に関して以下の事柄が実行される。 - 経路の送信先がルートサーバでない場合、RCID_PATH 属性はクライアントに 送信される UPDATE メッセージからは除外される。 - 経路の送信先が広告するサーバが置かれている RS クラスタ内の別の ルートサーバである場合、RCID_PATH 属性は修正されずに送信される。 - 経路の送信先が別の RS クラスタのルートサーバである場合、広告するルート サーバは送信先のクラスタがその経路に関する RCID_PATH 属性に存在して いないかを検証する。もし存在している場合、その経路は広告されず、 経路のループ検出のイベントが記録されるべきである。そうでない場合、 広告するサーバは自身の RCID を RCID_PATH 属性の RCID シーケンスに 付加する (一番左側に付加される)。 ルートサーバが他のルートサーバへのボーダルータから学習した経路を伝播する 場合、 - 経路の送信先が広告するルータと同じ RS クラスタに属するルートサーバで ある場合、空の RCID_PATH 属性が UPDATE メッセージに含まれる。 (空の RCID_PATH 属性は、長さのフィールドに 0 を含むものである)。 - 経路の送信先が異なる RS クラスタのルートサーバである場合、広告する ルートサーバは自身の RCID を RCID_PATH 属性に含める。その場合、 広告するルートサーバの RCID は RCID_PATH 属性のただ 1 つのエントリに なる。 4.3.5 NOTIFICATION エラーコード BGP-4/IDRP の仕様で定義されているエラーコードに加えて、NOTIFICATION メッセージ内で示される以下のエラーがルートサーバによって送信される。 255 LIST Message Error 以下のエラーサブコードが LIST メッセージエラーに関係する。 1 - 不正なアドレス。このサブコードは、受信した LIST メッセージ内の クライアント識別アドレスがルータインタフェースの有効なネットワーク レイヤアドレスを表現していないことを示す。 以下の UPDATE エラーサブコードが付加的に定義される。 255 - 無効な ADVERTISER 属性。このサブコードは、ADVERTISER 属性の値が ルータインタフェースの有効なネットワークレイヤアドレスを表現して いないことを示す。 4.3.7 タイマ ItitiationTimer の値として 5 分が提案されている。 RS 切替え時のルートフラップを避けるため、DelayGranularity の値は DelayTimer (4.3.3.3 参照) に RS間コネクションの Hold Time を組み合わせた値の考えられる 最大値をとるべきである。ここで、RS間コネクションはルートサーバとクライアント (他のクラスタ内の RS も含まれる) 間の全 BGP/IDRP コネクションの Hold Time インターバルの最小値の 2/3 よりも短いことが望ましい。したがって、3 つの RS が あり、その Hold Time がそれぞれ 30 秒と 90 秒であるようなクラスタでは、 DelayGranularity は 15 秒が推奨値になる。 同様の理由により、同じクラスタに属するルートサーバ間の BGP/IDRP コネクション の Hold Time は、ルートサーバとクライアント (他のクラスタ内の RS も含む) 間の BGP/IDRP コネクション全ての Hold TIme の最小値の 1/3 にセットされる。 したがって、クライアントとの BGP/IDRP セッションの Hold TIme の最小値が 90 秒ならば、そのクラスタ内のルートサーバ間の BGP/IDRP コネクションの Hold Time の推奨値は 30 秒になる。 5. ルートサーバの発見 本文書では、RS クライアント、もしくは他のルートサーバが動的に RS を発見する 仕組みを提案していない。経路制御に参加しているルータ上で手動で設定することに より、必要とされるコネクティビティを達成できるという最小限の仮定を行なって いる。 7. セキュリティに関する考察 セキュリティに関する特性は本文書の中では述べられていない。 8. 謝辞 本文書の中で紹介されている幾つかの設計コンセプトは、Tony Li (cisco Systems) との議論から得られた。 John Krawczyk (Bay Networks) と Susan Harris (Merit) がしてくれた論評と 様々なコメントに感謝する。 また、本文書のより早期のバージョンを論評し、建設的なコメントをくれた Yakov Rekhter (IBM) に感謝する。 Ray Chang (Bay Networks) と、本文書で紹介されたコンセプトの実装に関する 彼の経験はルートサーバの設計を改良する上で助けとなってくれた。特に感謝 したい。 9. 参考文献 [BGP4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995. [IDRP] Rekhter, Y., and P. Traina, "IDRP for IPv6", Work In Progress. 10. 著者のアドレス Dimitry Haskin Bay Networks, Inc. 2 Federal Street Billerica, MA 01821 EMail: dhaskin@baynetworks.com