3. プロトコル仕様
LDP の動作を記述したこれまでのセクションでは, LDP ピア間でメッセージを交換するシナリオについて論じてきた. 本セクションでは, メッセージの符号化, およびメッセージを処理するための手順を規定する.
LDP メッセージ交換は, LDP セッションの TCP 接続上で LDP プロトコルデータユニット (PDU) を送信することによって行われる.
各 LDP PDU は 1 つ以上の LDP メッセージを運ぶことができる. LDP PDU 内のメッセージは互いに関連している必要はないことに注意されたい. 例えば, 単一の PDU が, 複数の FEC に対する FEC-ラベルバインディングを広告するメッセージと, 別の複数の FEC に対するラベルバインディングを要求する別のメッセージと, 何らかのイベントを通知する 3 番目の Notification メッセージを運ぶこともできる.
3.1. LDP PDU
各 LDP PDU は LDP ヘッダの後に 1 つ以上の LDP メッセージが続くものである. LDP ヘッダは次のとおり:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version プロトコルのバージョン番号を含む 2 オクテットの符号なし整数. 本仕様のこのバージョンは LDP プロトコルバージョン 1 を規定する.
PDU Length Version および PDU Length フィールドを除いた, この PDU の全長をオクテット単位で指定する 2 オクテットの整数.
許容される最大 PDU Length は, LDP セッションの初期化時にネゴシエート可能である. ネゴシエーションが完了するまでの許容最大長は 4096 バイトである.
LDP Identifier この PDU が適用される, 送信側 LSR のラベル空間を一意に識別する 6 オクテットのフィールド. 最初の 4 オクテットはその LSR を識別し, グローバルに一意な値でなければならない (MUST). これはその LSR に割り当てられた 32 ビットの router Id であって, Loop Detection Path Vector 内でその LSR を識別するためにも使用されるものであることが望ましい (SHOULD). 最後の 2 オクテットは LSR 内のラベル空間を識別する. プラットフォーム全体で共通のラベル空間の場合, これらはともにゼロであることが望ましい (SHOULD).
LDP PDU の先頭オクテットにはアラインメント要件が存在しないことに注意されたい.
3.2. LDP 手順
LDP は以下の領域におけるメッセージ, TLV, および手順を定義する:
- ピア発見
- セッション管理
- ラベル配布
- エラーおよび勧告情報の通知
以降のセクションでは, これらの領域のメッセージおよび TLV の符号化と, それらに適用される手順を記述する.
ラベル配布手順は複雑であり, 個別のメッセージ仕様および TLV 仕様の寄せ集めとして完全に, 首尾一貫して, かつ曖昧さなく記述することは困難である.
付録 A「LDP Label Distribution Procedures」は, LSR で発生しうるラベル配布イベントと, LSR がどのように応答しなければならないかという観点からラベル配布手順を記述する. 付録 A が LDP ラベル配布手順の仕様である. 本文書の他の箇所で記述された手順が付録 A と矛盾する場合, LDP の動作を規定するのは付録 A である.
3.3. タイプ・レングス・バリュー符号化
LDP は, LDP メッセージで運ばれる情報の多くを符号化するためにタイプ・レングス・バリュー (Type-Length-Value, TLV) 符号化方式を使用する.
LDP TLV は, Type を指定するために 14 ビットを使用し, LSR がその Type を認識しない場合の動作を指定するために 2 ビットを使用する 2 オクテットのフィールドと, それに続く 2 オクテットの Length フィールド, さらにそれに続く可変長の Value フィールドとして符号化される.
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| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit Unknown TLV ビット. 未知の TLV を受信した際, U がクリア (=0) の場合, 通知がメッセージの送信元に返されなければならず (MUST), メッセージ全体が無視されなければならない (MUST). U がセット (=1) の場合, その未知の TLV は黙って無視されなければならず (MUST), 残りのメッセージはその未知の TLV が存在しなかったかのように処理されなければならない (MUST). 以降の TLV を定義するセクションでは, U-bit の値を規定する.
F-bit Forward unknown TLV ビット. このビットは, U-bit がセットされており, かつ未知の TLV を含む LDP メッセージが転送されるべき場合にのみ適用される. F がクリア (=0) の場合, その未知の TLV は, それを含むメッセージとともに転送されない. F がセット (=1) の場合, その未知の TLV は, それを含むメッセージとともに転送される. 以降の TLV を定義するセクションでは, F-bit の値を規定する. U-bit と F-bit の両方をセットすることにより, TLV は不透明な (opaque) データとして, その TLV を認識しないノードを通過して伝播させることができる.
Type Value フィールドをどのように解釈するかを符号化する.
Length Value フィールドの長さをオクテット単位で指定する.
Value Type フィールドで指定されたとおりに解釈される情報を符号化する, Length オクテットのオクテット列.
TLV の先頭オクテットにはアラインメント要件が存在しないことに注意されたい.
Value フィールド自体が TLV 符号化を含むことができることに注意されたい. すなわち, TLV は入れ子にできる.
TLV 符号化方式は非常に一般的である. 原理的には, LDP PDU に現れるすべてのものを TLV として符号化できる. 本仕様は TLV 方式をその完全な一般性までは使用しない. 一般性が不要で, その使用が空間を不必要に浪費する場合には使用されない. こうした箇所は通常, 符号化される値の型が既知であり (例えばメッセージまたはそれを囲む TLV 内の位置によって), かつ値の長さが固定であるか値の符号化自体から容易に導出できる場所である.
LDP のために定義された TLV のいくつかは互いに類似している. 例えば, Generic Label TLV, ATM Label TLV, および Frame Relay TLV がある. セクション「Generic Label TLV」「ATM Label TLV」および「Frame Relay TLV」を参照されたい.
このように関連する TLV を, TLV クラスを指定する TLV type と, そのクラス内の特定の種類の TLV を指定する TLV subtype という観点で考えることは可能であるが, 本仕様は TLV subtype という概念を形式化しない.
本仕様は, ラベル TLV のような関連する TLV に対する type 値を, 16 ビットの TLV タイプ番号空間内の連続したブロックから割り当てる.
セクション「TLV Summary」は, このバージョンのプロトコルで定義される TLV と, それぞれを記述する本文書内のセクションを列挙する.