6.2. Routing Locator Selection (ルーティングロケータ選択)
6.2. Routing Locator Selection (ルーティングロケータ選択)
クライアント側とサーバ側の両方が, 互いのセッションで使用される RLOC 選択を制御する必要がある場合があります。これは, EID-to-RLOC Map-Reply メッセージの Priority と Weight フィールドを操作することによって実現されます。また, 受信したトンネルパケットまたは EID-to-RLOC Map-Request メッセージから RLOC 情報を収集することもできます。
RLOC を選択するいくつかのシナリオと利用可能な制御は次のとおりです:
o サーバ側は 1 つの RLOC のみを返します。クライアント側はその RLOC のみを使用できます。サーバ側が選択を完全に制御します。
o サーバ側は RLOC のリストを返し, そのサブセットが同じ最適な Priority を持ちます。クライアント側は, サーバ側が割り当てた重みに従ってそのサブセットのみを使用できます。サーバ側は, サブセットとそのメンバー間の負荷分散の両方を制御します。クライアント側がサブセットが到達不可能であると判断した場合 (RLOC の Priority が 255 に設定されていない限り), サブセット外の RLOC を使用できます。制御は部分的に共有されます: サーバ側が宛先 RLOC リストと負荷分散を決定し, クライアント側はリスト内の RLOC が到達不可能な場合に代替を選択できます。
o サーバ側は RLOC サブセットの Weight を 0 に設定します。クライアント側は, サブセット上でトラフィックをどのように分散するかを自分で決定できます。サーバ側がリストを定義し, クライアント側が負荷分散を定義します。クライアント側は, サーバが提供するリストが到達不可能な場合, 他の RLOC を使用できます。
o いずれかの側 (より一般的にはサーバ側 ETR) が Map-Request を送信しないことを決定します。例えば, サーバ側 ETR が Map-Request を送信しない場合, クライアント側 ITR から RLOC を収集し, クライアント側 ITR が双方向の RLOC 到達可能性と優先度を担当します。サーバ側 ETR は, 受信したパケットの内部送信元 EID と外部送信元 RLOC をキャッシュすることで収集を実装します。クライアント側 ITR は戻りトラフィックの方法を制御でき, 外部送信元 RLOC をローテーションして, サーバ側 ETR が戻りトラフィックに使用するリストに参加できます。この方法は Priority または Weight を提供せず, サーバ側 ETR は各クライアント側 ITR RLOC が同じ最適な Priority を持ち, Weight がゼロであると仮定しなければなりません。さらに, データパケットは EID-Prefix エンコーディングを伝えることができず, Tunnel Router 上の EID-to-RLOC キャッシュが非常に大きくなる可能性があります。
o 「gleaned」Map-Cache エントリ (受信したカプセル化パケットの送信元 RLOC から学習) は, 検証を待つ間数秒間のみ保存および使用されます。検証は, 受信したカプセル化パケットの送信元 EID (内部 IP 送信元アドレス) に Map-Request を送信することによって完了します。この「検証用 Map-Request」への応答は, 「gleaned」EID の Map-Cache エントリを完全に入力するために使用され, 受信した Map-Reply の TTL フィールドに従って保存および使用されます。検証されたエントリが保存された後, 送信元 EID が検証されたエントリの EID-Prefix と一致する後続のパケットは, データ収集を行いません。
EID-to-RLOC Map-Reply に出現する RLOC は, Locator レコードの R ビットが 1 に設定されている場合, 到達可能であると想定されます。R ビットが 0 の場合, ITR または PITR はその RLOC にカプセル化してはなりません。Map-Reply に含まれる情報またはマッピングデータベースシステムに保存されている情報は, RLOC へのパスの到達可能性を提供しません。到達可能性はマッピングシステムの一部ではなく, 次のセクションで説明する 1 つ以上の Routing Locator 到達可能性アルゴリズムによって決定されます。