2. LDP の動作

2.1. FEC

どのパケットが各 LSP にマッピングされてよいかを正確に規定する必要がある. これは, 各 LSP に対して FEC 指定を提供することによって行われる. FEC は, その LSP にマッピングされてよい IP パケットの集合を識別する.

各 FEC は 1 つ以上の FEC element の集合として指定される. 各 FEC element は, 対応する LSP にマッピングされてよいパケットの集合を識別する. ある LSP が複数の FEC element によって共有される場合, その LSP は, FEC element が同じパスを共有できなくなるノードで (またはその手前で) 終端される.

本仕様は, 単一のタイプの FEC element, すなわち「Address Prefix FEC element」を定義する. この要素は, 長さ 0 から全アドレス長までの任意の長さのアドレスプレフィックスである.

追加の FEC element は, 必要に応じて他の仕様によって定義されてよい.

本セクションの残りでは, Address Prefix FEC element を用いて設定された LSP にパケットをマッピングするために使用される規則を示す.

あるアドレスが特定のアドレスプレフィックスに「一致する (matches)」とは, そのアドレスがそのプレフィックスで始まる場合に限る. また, あるパケットが特定の LSP に一致するとは, その LSP が, そのパケットの宛先アドレスに一致する Address Prefix FEC element を持つ場合に限る. 特定のパケットと特定の LSP に関して, そのパケットに一致する Address Prefix FEC element を「一致プレフィックス (matching prefix)」と呼ぶ.

特定のパケットを特定の LSP にマッピングする手順は次の規則を使用する. 各規則は, パケットを LSP にマッピングできるまで順に適用される.

• パケットがちょうど 1 つの LSP に一致する場合, そのパケットはその LSP にマッピングされる.

• パケットが複数の LSP に一致する場合, それは一致プレフィックスが最も長い LSP にマッピングされる. 一致プレフィックスが最も長い LSP が 1 つも存在しない場合, そのパケットは, 一致プレフィックスが他より長い LSP の集合の中から 1 つにマッピングされる. それらの LSP のうち 1 つを選択する手順は本文書の範囲を超える.

• パケットが特定の egress ルータを通過しなければならないことが既知であり, かつそのルータの /32 アドレスである Address Prefix FEC element を持つ LSP が存在する場合, そのパケットはその LSP にマッピングされる. この知識を得るための手順は本文書の範囲を超える.

パケットが特定の egress ルータを通過しなければならないことを判定する手順は本文書の範囲を超える. (例として, リンクステートルーティングアルゴリズムを実行している場合, この情報をリンクステートデータベースから得られることがある. 別の例として, BGP を実行している場合, この情報をそのパケットの経路の BGP ネクストホップ属性から得られることがある.)

2.2. ラベル空間, 識別子, セッション, およびトランスポート

2.2.1. ラベル空間

「ラベル空間 (label space)」という概念は, ラベルの割り当てと配布を論じるのに有用である. ラベル空間には 2 つのタイプがある:

• インタフェースごとのラベル空間. インタフェース固有の入ラベルは, ラベルにインタフェース資源を使用するインタフェースで使用される. そのようなインタフェースの例は, VCI (Virtual Channel Identifier) をラベルとして使用するラベル制御 ATM インタフェース, または DLCI (Data Link Connection Identifier) をラベルとして使用するフレームリレーインタフェースである.

  インタフェースごとのラベル空間の使用は, LDP ピアがインタフェースを介して「直接接続」されており, かつそのラベルがそのインタフェースを介して送信されるトラフィックにのみ使用される場合にのみ意味を持つことに注意されたい.

• プラットフォームごとのラベル空間. プラットフォーム全体の入ラベルは, 同じラベルを共有できるインタフェースで使用される.

2.2.2. LDP Identifier

LDP Identifier は, LSR のラベル空間を識別するために使用される 6 オクテットの量である. 最初の 4 オクテットはその LSR を識別し, その LSR に割り当てられた 32 ビットの router Id のような, グローバルに一意な値でなければならない. 最後の 2 オクテットは, LSR 内の特定のラベル空間を識別する. プラットフォーム全体のラベル空間に対する LDP Identifier の最後の 2 オクテットは常にともにゼロである. 本文書は LDP Identifier に対して次の印字表現を使用する:

  <LSR Id> : <label space id>

例えば lsr171:0, lsr19:2.

複数のラベル空間を管理および広告する LSR は, そのようなラベル空間ごとに異なる LDP Identifier を使用することに注意されたい.

LSR がピアに対して複数のラベル空間を広告する必要があり, したがって複数の LDP Identifier を使用する必要がある状況は, その LSR がピアへの 2 つのリンクを持ち, 両方が ATM である (かつインタフェースごとのラベルを使用する) 場合に発生する. 別の状況は, LSR がピアへの 2 つのリンクを持ち, 一方が Ethernet (かつプラットフォームごとのラベルを使用する) で, 他方が ATM である場合であろう.

2.2.3. LDP セッション

LDP セッションは, LSR 間のラベル交換を支援するために LSR 間に存在する.

LSR が LDP を使用して別の LSR に複数のラベル空間を広告する場合, それはラベル空間ごとに別々の LDP セッションを使用する.

2.2.4. LDP トランスポート

LDP は, セッションのための信頼性のあるトランスポートとして TCP を使用する.

2 台の LSR 間で複数の LDP セッションが必要な場合, LDP セッションごとに 1 つの TCP セッションが存在する.

2.3. 直接接続されていない LSR 間の LDP セッション

リンクレベルで直接接続されていない LSR 間の LDP セッションは, 状況によっては望ましいことがある.

例えば, LSRa が, 何らかの基準に一致するトラフィックを, 通常ルーティングされるパスに沿って転送するのではなく, LSP を介して直接接続されていない LSRb へ送信する「トラフィックエンジニアリング」アプリケーションを考える.

LSRa と LSRb の間のパスは, 1 つ以上の中間 LSR (LSR1,...LSRn) を含むであろう. LSRa と LSRb の間の LDP セッションは, LSRb に, この目的のためのラベルを LSRa へ広告する手段を提供することによって, LSRb が LSRa から LSP 上に到着するトラフィックをラベルスイッチングすることを可能にする.

この状況で, LSRa は, LSP 上で LSRb へ転送するトラフィックに 2 つのラベルを適用するであろう. すなわち, LSRa から LSRb への LSP パスに沿ってトラフィックを転送するために LSR1 から学習したラベルと, LSRb が LSP 上に到着するトラフィックをラベルスイッチングできるようにするために LSRb から学習したラベルである.

LSRa はまず, LSRb との LDP セッションを介して学習したラベルをパケットのラベルスタックに追加する (パケットがラベル付きで到着した場合はパケットのラベルスタック最上位のラベルをそれで置き換えることによって, ラベルなしで到着した場合はそれをプッシュすることによって). 次に, それは LSR1 から学習した LSP 用のラベルをラベルスタックにプッシュする.

2.4. LDP Discovery

LDP discovery (発見) は, LSR が潜在的な LDP ピアを発見できるようにするメカニズムである. Discovery により, LSR のラベルスイッチングピアを明示的に設定する必要がなくなる.

Discovery メカニズムには 2 つの変種がある:

• Basic Discovery メカニズム: リンクレベルで直接接続された LSR 隣接を発見するために使用される.

• Extended Discovery メカニズム: リンクレベルで直接接続されていない LSR を位置特定するために使用される.

2.4.1. Basic Discovery メカニズム

インタフェース上で LDP Basic Discovery を行うために, LSR はそのインタフェースから LDP Link Hello を定期的に送信する. LDP Link Hello は, "all routers on this subnet" グループマルチキャストアドレスの周知の LDP discovery ポート宛ての UDP パケットとして送信される.

LSR が送信する LDP Link Hello は, その LSR がそのインタフェースに使用する予定のラベル空間に対する LDP Identifier と, 場合によっては追加情報を運ぶ.

インタフェース上での LDP Link Hello の受信は, そのインタフェース上でリンクレベルに到達可能な潜在的な LDP ピアとの「Hello 隣接」, およびそのピアがそのインタフェースに使用する予定のラベル空間を識別する.

2.4.2. Extended Discovery メカニズム

直接接続されていない LSR 間の LDP セッションは, LDP Extended Discovery によってサポートされる.

LDP Extended Discovery を行うために, LSR は LDP Targeted Hello を特定のアドレスへ定期的に送信する. LDP Targeted Hello は, その特定のアドレスの周知の LDP discovery ポート宛ての UDP パケットとして送信される.

LSR が送信する LDP Targeted Hello は, その LSR が使用する予定のラベル空間に対する LDP Identifier と, 場合によっては追加の任意情報を運ぶ.

Extended Discovery は次の点で Basic Discovery と異なる:

• Targeted Hello は, 送信インタフェースの "all routers" グループマルチキャストアドレスではなく, 特定のアドレスへ送信される.

• 対称である Basic Discovery とは異なり, Extended Discovery は非対称である.

  一方の LSR が他方のターゲット LSR との Extended Discovery を開始し, ターゲット LSR が Targeted Hello に応答するか無視するかを決定する. 応答することを選択したターゲット LSR は, 開始側 LSR へ Targeted Hello を定期的に送信することによってそうする.

LDP Targeted Hello の受信は, ネットワークレベルで到達可能な潜在的な LDP ピアとの「Hello 隣接」, およびそのピアが使用する予定のラベル空間を識別する.

2.5. LDP セッションの確立と維持

2.5.1. LDP セッション確立

2 台の LSR 間の LDP Discovery Hello の交換が LDP セッション確立を引き起こす. セッション確立は 2 段階のプロセスである:

• トランスポート接続の確立
• セッション初期化

以下は, LSR1 の観点から, LSR1 と LSR2 の間の LDP セッションの確立を記述する. それは, LSR1 に対してラベル空間 LSR1:a を, LSR2 に対してラベル空間 LSR2:b を指定する Hello の交換を前提としている.

2.5.2. トランスポート接続の確立

Hello の交換は, LSR1 において, リンク (L) とラベル空間 LSR1:a および LSR2:b を結び付ける働きをする Hello 隣接の作成をもたらす.

1. LSR1 が, ラベル空間 LSR1:a と LSR2:b の交換のための LDP セッションをまだ持っていない場合, それは LSR2 との新しい LDP セッションのための TCP 接続を開こうと試みる.

   LSR1 は, LDP TCP 接続の自身の側 (A1) と LSR2 の側 (A2) で使用されるトランスポートアドレスを決定する. アドレス A1 は次のように決定される:

   a. LSR1 が, LSR2 へ送信する Hello で Transport Address 任意オブジェクト (TLV) を使用してアドレスを広告する場合, A1 は LSR1 がその任意オブジェクトを介して広告するアドレスである.

   b. LSR1 が Transport Address 任意オブジェクトを使用しない場合, A1 は LSR2 へ送信する Hello で使用される送信元アドレスである.

   同様に, アドレス A2 は次のように決定される:

   a. LSR2 が Transport Address 任意オブジェクトを使用する場合, A2 は LSR2 がその任意オブジェクトを介して広告するアドレスである.

   b. LSR2 が Transport Address 任意オブジェクトを使用しない場合, A2 は LSR2 から受信した Hello の送信元アドレスである.

2. LSR1 は, アドレス A1 と A2 を符号なし整数として比較することによって, セッション確立においてアクティブな役割を果たすかパッシブな役割を果たすかを決定する. A1 > A2 の場合, LSR1 はアクティブな役割を果たす. それ以外の場合, それはパッシブである.

   A1 と A2 を符号なし整数として比較する手順は次のとおり:

   • A1 と A2 が同じアドレスファミリでない場合, それらは比較不能であり, セッションは確立できない.

   • U1 を, A1 をバイトの並びとして扱うことによって得られる抽象的な符号なし整数とする. ここで, メッセージ内で最も早く現れるバイトがその整数の最上位バイトであり, メッセージ内で最も遅く現れるバイトがその整数の最下位バイトである.

   同様の方法で A2 から得られる抽象的な符号なし整数を U2 とする.

   • U1 と U2 を比較する. U1 > U2 ならば A1 > A2 である. U1 < U2 ならば A1 < A2 である.

3. LSR1 がアクティブである場合, それはアドレス A2 の周知の LDP ポートへ接続することによって LDP TCP 接続を確立しようと試みる. LSR1 がパッシブである場合, それは LSR2 が自身の周知の LDP ポートへ LDP TCP 接続を確立するのを待つ.

LSR が Hello を送信するとき, それはセッション接続の自身の側のトランスポートアドレスを選択し, そのアドレスを広告するために Hello を使用する. これは, 任意の Transport Address TLV にそれを含めることによって明示的に, またはその TLV を省略してそれを Hello の送信元アドレスとして使用することによって暗黙的に行われる.

LSR は, 同じラベル空間を広告するすべての Hello で同じトランスポートアドレスを広告しなければならない (MUST). この要件は, 同じラベル空間を使用する複数の Hello 隣接によって結ばれた 2 台の LSR が, 各隣接について同じ接続確立の役割を果たすことを保証する.

2.5.3. セッション初期化

LSR1 と LSR2 がトランスポート接続を確立した後, それらは LDP Initialization メッセージを交換することによってセッションパラメータをネゴシエートする. ネゴシエートされるパラメータには, LDP プロトコルバージョン, ラベル配布方式, タイマ値, ラベル制御 ATM のための VPI/VCI (Virtual Path Identifier / Virtual Channel Identifier) 範囲, ラベル制御フレームリレーのための DLCI (Data Link Connection Identifier) 範囲などが含まれる.

ネゴシエーションの成功は, ラベル空間 LSR1:a と LSR2:b の広告のための LSR1 と LSR2 の間の LDP セッションの確立を完了する.

以下は, LSR1 の観点からのセッション初期化を記述する.

接続が確立された後, LSR1 がアクティブな役割を果たしている場合, それは Initialization メッセージを LSR2 へ送信することによってセッションパラメータのネゴシエーションを開始する. LSR1 がパッシブである場合, それは LSR2 がパラメータネゴシエーションを開始するのを待つ.

一般に, LSR1 と LSR2 の間に複数のリンクがあり, 各々が広告すべき複数のラベル空間を持つ場合, パッシブ LSR は, その接続上で LDP Initialization メッセージを受信するまで, 新たに確立された TCP 接続上でどのラベル空間を広告すべきかを知ることができない. Initialization メッセージは, 送信側 (アクティブ LSR) のラベル空間に対する LDP Identifier と, 受信側 (パッシブ LSR) のラベル空間に対する LDP Identifier の両方を運ぶ.

ピアからの Initialization メッセージを待つことにより, パッシブ LSR は, ピアが広告する予定のラベル空間 (Initialization メッセージの PDU ヘッダ内の LDP Identifier から判定される) を, Hello が交換されたときに以前に作成された Hello 隣接と照合できる.

1. LSR1 がパッシブな役割を果たす場合:

   a. LSR1 が Initialization メッセージを受信した場合, それはそのメッセージの PDU が運ぶ LDP Identifier を Hello 隣接と照合しようと試みる.

   b. 一致する Hello 隣接が存在する場合, その隣接がそのセッションのローカルラベル空間を指定する.

   次に LSR1 は, そのメッセージで提案されたセッションパラメータが受け入れ可能かどうかを確認する. 受け入れ可能である場合, LSR1 は, 自身が使用したいパラメータを提案する自身の Initialization メッセージと, LSR2 のパラメータの受け入れを通知する KeepAlive メッセージで応答する. パラメータが受け入れ可能でない場合, LSR1 は Session Rejected/Parameters Error Notification メッセージを送信し, TCP 接続を閉じることによって応答する.

   c. LSR1 が一致する Hello 隣接を見つけられない場合, それは Session Rejected/No Hello Error Notification メッセージを送信し, TCP 接続を閉じる.

   d. LSR1 が自身の Initialization メッセージへの応答として KeepAlive を受信した場合, LSR1 の観点からセッションは動作可能である.

   e. LSR1 が Error Notification メッセージを受信した場合, LSR2 はその提案されたセッションを拒否しており, LSR1 は TCP 接続を閉じる.

2. LSR1 がアクティブな役割を果たす場合:

   a. LSR1 が Error Notification メッセージを受信した場合, LSR2 はその提案されたセッションを拒否しており, LSR1 は TCP 接続を閉じる.

   b. LSR1 が Initialization メッセージを受信した場合, それはセッションパラメータが受け入れ可能かどうかを確認する. そうである場合, それは KeepAlive メッセージで応答する. セッションパラメータが受け入れられない場合, LSR1 は Session Rejected/Parameters Error Notification メッセージを送信し, 接続を閉じる.

   c. LSR1 が KeepAlive メッセージを受信した場合, LSR2 はその提案されたセッションパラメータを受け入れたことになる.

   d. LSR1 が, 受け入れ可能な Initialization メッセージと KeepAlive メッセージの両方を受信したとき, LSR1 の観点からセッションは動作可能である.

   LDP セッションが確立されるまで, 上記の手順に列挙されたもの以外のメッセージは交換されてはならず, LDP メッセージ内の U-bit を処理するための規則は無効化される. 上記の手順に列挙されたもの以外のメッセージを受信した場合, Shutdown msg が送信されなければならず (MUST), トランスポート接続が閉じられなければならない (MUST).

セッションパラメータについて一致しない, 両立しない設定の LSR の組が, 互いの Initialization メッセージを Error Notification メッセージで NAK し合いながら, 終わりのないメッセージの連鎖に陥ることがありうる.

LSR は, Initialization メッセージが NAK されている状況では, セッション設定の再試行を指数バックオフで抑制しなければならない (MUST). また, そのような状況を検出した LSR が, 運用者に通知するための措置を取ることが推奨される.

NAK された Initialization メッセージに続くセッション確立の設定試行は, 15 秒以上遅延されなければならず (MUST), その後の遅延は少なくとも 2 分の最大遅延まで増大しなければならない (MUST). 遅延されなければならない具体的なセッション確立動作は, アクティブな役割を果たす LSR がセッションのトランスポート接続を開く試みである.

抑制された Initialization の NAK の連続は, 運用者の介入が LSR の一方を再設定するまで終息する可能性は低い. そのような設定操作の後は, (それらの Initialization メッセージが NAK されるまでは) それ以降のセッション確立試行を抑制する必要はもはやない.

セッション確立は非対称な性質を持つため, パッシブ LSR の再設定は, 何らかの追加の措置がなければ, アクティブ LSR には気付かれない. セクション「Hello Message」は, LSR が, 自身が再設定されたことを潜在的な LDP ピアに通知するために使用できる任意のメカニズムを記述する.

2.5.4. 初期化ステートマシン

LDP のセッションネゴシエーションの動作をステートマシンの観点で記述すると都合がよい. 我々は LDP ステートマシンを 5 つの取り得る状態を持つものとして定義し, その動作を状態遷移表および状態遷移図として示す. Shutdown メッセージは, 致命的なエラーを示す Status TLV を持つ Notification メッセージとして実装されることに注意されたい.

        Session Initialization State Transition Table

STATE EVENT NEW STATE

NON EXISTENT Session TCP connection established INITIALIZED established

INITIALIZED Transmit Initialization msg OPENSENT (Active Role)

          Receive acceptable                  OPENREC
                Initialization msg
                (Passive Role)
            Action: Transmit Initialization
                    msg and KeepAlive msg

          Receive Any other LDP msg           NON EXISTENT
            Action: Transmit Error Notification msg
                    (NAK) and close transport connection

OPENREC Receive KeepAlive msg OPERATIONAL

          Receive Any other LDP msg           NON EXISTENT
            Action: Transmit Error Notification msg
                    (NAK) and close transport connection

OPENSENT Receive acceptable OPENREC Initialization msg Action: Transmit KeepAlive msg

          Receive Any other LDP msg           NON EXISTENT
            Action: Transmit Error Notification msg
                    (NAK) and close transport connection

OPERATIONAL Receive Shutdown msg NON EXISTENT Action: Transmit Shutdown msg and close transport connection

          Receive other LDP msgs              OPERATIONAL
          Timeout                             NON EXISTENT
            Action: Transmit Shutdown msg and
                    close transport connection

       Session Initialization State Transition Diagram

                           +------------+
                           |            |
             +------------>|NON EXISTENT|<--------------------+
             |             |            |                     |
             |             +------------+                     |
             | Session        |    ^                          |
             |   connection   |    |                          |
             |   established  |    | Rx any LDP msg except    |
             |                V    |   Init msg or Timeout    |
             |            +-----------+                       |
Rx Any other |            |           |                       |
   msg or    |            |INITIALIZED|                       |
   Timeout / |        +---|           |-+                     |
Tx NAK msg   |        |   +-----------+ |                     |
             |        | (Passive Role)  | (Active Role)       |
             |        | Rx Acceptable   | Tx Init msg         |
             |        |    Init msg /   |                     |
             |        | Tx Init msg     |                     |
             |        |    Tx KeepAlive |                     |
             |        V    msg          V                     |
             |   +-------+        +--------+                  |
             |   |       |        |        |                  |
             +---|OPENREC|        |OPENSENT|----------------->|
             +---|       |        |        | Rx Any other msg |
             |   +-------+        +--------+    or Timeout    |
Rx KeepAlive |        ^                |     Tx NAK msg       |
   msg       |        |                |                      |
             |        |                | Rx Acceptable        |
             |        |                |    Init msg /        |
             |        +----------------+ Tx KeepAlive msg     |
             |                                                |
             |      +-----------+                             |
             +----->|           |                             |
                    |OPERATIONAL|                             |
                    |           |---------------------------->+
                    +-----------+     Rx Shutdown msg
             All other  |   ^            or Timeout /
               LDP msgs |   |         Tx Shutdown msg
                        |   |
                        +---+

2.5.5. Hello 隣接の維持

ピアとの LDP セッションは 1 つ以上の Hello 隣接を持つ.

LDP セッションが複数の Hello 隣接を持つのは, 一対の LSR が, 同じラベル空間を共有する複数のリンクによって接続されている場合である. 例えば, 一対のルータ間の複数の PPP リンクである. この状況では, LSR がそのような各リンク上で送信する Hello は同じ LDP Identifier を運ぶ.

LDP は, LDP セッションおよびその Hello 隣接の必要性を監視するメカニズムを含む.

LDP は, LDP Discovery Hello の定期的な受信を, Hello によって識別されるラベル空間を使用するというピアの意思を示すものとして使用する. LSR は各 Hello 隣接に対して保持タイマを維持し, その隣接に一致する Hello を受信するたびにそれを再起動する. ピアから一致する Hello を受信することなくタイマが満了した場合, LDP は, ピアがそのリンク (Targeted Hello の場合はターゲット) についてそのラベル空間を使用したラベルスイッチングをもはや望んでいないか, またはピアが故障したと結論する. そして LSR はその Hello 隣接を削除する. LDP セッションの最後の Hello 隣接が削除されたとき, LSR は Notification メッセージを送信しトランスポート接続を閉じることによってその LDP セッションを終了する.

2.5.6. LDP セッションの維持

LDP は, LDP セッションの健全性を監視するメカニズムを含む.

LDP は, セッションのトランスポート接続上での LDP PDU の定期的な受信を, セッションの健全性を監視するために使用する. LSR はピアセッションごとに KeepAlive Timer を維持し, セッションのピアから LDP PDU を受信するたびにそれをリセットする. ピアから LDP PDU を受信することなく KeepAlive Timer が満了した場合, LSR は, トランスポート接続が不良であるかピアが故障したと結論し, トランスポート接続を閉じることによってその LDP セッションを終了する.

LDP セッションが確立された後, LSR は, ピアがセッションの KeepAlive Timer を再起動することを保証するために, 少なくとも KeepAlive 時間期間ごとにピアが自身から LDP PDU を受信するよう取り計らわなければならない. LSR はこの要件を満たすために任意のプロトコルメッセージを送信してよい. LSR がピアに通信すべき他の情報を持たない状況では, それは KeepAlive メッセージを送信する.

LSR は, いつでもピアとの LDP セッションを終了することを選択してよい. そうすることを選択した場合, それは Shutdown メッセージでピアに通知する.

2.6. ラベル配布と管理

MPLS アーキテクチャ [RFC3031] は, LSR が, 別の LSR からの明示的な要求に応答して FEC ラベルバインディングを配布することを許容する. これは Downstream On Demand ラベル配布として知られている. またそれは, LSR が, 明示的に要求していない LSR にラベルバインディングを配布することをも許容する. [RFC3031] はこのラベル配布方式を Unsolicited Downstream と呼んでいる. 本文書は Downstream Unsolicited という用語を使用する.

これらのラベル配布技術はどちらも, 同じネットワーク内で同時に使用してよい. しかし, 任意の所与の LDP セッションについて, 各 LSR は, 一方のピアが Downstream Unsolicited ラベル配布を使用しているときに相手もそうであると想定してしまう状況を避けるために, ピアが使用するラベル配布方式を認識していなければならない. セクション「Downstream on Demand Label Advertisement」を参照されたい.

2.6.1. ラベル配布制御モード

LSP の初期設定の動作は, LSR が独立 (independent) 制御または順序 (Ordered) 制御のいずれで動作しているかによって決まる. LSR は, 設定可能なオプションとして両方のタイプの制御をサポートしてよい.

2.6.1.1. 独立ラベル配布制御

独立 LSP 制御を使用する場合, 各 LSR は, 望むいつでも隣接にラベルマッピングを広告してよい. 例えば, 独立 Downstream on Demand モードで動作する場合, LSR は, ネクストホップからのラベルマッピングを待つことなく, ラベルマッピングの要求に直ちに応答してよい. 独立 Downstream Unsolicited モードで動作する場合, LSR は, ある FEC をラベルスイッチングする準備ができたときはいつでも, その FEC に対するラベルマッピングを隣接に広告してよい.

独立モードの使用の結果の一つは, 下流ラベルを受信する前に上流ラベルを広告できることである.

2.6.1.2. 順序ラベル配布制御

LSP 順序制御を使用する場合, LSR は, その FEC のネクストホップに対するラベルマッピングを持っている FEC, またはその LSR が egress である FEC についてのみ, ラベルマッピングの送信を開始してよい. LSR が egress ではなく, かつマッピングが存在しない各 FEC について, LSR は, その FEC をマッピングし対応するラベルを上流 LSR に渡す前に, 下流 LSR からのラベルを受信するまで待たなければならない (MUST). LSR は, いくつかの FEC については egress であり, 他の FEC については非 egress でありうる.

LSR は, 特定の FEC に関して, 次のいずれかの条件で egress LSR として動作してよい:

1. その FEC が LSR 自身 (直接接続されたインタフェースを含む) を参照している.

2. その FEC のネクストホップルータがラベルスイッチングネットワークの外側にある.

3. FEC element が, OSPF サマリネットワークにおける別エリア, または OSPF AS external および BGP 経路 [RFC2328] [RFC4271] における別自律システムのような, ルーティングドメイン境界を越えることによって到達可能である.

LSR が所与の FEC について egress であるかどうかは, ネットワークの状態および LSR の設定に応じて, 時間とともに変化しうることに注意されたい.

2.6.2. ラベル保持モード

MPLS アーキテクチャ [RFC3031] は, LSR が, その FEC のネクストホップではない隣接から学習した FEC のラベルバインディングを維持するかどうかを指定する, ラベル保持モード (label retention mode) という概念を導入している.

2.6.2.1. コンサバティブラベル保持モード

Downstream Unsolicited 広告モードでは, すべての経路に対するラベルマッピング広告をすべてのピア LSR から受信しうる. コンサバティブ保持 (Conservative Label retention) を使用する場合, 広告されたラベルマッピングは, それらがパケットの転送に使用される場合 (すなわち, ルーティングに従って有効なネクストホップから受信された場合) にのみ保持される. Downstream on Demand モードで動作する場合, LSR は, ルーティングに従ったネクストホップ LSR からのみラベルマッピングを要求する. Downstream on Demand モードは主としてラベルの節約が望まれる場合 (例えば, クロスコネクト空間が限られた ATM スイッチ) に使用されるため, それは通常コンサバティブラベル保持モードとともに使用される.

コンサバティブモードの主な利点は, データの転送に必要なラベルのみが割り当てられ維持されることである. これは, ATM スイッチのようにラベル空間が本質的に限られている LSR では特に重要である. コンサバティブモードの欠点は, ルーティングが所与の宛先のネクストホップを変更した場合, ラベル付きパケットを転送できるようになる前に, 新しいネクストホップから新しいラベルを取得しなければならないことである.

2.6.2.2. リベラルラベル保持モード

Downstream Unsolicited 広告モードでは, すべての経路に対するラベルマッピング広告をすべての LDP ピアから受信しうる. リベラル保持 (Liberal Label retention) を使用する場合, ピア LSR から受信したすべてのラベルマッピングは, その LSR が広告されたマッピングのネクストホップであるかどうかにかかわらず保持される. リベラル保持を伴う Downstream on Demand モードで動作する場合, LSR は, すべての既知のプレフィックスに対するラベルマッピングをすべてのピア LSR に要求することを選択するかもしれない. しかし, Downstream on Demand モードは通常, コンサバティブなアプローチが推奨される ATM スイッチベースの LSR のような装置によって使用されることに注意されたい.

リベラルラベル保持モードの主な利点は, ラベルが既に存在するため, ルーティング変更への反応が迅速になりうることである. リベラルモードの主な欠点は, 不要なラベルマッピングが配布され維持されることである.

2.6.3. ラベル広告モード

LSR 上の各インタフェースは, Downstream Unsolicited または Downstream on Demand のいずれかの広告モードで動作するよう設定される. LSR は初期化中に広告モードを交換する. Downstream Unsolicited と Downstream on Demand モードの主な違いは, マッピング要求およびマッピング広告を開始する責任をどちらの LSR が負うかにある.

2.7. LDP Identifier とネクストホップアドレス

LSR は学習したラベルをラベル情報ベース (Label Information Base, LIB) に維持する. Downstream Unsolicited モードで動作する場合, あるアドレスプレフィックスに対する LIB エントリは, (LDP Identifier, label) の組の集合をそのプレフィックスに関連付ける. そのような組は, そのプレフィックスに対するラベルを広告するピアごとに 1 つである.

プレフィックスのネクストホップが変化したとき, LSR は, 転送に使用するために新しいネクストホップが広告したラベルを LIB から取得しなければならない. そのラベルを取得するには, LSR はそのプレフィックスのネクストホップアドレスを LDP Identifier にマッピングできなければならない.

同様に, LSR が LDP ピアからあるプレフィックスのラベルを学習したとき, それは, そのプレフィックスに一致するパケットを転送する際に新たに学習したラベルを使用し始める必要があるかどうかを判定するために, そのピアが現在そのプレフィックスのネクストホップであるかどうかを判定できなければならない. その決定を行うには, LSR は LDP Identifier をピアのアドレスにマッピングし, そのうちのいずれかがそのプレフィックスのネクストホップであるかどうかを確認できなければならない.

LSR がピア LDP Identifier とピアのアドレスの間でマッピングできるようにするために, LSR は LDP Address および Withdraw Address メッセージを使用して自身のアドレスを広告する.

LSR は, 自身のアドレスをピアに広告するために Address メッセージを送信する. LSR は, 以前に広告したアドレスをピアからウィズドローするために Withdraw Address メッセージを送信する.

2.8. ループ検出

Loop Detection は, ループしている LSP を見つけるための, およびマージ能力のない LSR が存在する状況で Label Request メッセージがループするのを防ぐためのメカニズムを提供する, 設定可能なオプションである.

このメカニズムは, Label Request および Label Mapping メッセージによって運ばれる Path Vector および Hop Count TLV を利用する. それはこれらの TLV の次の基本的性質に基づく:

• Path Vector TLV は, それを含むメッセージが通過した LSR のリストを含む. LSR は, Path Vector リストにおいて, その一意な LSR Identifier (Id), すなわちその LDP Identifier の最初の 4 オクテットによって識別される. LSR が Path Vector TLV を含むメッセージを伝播するとき, それは自身の LSR Id を Path Vector リストに追加する. 自身の LSR Id を含む Path Vector を持つメッセージを受信する LSRは, そのメッセージがループを通過したことを検出する. LDP は許容される最大 Path Vector 長という概念をサポートする. Path Vector が最大長に到達したことを検出する LSRは, それを含むメッセージがループを通過したかのように振る舞う.

• Hop Count TLV は, それを含むメッセージが通過した LSR のカウントを含む. LSR が Hop Count TLV を含むメッセージを伝播するとき, それはそのカウントをインクリメントする. Hop Count が設定された最大値に到達したことを検出する LSR は, それを含むメッセージがループを通過したかのように振る舞う. 慣例により, カウント 0 はホップカウントが未知であることを意味すると解釈される. 未知のホップカウント値をインクリメントした結果は, 未知のホップカウント値 (0) である.

以下の段落は LDP Loop Detection の手順を記述する. これらの段落において, かつこれらの段落においてのみ, "MUST" は「Loop Detection 用に設定されている場合は MUST」を意味するよう再定義される. これらの段落は, Path Vector および Hop Count TLV を運ばなければならないメッセージを規定する. Hop Count TLV およびその手順は, Loop Detection が設定されていない状況では Path Vector TLV なしで使用されることに注意されたい ([RFC3035] および [RFC3034] を参照).

2.8.1. Label Request メッセージ

Path Vector TLV および Hop Count TLV の使用は, マージ能力のない LSR を含む環境で Label Request メッセージがループするのを防ぐ.

Loop Detection が有効であるとき, LSR R による Label Request メッセージでの Hop Count TLV の使用を規定する規則は次のとおり:

• Label Request メッセージは Hop Count TLV を含まなければならない (MUST).

• R が FEC ingress であるために Label Request を送信している場合, それはホップカウント値 1 を持つ Hop Count TLV を含まなければならない (MUST).

• R が, 上流 LSR から Label Request を受信した結果として Label Request を送信している場合, かつ受信した Label Request が Hop Count TLV を含む場合, R は受信したホップカウント値を 1 インクリメントしなければならず (MUST), その結果の値を Hop Count TLV に入れて Label Request メッセージとともに自身のネクストホップへ渡さなければならない (MUST).

Loop Detection が有効であるとき, LSR R による Label Request メッセージでの Path Vector TLV の使用を規定する規則は次のとおり:

• R が FEC ingress であるために Label Request を送信している場合, かつ R がマージ能力を持たない場合, それは自身の LSR Id を含む長さ 1 の Path Vector TLV を含まなければならない (MUST).

• R が, 上流 LSR から Label Request を受信した結果として Label Request を送信している場合, かつ受信した Label Request が Path Vector TLV を含むか, または R がマージ能力を持たない場合:

  R は自身の LSR Id を Path Vector に追加しなければならず (MUST), その結果の Path Vector を Label Request メッセージとともに自身のネクストホップへ渡さなければならない (MUST). その Label Request が Path Vector TLV を含まない場合, R は自身の LSR Id を含む長さ 1 の Path Vector TLV を含まなければならない (MUST).

R が特定の FEC に対する Label Request メッセージを受信し, かつ R が以前にその FEC に対する Label Request メッセージを自身のネクストホップへ送信していてまだ応答を受信しておらず, かつ R が新たに受信した Label Request を既存の未完了の Label Request とマージする意思がある場合, R はその Label Request をネクストホップへ伝播させないことに注意されたい.

R が自身のネクストホップから, 設定された最大値を超える Hop Count TLV を持つ, または自身の LSR Id を含むか許容最大長を超える Path Vector TLV を持つ Label Request メッセージを受信した場合, R はその Label Request メッセージがループを経由してきたことを検出する.

R がループを検出したとき, それは Loop Detected Notification メッセージをその Label Request メッセージの送信元へ送信しなければならず (MUST), その Label Request メッセージを破棄しなければならない.

2.8.2. Label Mapping メッセージ

Label Mapping メッセージでの Path Vector TLV および Hop Count TLV の使用は, ループしている LSP を見つけて終端させるメカニズムを提供する. LSR がネクストホップから Label Mapping メッセージを受信したとき, そのメッセージは, ingress LSR に到達するかループが見つかるまで, 以下に規定するとおりに上流へ伝播される.

Loop Detection が有効であるとき, LSR R が送信する Label Mapping メッセージでの Hop Count TLV の使用を規定する規則は次のとおり:

• R は Hop Count TLV を含まなければならない (MUST).

• R が egress である場合, ホップカウント値は 1 でなければならない (MUST).

• ネクストホップから受信した Label Mapping メッセージを上流ピアへ伝播するために Label Mapping メッセージを送信している場合, ホップカウント値は次のように決定されなければならない (MUST):

  o R が, その LSR 群が 'TTL-decrement' を行わない LSR ドメイン (例えば ATM LSR ドメインまたはフレームリレー LSR ドメイン) のエッジ集合のメンバーであり, かつ上流ピアがそのドメイン内にある場合, R はそのメッセージを伝播する前にホップカウントを 1 にリセットしなければならない (MUST).

  o それ以外の場合, R は, そのメッセージを伝播する前に, ネクストホップから受信したホップカウントをインクリメントしなければならない (MUST).

• Label Mapping メッセージを, Label Mapping メッセージを伝播するために送信しているのではない場合, ホップカウント値は, 以前の Label Mapping メッセージから学習したホップカウントについての R の現在の知識をインクリメントした結果でなければならない (MUST). R がネクストホップから Label Mapping メッセージを受信していない場合, このホップカウント値は未知であることに注意されたい.

任意の Label Mapping メッセージは Path Vector TLV を含んでよい (MAY). Loop Detection が有効であるとき, LSR R が送信する Label Mapping メッセージでの Path Vector TLV の必須の使用を規定する規則は次のとおり:

• R が egress である場合, その Label Mapping メッセージは Path Vector TLV を含む必要はない.

• R が, ネクストホップから受信した Label Mapping メッセージを上流ピアへ伝播するために Label Mapping メッセージを送信している場合:

  o R がマージ能力を持ち, かつ R が以前にその上流ピアへ Label Mapping メッセージを送信していない場合, それは Path Vector TLV を含まなければならない (MUST).

  o 受信したメッセージが未知のホップカウントを含む場合, R は Path Vector TLV を含まなければならない (MUST).

  o R が以前にその上流ピアへ Label Mapping メッセージを送信している場合, 受信したメッセージが LSP ホップカウントの増加, ホップカウントの未知から既知への変化, または既知から未知への変化を報告するならば, それは Path Vector TLV を含まなければならない (MUST).

上記の規則が, R が Label Mapping メッセージに Path Vector TLV を含めることを要求する場合, R は次のようにそれを計算する:

o 受信した Label Mapping メッセージが Path Vector を含んでいた場合, 上流へ送信する Path Vector は, 受信した Path Vector に R の LSR Id を追加した結果でなければならない (MUST).

o 受信したメッセージが Path Vector を持たなかった場合, 上流へ送信する Path Vector は, R の LSR Id を含む長さ 1 の Path Vector でなければならない (MUST).

• Label Mapping メッセージを, 受信したメッセージを上流へ伝播するために送信しているのではない場合, その Label Mapping メッセージは, R の LSR Id を含む長さ 1 の Path Vector を含まなければならない (MUST).

  R が自身のネクストホップから, 設定された最大値を超える Hop Count TLV を持つ, または自身の LSR Id を含むか許容最大長を超える Path Vector TLV を持つ Label Mapping メッセージを受信した場合, R は対応する LSP がループを含むことを検出する.

  R がループを検出したとき, それは転送のためにそのラベルを使用することを停止しなければならず (MUST), その Label Mapping メッセージを破棄しなければならず (MUST), その Label Mapping メッセージの送信元へ Loop Detected ステータスを通知しなければならない (MUST).

2.8.3. 考察

MPLS ドメインで Loop Detection が望まれる場合, その MPLS ドメイン内のすべての LSR でそれを有効にすべきである. そうしないと Loop Detection は正しく動作せず, 未検出のループまたは誤検出されたループを生じうる.

Loop Detection 用に設定された LSR は, LSP 状態の一部として Path Vector を格納することは期待されていない (NOT expected).

マージ能力のない LSR のみが存在するネットワークでは, Path Vector は ingress から egress へ下流に渡され, 上流には渡されないことに注意されたい. マージがサポートされている場合でも, egress に到達することが既知である LSP に沿っては, Path Vector を上流に渡す必要はない. LSR がネクストホップの変化を経験したとき, ネクストホップの変化がループをもたらさないことをホップカウントから判断できない場合にのみ, それは Path Vector を上流に渡す必要がある.

順序ラベル配布の場合, Label Mapping メッセージは egress から ingress へ向かって伝播され, その過程で自然に Path Vector が作成される. 独立ラベル配布の場合, LSR は, その FEC に対する Label Mapping メッセージを下流ピアから受信する前に, その FEC に対する Label Mapping メッセージを発信することがある. この場合, 下流ピアから受信したその FEC に対する後続の Label Mapping メッセージは LSP 属性の更新として扱われ, その Label Mapping メッセージは上流へ伝播されなければならない. したがって, Label Mapping 更新メッセージの数を最小限に抑えるために, Loop Detection を順序ラベル配布と組み合わせて設定することが推奨される.

2.9. LDP メッセージの真正性と完全性

本セクションは, LDP セッション接続ストリームへのスプーフィングされた TCP セグメントの混入から保護するためのメカニズムを規定する. このメカニズムの使用は, 設定可能なオプションとしてサポートされなければならない (MUST).

このメカニズムは, BGP [RFC4271] が使用するために [RFC2385] で規定された TCP MD5 Signature Option の使用に基づく. MD5 ハッシュ関数の仕様については [RFC1321] を参照されたい. 標準成熟度の観点から, 本文書は [RFC2385] に対して, [RFC4271] が [RFC2385] に対して関係するのと同じように関係する. これは [RFC4278] で説明されている.

2.9.1. TCP MD5 Signature Option

[RFC2385] からの次の引用は, TCP MD5 Signature Option を使用することによって達成されるセキュリティ特性を概説し, その動作を要約している:

"IESG Note

  This document describes current existing practice for securing
  BGP against certain simple attacks.  It is understood to have
  security weaknesses against concerted attacks."

"Abstract

  This memo describes a TCP extension to enhance security for
  BGP.  It defines a new TCP option for carrying an MD5 [RFC1321]
  digest in a TCP segment.  This digest acts like a signature for
  that segment, incorporating information known only to the
  connection end points.  Since BGP uses TCP as its transport,
  using this option in the way described in this paper
  significantly reduces the danger from certain security attacks
  on BGP."

"Introduction

  The primary motivation for this option is to allow BGP to
  protect itself against the introduction of spoofed TCP segments
  into the connection stream.  Of particular concern are TCP
  resets.

  To spoof a connection using the scheme described in this paper,
  an attacker would not only have to guess TCP sequence numbers,
  but would also have had to obtain the password included in the
  MD5 digest.  This password never appears in the connection
  stream, and the actual form of the password is up to the
  application.  It could even change during the lifetime of a
  particular connection so long as this change was synchronized
  on both ends (although retransmission can become problematical
  in some TCP implementations with changing passwords).

  Finally, there is no negotiation for the use of this option in
  a connection, rather it is purely a matter of site policy
  whether or not its connections use the option."

"MD5 as a Hashing Algorithm

  Since this memo was first issued (under a different title), the
  MD5 algorithm has been found to be vulnerable to collision
  search attacks [Dobb], and is considered by some to be
  insufficiently strong for this type of application.

  This memo still specifies the MD5 algorithm, however, since the
  option has already been deployed operationally, and there was
  no "algorithm type" field defined to allow an upgrade using the
  same option number.  The original document did not specify a
  type field since this would require at least one more byte, and
  it was felt at the time that taking 19 bytes for the complete
  option (which would probably be padded to 20 bytes in TCP
  implementations) would be too much of a waste of the already
  limited option space.

  This does not prevent the deployment of another similar option
  which uses another hashing algorithm (like SHA-1).  Also, if
  most implementations pad the 18 byte option as defined to 20
  bytes anyway, it would be just as well to define a new option
  which contains an algorithm type field.

  This would need to be addressed in another document, however."

End of quotes from [RFC2385].

2.9.2. TCP MD5 Signature Option の LDP での使用

LDP は TCP MD5 Signature Option を次のように使用する:

• LDP TCP 接続のための MD5 Signature Option の使用は, 設定可能な LSR オプションである.

• MD5 Signature Option を使用する LSR は, 潜在的な LDP ピアごとにパスワード (共有秘密) を設定される.

• LSR は, [RFC2385] で規定されたとおりに MD5 アルゴリズムを適用して, ピアへ送信する TCP セグメントの MD5 ダイジェストを計算する. この計算は, TCP セグメントと同様にピアのパスワードを利用する.

• LSR が MD5 ダイジェスト付きの TCP セグメントを受信したとき, それは MD5 ダイジェストを計算し (自身のパスワードの記録を使用する), 計算したダイジェストと受信したダイジェストを比較することによってそのセグメントを検証する. 比較が失敗した場合, そのセグメントは, 送信元へ何の応答もせずに破棄される.

• LSR は, パスワードが設定されていない LSR からの LDP Hello を無視する. これにより, LSR が, パスワードが設定されている LSR とのみ LDP TCP 接続を確立することが保証される.

2.10. 明示的にルーティングされた LSP のためのラベル配布

トラフィックエンジニアリング [RFC2702] は重要な MPLS アプリケーションになると予想される. トラフィックエンジニアリングのための MPLS サポートは, 宛先ベースのルーティングプロトコルによって決定される通常ルーティングされた (ホップバイホップの) パスに従う必要のない, 明示的にルーティングされた LSP を使用する. CR-LDP [CRLDP] は, LDP を使用して明示的にルーティングされた LSP を設定するための LDP への拡張を定義している.