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

6. 今後の検討領域

このバージョンの LDP で扱われていない次の話題は, 今後の検討の可能な領域である:

  • MPLS アーキテクチャ [RFC3031] のセクション 2.16 は, ピア LSR 間の初期のラベル配布プロトコルネゴシエーションが, 各 LSR が自身のピアがラベルスタックをポップできるかどうかを判定できるようにすることを要求している. このバージョンの LDP は, LSR が ATM およびフレームリレーを除くすべてのリンクタイプについてラベルのポップをサポートすることを前提としている. 将来のバージョンでは, この判定をセッション開始ネゴシエーションの一部とする手段を規定するかもしれない.

  • CoS (Class of Service) に対する LDP サポートは, このバージョンでは規定されていない. CoS サポートは将来のバージョンで扱われるかもしれない.

  • マルチキャストに対する LDP サポートは, このバージョンでは規定されていない. マルチキャストサポートは将来のバージョンで扱われるかもしれない.

  • マルチパスラベルスイッチングに対する LDP サポートは, このバージョンでは規定されていない. マルチパスサポートは将来のバージョンで扱われるかもしれない.

  • 最大伝送単位 (maximum transmission unit) を通知するための LDP サポートは, このバージョンでは規定されていない. それは実験的文書 [LDP-MTU] で論じられている.

  • 現在の仕様は, 非ブロードキャストマルチアクセス (Non-Broadcast Multi-Access, NBMA) メディア上での基本的なピア発見を扱っていない. 現在の仕様で利用可能な解決策は, そのような構成で拡張ピア発見 (extended peer discovery) を使用することである. 事前設定された隣接アドレスを使用する, Basic Discovery と意味的に類似したメカニズム (1 ホップ制限, hello 隣接をインタフェースにバインドする) を定義するという課題は, 今後の検討に残される.

  • 現在の仕様は隣接のシャットダウンをサポートしていない. それを行う動機とそれを達成するためのメカニズムは, 今後の検討に残される.

  • 現在の仕様は, Hello のスプーフィングを検出するための, Hello メッセージを保護する方法を含んでいない. これが必要となるシナリオ, およびそれを達成するためのメカニズムは, 今後の検討に残される.

  • 現在の仕様は, ステートレスな高速制御プレーン再起動を検出する能力を持たない. これを達成する方法, おそらく Hello メッセージで運ばれる「incarnation/instance」番号を通じた方法は, 今後の検討に残される.

  • 現在の仕様は, BGP の「end of RIB」メッセージに類似した「end of LIB」メッセージをサポートしていない. このメッセージは, LDP LSR (DU モードで動作する) がセッション確立後に使用するものである. そのようなメカニズムの必要性とその実装に関する議論は, 今後の検討に残される.

  • 現在の仕様は, 異なる LSR が同じアドレスを広告する状況を扱っていない. そのような状況は通常, 設定エラーの結果として発生し, この場合の目標は, 同じアドレスを広告している LSR に, 運用者が是正措置を取れるようにするのに十分な情報を提供することである. このメカニズムの規定は別の文書に委ねられる.