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

3.5.7. Label Mapping メッセージ

LSR は, FEC-ラベルバインディングをピアに広告するために, LDP ピアに Label Mapping メッセージを送信する.

Label Mapping メッセージの符号化は次のとおり:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|   Label Mapping (0x0400)    |      Message Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Message ID                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     FEC TLV                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Label TLV                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Optional Parameters                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID このメッセージを識別するために使用される 32 ビット値.

FEC TLV 広告される FEC-Label マッピングの FEC 構成要素を指定する. 符号化についてはセクション「FEC TLVs」を参照されたい.

Label TLV FEC-Label マッピングの Label 構成要素を指定する. 符号化についてはセクション「Label TLV」を参照されたい.

Optional Parameters この可変長フィールドは 0 個以上のパラメータを含み, 各パラメータは TLV として符号化される. 任意パラメータは次のとおり:

  Optional Parameter    Length       Value
      Label Request         4            See below
          Message ID TLV
      Hop Count TLV         1            See below
      Path Vector TLV       variable     See below

Hop Count および Path Vector TLV の符号化は, セクション「TLV Encodings for Commonly Used Parameters」にある.

Label Request Message ID この Label Mapping メッセージが Label Request メッセージへの応答である場合, それは Label Request Message ID 任意パラメータを含まなければならない (MUST). この任意パラメータの値は, 対応する Label Request メッセージの Message ID である.

Hop Count Label メッセージによって設定されつつある LSP に沿った LSR ホップ数の累計を指定する. セクション「Hop Count Procedures」はこの TLV の扱い方を記述する.

Path Vector Label メッセージによって設定されつつある LSP に沿った LSR を指定する. セクション「Path Vector Procedures」はこの TLV の扱い方を記述する.

3.5.7.1. Label Mapping メッセージの手順​

Mapping メッセージは, LSR が FEC に対するラベルマッピングを LDP ピアに配布するために使用する. LSR が FEC に対するマッピングを複数の LDP ピアに配布する場合, 単一のラベルをその FEC にマッピングしてそのマッピングをすべてのピアに配布するのか, それともピアごとに異なるマッピングを使用するのかは, ローカルな事項である.

LSR は, 自身が配布したラベルマッピングの一貫性, およびピアがそれらのマッピングを持つことについて責任を負う.

下流 LSR から Prefix に対する Label Mapping メッセージを受信する LSR は, 自身のルーティングテーブルがその FEC Element に完全に一致するエントリを含んでいない限り, そのラベルを転送に使用すべきではない (SHOULD NOT).

詳細については, 付録 A「LDP Label Distribution Procedures」を参照されたい.

3.5.7.1.1. 独立制御マッピング​

LSR が独立制御 (Independent Control) 用に設定されている場合, マッピングメッセージは次のいずれかの条件でその LSR によって送信される:

  1. LSR が転送テーブルを介して新しい FEC を認識し, かつラベル広告方式が Downstream Unsolicited 広告である.

  2. LSR が, その LSR の転送テーブルに存在する FEC に対する Request メッセージを上流ピアから受信する.

  3. FEC のネクストホップが別の LDP ピアに変化し, かつ Loop detection が設定されている.

  4. マッピングの属性が変化する.

  5. 下流ネクストホップからマッピングを受信し, かつ

    a) 上流マッピングが作成されていない, または b) loop detection が設定されている, または c) マッピングの属性が変化した.

3.5.7.1.2. 順序制御マッピング​

LSR が順序制御 (Ordered Control) を行っている場合, Mapping メッセージは次のいずれかの条件で下流 LSR によって送信される:

  1. LSR が転送テーブルを介して新しい FEC を認識し, かつその FEC の egress である.

  2. LSR が, その LSR の転送テーブルに存在する FEC に対する Request メッセージを上流ピアから受信し, かつその LSR がその FEC の egress であるか, またはその FEC に対する下流マッピングを持っている.

  3. FEC のネクストホップが別の LDP ピアに変化し, かつ Loop Detection が設定されている.

  4. マッピングの属性が変化する.

  5. 下流ネクストホップからマッピングを受信し, かつ

         a) no upstream mapping has been created   OR
         b) Loop Detection is configured   OR
         c) the attributes of the mapping have changed.

3.5.7.1.3. Downstream on Demand によるラベル広告​

一般に, Downstream on Demand モードで動作する場合, 上流 LSR がラベルマッピングを要求する責任を負う. しかし, いくつかの規則に従わない限り, 広告方式の異なる隣接 LSR が, すべてが正常に機能しているにもかかわらずラベルが配布されないライブロック状況に陥る可能性がある. 例えば, 2 台の LSR Ru と Rd を考え, Ru が特定の FEC に対する上流 LSR であり, Rd が下流 LSR であるとする. この例で, Ru は Downstream Unsolicited 広告モードを使用し, Rd は Downstream on Demand モードを使用している. この場合, Rd は, Ru が必要になったときにラベルマッピングを要求するだろうと想定するかもしれず, また Ru は, Rd が Ru にラベルを使用してほしい場合に Rd がラベルを広告するだろうと想定するかもしれない. Rd と Ru が示唆どおりに動作するなら, Rd から Ru へはラベルが配布されない.

このライブロック状況は, 次の規則を守ることによって回避できる. すなわち, Downstream on Demand モードで動作する LSR は, 求められていないマッピング広告を送信することを期待されるべきではない (SHOULD NOT). したがって, 下流 LSR が Downstream on Demand モードで動作している場合, 上流 LSR が, 必要に応じてラベルマッピングを要求する責任を負う.

3.5.7.1.4. Downstream Unsolicited によるラベル広告​

一般に, 下流 LSR は, 上流 LSR にラベルを使用してほしいときにラベルマッピングを広告する責任を負う. 上流 LSR は, 望むならマッピング要求を発行してよい.

Downstream Unsolicited モードとコンサバティブ保持 (Conservative Label retention) の組み合わせは, LSR が, 後に必要となる FEC のラベルを解放してしまう状況につながりうる. 例えば, LSR Rd が LSR Ru に対して, Ru のネクストホップではない FEC のラベルを広告した場合, Ru はそのラベルを解放する. その後 Ru のその FEC に対するネクストホップが Rd に変化した場合, それは以前に解放したラベルを必要とする.

この状況に対処するため, Ru は必要になったときにラベルを明示的に要求でき, または Rd は定期的にそれを Ru に再広告できる. 多くの状況で, Ru は Rd からラベルを必要とするときを認識する. 例えば, その FEC に対するネクストホップが Rd に変化したときである. しかし, Ru が認識しない状況もありうる. 例えば, Rd が非標準の性質を持つ LSP を確立しようとしている場合である. この状況で Ru にラベルを明示的に要求することを強制すると, 非標準の性質を持つ潜在的な LSP に関する状態を維持することを Ru に要求することになる.

Ru がラベルを必要としていることを認識する状況では, それは Label Request メッセージによってそのラベルを明示的に要求する責任を負う. Ru がラベルを必要としていることを認識しないかもしれない状況では, Rd がそのラベルを定期的に Ru に再広告する責任を負う.

このバージョンの LDP において, Ru が Rd から FEC に対するラベルを必要としていることを認識する唯一の状況は, Rd がその FEC に対する Ru のネクストホップであり, Ru が Rd からラベルを持っておらず, かつその FEC に対する LSP が本文書で定義される TLV で確立できるものである場合である.