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

3.4. よく使われるパラメータの TLV 符号化

複数の LDP メッセージで使用されるパラメータがいくつかある. これらのよく使われるパラメータの TLV 符号化を本セクションで規定する.

3.4.1. FEC TLV​

ラベルは転送等価クラス (Forwarding Equivalence Class, FEC) にバインドされる. FEC は 1 つ以上の FEC element のリストである. FEC TLV は FEC 項目を符号化する.

その符号化は次のとおり:

 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|0| FEC (0x0100) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FEC Element 1 to FEC Element n FEC element にはいくつかのタイプがある. セクション「FECs」を参照されたい. FEC element の符号化は FEC element のタイプに依存する.

FEC Element の値は, 要素タイプを指定する 1 オクテットのフィールドと, タイプ依存の要素値である可変長フィールドとして符号化される. FEC element 値の表現はタイプ依存であるが, FEC element の符号化自体は標準的な LDP TLV 符号化を使用しないものであることに注意されたい.

FEC Element の値の符号化は次のとおり:

  FEC Element       Type      Value
type name
        Wildcard        0x01      No value; i.e., 0 value octets;
see below.
Prefix 0x02 See below.

このバージョンの LDP は, Label Mapping メッセージについてのみ, FEC ごとに複数の FEC Element を使用することをサポートすることに注意されたい. 他のメッセージでの複数の FEC Element の使用は, このバージョンでは許可されず, 今後の検討課題である.

Wildcard FEC Element

  Label Withdraw および Label Release メッセージでのみ使用される. ウィズドロー/リリースが, 後続の label TLV 内のラベルに関連付けられたすべての FEC に適用されることを示す. FEC TLV 内で唯一の FEC Element でなければならない.

Prefix FEC Element の値の符号化:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Address Family
[ASSIGNED_AF] の ADDRESS FAMILY NUMBERS からの値を含む 2 オクテットの量であり, Prefix フィールド内のアドレスプレフィックスのアドレスファミリを符号化する.

PreLen
後続するアドレスプレフィックスの長さをビット単位で含む 1 オクテットの符号なし整数. 長さゼロは, すべてのアドレスに一致するプレフィックス (デフォルト宛先) を示す. この場合, Prefix 自体はゼロオクテットである.

Prefix
Address Family フィールドに従って符号化され, その長さ (ビット) が PreLen フィールドで指定されたアドレスプレフィックスであり, バイト境界までパディングされている.

3.4.1.1. FEC の手順​

FEC TLV の復号において, LSR が, 自身がサポートしない Address Family を持つ FEC Element に遭遇した場合, それは FEC TLV の復号を停止し, その TLV を含むメッセージの処理を中止し, 自身の LDP ピアにエラーを通知する "Unsupported Address Family" Notification メッセージを送信することが望ましい (SHOULD).

復号できない FEC Element タイプに遭遇した場合, それは FEC TLV の復号を停止し, その TLV を含むメッセージの処理を中止し, 自身の LDP ピアにエラーを通知する "Unknown FEC" Notification メッセージを送信することが望ましい (SHOULD).

3.4.2. Label TLV​

Label TLV はラベルを符号化する. Label TLV は, ラベルマッピングを広告し, 要求し, 解放し, ウィズドローするために使用されるメッセージによって運ばれる.

Label TLV を必要とする状況で現れうる Label TLV には, いくつかの異なる種類がある.

3.4.2.1. Generic Label TLV​

LSR は, ラベル値が基盤となるリンク技術に依存しないリンクで使用するためのラベルを符号化するために Generic Label TLV を使用する. そのようなリンクの例は PPP および Ethernet である.

 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|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Label これは 20 ビットのラベル値であり, 4 オクテットのフィールド内に 20 ビットの数値として次のように表現される:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

詳細については [RFC3032] を参照されたい.

3.4.2.2. ATM Label TLV​

LSR は, ATM リンクで使用するためのラベルを符号化するために ATM Label TLV を使用する.

 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|0| ATM Label (0x0201) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| V | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Res このフィールドは予約されている. 送信時にはゼロに設定されなければならず (MUST), 受信時には無視されなければならない (MUST).

V-bits 2 ビットのスイッチング指示子. V-bits が 00 の場合, VPI と VCI の両方が有意である. V-bits が 01 の場合, VPI フィールドのみが有意である. V-bit が 10 の場合, VCI のみが有意である.

VPI Virtual Path Identifier. VPI が 12 ビット未満の場合, それはこのフィールド内で右詰めされるべきであり (SHOULD), 先行するビットは 0 に設定されるべきである (SHOULD).

VCI Virtual Channel Identifier. VCI が 16 ビット未満の場合, それはフィールド内で右詰めされるべきであり (SHOULD), 先行するビットは 0 に設定されなければならない (MUST). V-bits フィールドで Virtual Path switching が示されている場合, このフィールドは受信側で無視されなければならず (MUST), 送信側で 0 に設定されなければならない (MUST).

3.4.2.3. Frame Relay Label TLV​

LSR は, フレームリレーリンクで使用するためのラベルを符号化するために Frame Relay Label TLV を使用する.

 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|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Res このフィールドは予約されている. 送信時にはゼロに設定されなければならず (MUST), 受信時には無視されなければならない (MUST).

Len このフィールドは DLCI のビット数を指定する. 次の値がサポートされる:

  0 = 10 bits of DLCI
2 = 23 bits of DLCI

Len 値 1 および 3 は予約されている.

DLCI Data Link Connection Identifier

10 ビット DLCI の場合, 符号化は次のとおり:

    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|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| 0 | 10-bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

23 ビット DLCI の場合, 符号化は次のとおり:

    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|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| 23-bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

詳細については [RFC3034] を参照されたい.

3.4.3. Address List TLV​

Address List TLV は Address および Address Withdraw メッセージに現れる.

その符号化は次のとおり:

 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|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Addresses |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address Family [ASSIGNED_AF] の ADDRESS FAMILY NUMBERS からの値を含む 2 オクテットの量であり, Addresses フィールドに含まれるアドレスを符号化する.

Addresses 指定された Address Family のアドレスのリスト. 個々のアドレスの符号化は Address Family に依存する.

このバージョンのプロトコルでは次のアドレス符号化が定義されている:

  Address Family      Address Encoding
      IPv4                4 octet full IPv4 address
IPv6 16 octet full IPv6 address

3.4.4. Hop Count TLV​

Hop Count TLV は, LSP を設定するメッセージにおける任意フィールドとして現れる. それは, LSP が設定されつつある過程で, LSP に沿った LSR ホップ数を計算する.

ATM およびフレームリレーリンクを通過する LSP の設定手順は Hop Count TLV の使用を要することに注意されたい ([RFC3035] および [RFC3034] を参照).

 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|0| Hop Count (0x0103) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC Value |
+-+-+-+-+-+-+-+-+

HC Value 1 オクテットの符号なし整数のホップカウント値.

3.4.4.1. Hop Count の手順​

LSP の設定中, LSR R は, その LSP に対する Label Mapping または Label Request メッセージであって Hop Count TLV を含むものを受信することがある. その場合, それはそのホップカウント値を記録することが望ましい (SHOULD).

その後 LSR R が, LSP 設定を継続するために, その LSP に対する Label Mapping メッセージを上流ピアへ, または Label Request メッセージを下流ピアへ伝播する場合, それは次のようにして伝播するメッセージに含めるホップカウントを決定しなければならない:

  • メッセージが Label Request メッセージである場合, R は受信したホップカウントをインクリメントしなければならない (MUST).

  • メッセージが Label Mapping メッセージである場合, R は次のようにしてホップカウントを決定する:

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

    o それ以外の場合, R は受信したホップカウントをインクリメントしなければならない (MUST).

LSP 内の最初の LSR (Label Request メッセージでは ingress, Label Mapping メッセージでは egress) は, ホップカウント値を 1 に設定することが望ましい (SHOULD).

慣例により, 値 0 は未知のホップカウントを示す. 未知のホップカウントをインクリメントした結果は, それ自体が未知のホップカウント (0) である.

未知のホップカウント値の使用は, 独立制御が使用される場合のシグナリングオーバーヘッドを大幅に低減する. 新しい LSP が確立されるとき, 各 LSR は未知のホップカウントから開始する. ホップカウントも未知である新しい LSR の追加は, ホップカウントが未知のままであるため, ホップカウント更新を上流に伝播させることを引き起こさない. egress が最終的に LSP に追加されると, そのとき LSR 群は Label Mapping メッセージを介してホップカウント更新を上流に伝播する.

未知のホップカウントを使用しない場合, 新しい LSR が LSP に追加されるたびに, その新しい LSR が他のどの LSR よりも egress に近い場合には, ホップカウント更新を上流に伝播する必要がある. これらの更新は egress までのホップカウントを反映しないため, 無駄なオーバーヘッドである.

ingress ノードの観点からは, ホップカウントが未知であるという事実は, LSP 上で送信されたパケットが実際に egress に到達するかどうかについて何も含意しない. それが含意するのは, egress からのホップカウント更新がまだ ingress に到達していないということだけである.

LSR が Hop Count TLV を含むメッセージを受信した場合, それはホップカウント値を確認し, ホップカウントが設定された最大許容値を超えたかどうかを判定しなければならない (MUST). 超えた場合, それは, そのメッセージの送信元への応答として Loop Detected を通知する Notification メッセージを送信することにより, 含まれるメッセージがループを通過したかのように振る舞わなければならない (MUST).

Loop Detection が設定されている場合, LSR はセクション「Loop Detection」で規定された手順に従わなければならない (MUST).

3.4.5. Path Vector TLV​

Path Vector TLV は, 任意の LDP Loop Detection メカニズムを実装するために, Label Request および Label Mapping メッセージで Hop Count TLV とともに使用される. セクション「Loop Detection」を参照されたい. Label Request メッセージでのその使用は, その要求が通過した LSR の経路を記録する. Label Mapping メッセージでのその使用は, ラベル広告が LSP を設定するために通過した LSR の経路を記録する. その符号化は次のとおり:

 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|0| Path Vector (0x0104) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

One or more LSR Ids メッセージが通過した LSR の経路を示す router-id のリスト. 各 LSR Id は, 対応する LSR の LDP Identifier の最初の 4 オクテット (router-id) である. これにより, LSR ネットワーク内で一意であることが保証される.

3.4.5.1. Path Vector の手順​

Path Vector TLV は, Loop Detection が設定されている場合に Label Mapping および Label Request メッセージで運ばれる.

3.4.5.1.1. Label Request の Path Vector​

セクション「Loop Detection」は, LSR が Label Request メッセージに Path Vector TLV を含めなければならない状況を規定する.

Label Request メッセージで Path Vector を受信する LSR は, セクション「Loop Detection」で記述された手順を実行しなければならない (MUST).

LSR がループを検出した場合, それはその Label Request メッセージを拒否しなければならない (MUST).

LSR は次のことをしなければならない (MUST):

  1. "Loop Detected" を通知する Notification メッセージを送信側 LSR に送信する.

  2. その Label Request メッセージをそれ以上伝播させない.

Path Vector TLV を持つ Label Request メッセージは, 次のいずれかまで転送されることに注意されたい:

  1. ループが見つかる,

  2. LSP egress に到達する, または

  3. 最大 Path Vector 制限または最大 Hop Count 制限に到達する. これはループが検出されたかのように扱われる.

3.4.5.1.2. Label Mapping の Path Vector​

セクション「Loop Detection」は, LSR が Label Mapping メッセージに Path Vector TLV を含めなければならない状況を規定する.

Label Mapping メッセージで Path Vector を受信する LSR は, セクション「Loop Detection」で記述された手順を実行しなければならない (MUST).

LSR がループを検出した場合, 転送ループを防止するために, それはその Label Mapping メッセージを拒否しなければならない (MUST). LSR は次のことをしなければならない (MUST):

  1. "Loop Detected" を通知するために, Status TLV を運ぶ Label Release メッセージを送信側 LSR に送信する.

  2. そのメッセージをそれ以上伝播させない.

  3. その Label Mapping メッセージが既存の LSP に対するものかどうかを確認する. そうである場合, LSR は, その FEC に対する下流ラベルにスプライスされている上流ラベルがあれば, それらをアンスプライスしなければならない.

Path Vector TLV を持つ Label Mapping メッセージは, 次のいずれかまで転送されることに注意されたい:

  1. ループが見つかる,

  2. LSP ingress に到達する, または

  3. 最大 Path Vector 制限または最大 Hop Count 制限に到達する. これはループが検出されたかのように扱われる.

3.4.6. Status TLV​

Notification メッセージは, 通知されるイベントを指定するために Status TLV を運ぶ.

Status TLV の符号化は次のとおり:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U-bit Status TLV が Notification メッセージで送信される場合は 0 であることが望ましい (SHOULD). Status TLV がその他のメッセージで送信される場合は 1 であることが望ましい (SHOULD).

F-bit Status Code フィールドの F-bit の設定と同じであることが望ましい (SHOULD).

Status Code 通知されるイベントを符号化する 32 ビットの符号なし整数. Status Code の構造は次のとおり:

    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F| Status Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E-bit Fatal error ビット. セット (=1) の場合, これは致命的な Error Notification である. クリア (=0) の場合, これは Advisory Notification である.

F-bit Forward ビット. セット (=1) の場合, 通知は, 通知されるイベントに関連する LSP のネクストホップまたは前ホップがあればその LSR に転送されることが望ましい (SHOULD). クリア (=0) の場合, 通知は転送されるべきではない (SHOULD NOT).

Status Data ステータス情報を指定する 30 ビットの符号なし整数.

  本仕様は Status Code (上記の符号化を持つ 32 ビットの符号なし整数) を定義する.

Status Code 0 は成功を通知する.

Message ID 非ゼロの場合, Status TLV が参照するピアメッセージを識別する 32 ビット値. ゼロの場合, 特定のピアメッセージを識別していない.

Message Type 非ゼロの場合, Status TLV が参照するピアメッセージのタイプ. ゼロの場合, Status TLV は特定のメッセージタイプを参照しない.

Status TLV の使用は Notification メッセージに限定されないことに注意されたい. Notification メッセージ以外のメッセージが, Any パラメータとして Status TLV を運んでもよい. Notification 以外のメッセージが Status TLV を運ぶ場合, Status TLV の U-bit は 1 に設定されることが望ましい (SHOULD). これは, 受信側がその TLV を扱う準備ができていない場合にその TLV を黙って破棄すべきである (SHOULD) ことを示す.