RFC 4379 - 3. Packet Format
3. パケット形式 (Packet Format)
本節では、MPLS echo メッセージで使用されるメッセージタイプ、応答モード、リターンコード、TLV を定義する。
MPLS echo request は、(ラベルが付くこともある) IPv4 または IPv6 の UDP パケットである。UDP パケットの内容は以下の形式をとる。
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 Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Number は現在 1 である。(注: 実装が MPLS echo request/reply を正しく解析または処理する能力に影響する変更が行われるたびに、バージョン番号を増分する必要がある。こうした変更には、いずれかの固定フィールドに対する構文上または意味上の変更、および特定のバージョン番号で定義された Type-Length-Value (TLV) またはサブ TLV の割り当てや形式に対する変更が含まれる。省略可能な TLV またはサブ TLV を追加する場合には、バージョン番号を変更する必要がないこともある。)
Global Flags フィールドは以下の形式のビットベクトルである。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
現時点で定義されているフラグは V ビットの 1 つだけであり、残りは送信時にゼロに設定しなければならず (MUST)、受信時には無視される。
V (Validate FEC Stack) フラグは、送信側が受信側に FEC スタック検証の実行を求める場合に 1 に設定される。V が 0 の場合、その選択は受信側に委ねられる。
Message Type は以下のいずれかである。
| 値 | 意味 |
|---|---|
| 1 | MPLS echo request (MPLS エコー要求) |
| 2 | MPLS echo reply (MPLS エコー応答) |
Reply Mode は以下のいずれかの値をとることができる。
| 値 | 意味 |
|---|---|
| 1 | Do not reply (応答しない) |
| 2 | Reply via an IPv4/IPv6 UDP packet (IPv4/IPv6 UDP パケットで応答) |
| 3 | Reply via an IPv4/IPv6 UDP packet with Router Alert (Router Alert 付き IPv4/IPv6 UDP パケットで応答) |
| 4 | Reply via application level control channel (アプリケーション層制御チャネルで応答) |
Reply Mode フィールドが 1 (応答しない) である MPLS echo request は、片方向の疎通テストに使用できる。受信ルータは、Sequence Number の欠落を記録したり、遅延やジッタの統計を維持したりしてもよい。MPLS echo request は通常、Reply Mode フィールドに 2 (IPv4/IPv6 UDP パケットで応答) をとる。通常の IP 戻り経路が信頼できないと判断される場合は、3 (Router Alert 付き IPv4/IPv6 UDP パケットで応答) を使用できる。この場合、すべての中間ルータが MPLS echo reply を理解し、その転送方法を知っている必要があることに注意する。echo reply は、受信した echo request と同じ IP バージョン番号を使用する。すなわち、IPv4 でカプセル化された echo request に対しては、IPv4 でカプセル化された echo reply が送信される。
一部のアプリケーションは IP 制御チャネルをサポートする。その一例が、Virtual Circuit Connectivity Verification (VCCV) [VCCV] で定義されている関連制御チャネル (associated control channel) である。制御エンティティ間に IP 制御チャネルをサポートするアプリケーションは、Reply Mode を 4 (アプリケーション層制御チャネルで応答) に設定することで、応答が同じチャネルを使用することを保証できる。このコードポイントのさらなる定義はアプリケーション固有であり、したがって本文書の範囲外である。
リターンコードとサブコードについては次節で説明する。
Sender's Handle は送信側が設定し、受信側が echo reply (もしあれば) で変更せずに返す。このハンドルに関連する意味づけはないが、送信側はこれを要求と応答の対応付けに役立てることができる。
Sequence Number は MPLS echo request の送信側が割り当てるものであり、(例えば) 応答の欠落を検出するために使用できる。
TimeStamp Sent は、MPLS echo request を送信した時刻 (送信側のクロックによる秒とマイクロ秒) を NTP 形式 [NTP] で表したものである。echo reply 内の TimeStamp Received は、対応する echo request を受信した時刻 (受信側のクロックによる) を NTP 形式で表したものである。
TLV (Type-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
タイプは以下で定義する。Length は Value フィールドの長さ (オクテット単位) である。Value フィールドはタイプに依存し、4 オクテット境界に揃えるためにゼロでパディングされる。TLV は他の TLV の中にネストすることができ、その場合ネストされた TLV はサブ TLV と呼ばれる。サブ TLV は独立したタイプを持ち、同じく 4 オクテットに整列しなければならない (MUST)。
以下に 2 つの例を示す。Label Distribution Protocol (LDP) の IPv4 FEC サブ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
この TLV の Length は 5 である。LDP IPv4 FEC サブ TLV と VPN IPv4 プレフィックス サブ TLV を含むターゲット FEC スタック 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (FEC TLV) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP ping 用のトップレベル TLV のタイプと値 (Types and Values) を以下に示す。
| タイプ番号 (Type #) | 値フィールド (Value Field) |
|---|---|
| 1 | Target FEC Stack (ターゲット FEC スタック) |
| 2 | Downstream Mapping (ダウンストリームマッピング) |
| 3 | Pad (パッド) |
| 4 | Not Assigned (未割り当て) |
| 5 | Vendor Enterprise Number (ベンダー企業番号) |
| 6 | Not Assigned (未割り当て) |
| 7 | Interface and Label Stack (インタフェースとラベルスタック) |
| 8 | Not Assigned (未割り当て) |
| 9 | Errored TLVs (エラーとなった TLV) |
| 10 | Reply TOS Byte (応答 TOS バイト) |
32768 未満のタイプ (すなわち最上位ビットが 0) は必須 (mandatory) TLV であり、実装がこれをサポートするか、さもなければ echo 応答でリターンコード 2 (「1 つ以上の TLV が理解されなかった」) を返さなければならない (MUST)。
32768 以上のタイプ (すなわち最上位ビットが 1) は任意 (optional) TLV であり、実装がこれを理解またはサポートしていない場合は無視すべきである (SHOULD)。
3.1. リターンコード (Return Codes)
リターンコードは送信側がゼロに設定する。受信側は以下に列挙する値のいずれかに設定できる。表記
| 値 | 意味 |
|---|---|
| 0 | No return code (リターンコードなし) |
| 1 | Malformed echo request received (形式不正な echo request を受信) |
| 2 | One or more of the TLVs was not understood (1 つ以上の TLV が理解されなかった) |
| 3 | Replying router is an egress for the FEC at stack-depth |
| 4 | Replying router has no mapping for the FEC at stack-depth |
| 5 | Downstream Mapping Mismatch (ダウンストリームマッピングの不一致) (注 1 参照) |
| 6 | Upstream Interface Index Unknown (上流インタフェースインデックス不明) (注 1 参照) |
| 7 | Reserved (予約済み) |
| 8 | Label switched at stack-depth |
| 9 | Label switched but no MPLS forwarding at stack-depth |
| 10 | Mapping for this FEC is not the given label at stack-depth |
| 11 | No label entry at stack-depth |
| 12 | Protocol not associated with interface at FEC stack-depth |
| 13 | Premature termination of ping due to label stack shrinking to a single label (ラベルスタックが単一ラベルに縮小したため ping が途中で終了した) |
注 1
リターンサブコードは、ラベルスタック内で処理が終了した位置を格納する。RSC が 0 の場合、どのラベルも処理されなかった。それ以外の場合、そのパケットは深さ RSC でラベルスイッチされるはずだった。
3.2. ターゲット FEC スタック (Target FEC Stack)
ターゲット FEC スタック (Target FEC Stack) はサブ TLV のリストである。要素数は各サブ TLV の Length フィールドを見て決定する。
| サブタイプ (Sub-Type) | 長さ (Length) | 値フィールド (Value Field) |
|---|---|---|
| 1 | 5 | LDP IPv4 prefix (LDP IPv4 プレフィックス) |
| 2 | 17 | LDP IPv6 prefix (LDP IPv6 プレフィックス) |
| 3 | 20 | RSVP IPv4 LSP (RSVP IPv4 LSP) |
| 4 | 56 | RSVP IPv6 LSP (RSVP IPv6 LSP) |
| 5 | Not Assigned (未割り当て) | |
| 6 | 13 | VPN IPv4 prefix (VPN IPv4 プレフィックス) |
| 7 | 25 | VPN IPv6 prefix (VPN IPv6 プレフィックス) |
| 8 | 14 | L2 VPN endpoint (L2 VPN エンドポイント) |
| 9 | 10 | "FEC 128" Pseudowire ("FEC 128" 疑似回線、廃止) |
| 10 | 14 | "FEC 128" Pseudowire ("FEC 128" 疑似回線) |
| 11 | 16+ | "FEC 129" Pseudowire ("FEC 129" 疑似回線) |
| 12 | 5 | BGP labeled IPv4 prefix (BGP ラベル付き IPv4 プレフィックス) |
| 13 | 17 | BGP labeled IPv6 prefix (BGP ラベル付き IPv6 プレフィックス) |
| 14 | 5 | Generic IPv4 prefix (汎用 IPv4 プレフィックス) |
| 15 | 17 | Generic IPv6 prefix (汎用 IPv6 プレフィックス) |
| 16 | 4 | Nil FEC (Nil FEC) |
その他の FEC タイプは必要に応じて定義される。
この TLV が定義するのは FEC のスタックであり、最初の FEC 要素がラベルスタックの先頭 (top) に対応し、以下同様であることに注意する。
MPLS echo request は、試験対象の FEC スタックを記述するターゲット FEC スタックを持たなければならない (MUST)。例えば、LSR X が 192.168.1.1 に対する LDP マッピング [LDP] を持つとする (ラベルは 1001 とする)。ラベル 1001 が、LDP 経由でこのプレフィックスを通知した出口 LSR に実際に到達することを検証するには、X は、FEC スタック TLV に FEC を 1 つだけ (タイプが LDP IPv4 prefix で、プレフィックスが 192.168.1.1/32) 含む MPLS echo request を送り、その echo request をラベル 1001 付きで送信すればよい。
次に、LSR X が、ラベルスタック <1001, 23456> が VPN foo 内の VPN IPv4 プレフィックス 10/8 (3.2.5 節参照) に到達するための正しいラベルスタックであることを検証したいとする。さらに、ループバックアドレス 192.168.1.1 を持つ LSR Y が、ルート識別子 (Route Distinguisher) RD-foo-Y (一般には、LSR X 自身が VPN foo に対して広告で使用するルート識別子と異なりうる)、ラベル 23456、BGP ネクストホップ 192.168.1.1 とともにプレフィックス 10/8 を通知したとする [BGP]。最後に、LSR X が 192.168.1.1 に対するラベルバインディング 1001 を LDP 経由で受信したとする。X が MPLS echo request を送る際の選択肢は 2 つある。X は、タイプが VPN IPv4 prefix でプレフィックスが 10/8、ルート識別子が RD-foo-Y である FEC を 1 つだけ含む FEC スタック TLV を伴う MPLS echo request を送ることができる。あるいは、X は、2 つの FEC を含む FEC スタック TLV を送ることもできる。1 つ目はタイプが LDP IPv4 でプレフィックスが 192.168.1.1/32、2 つ目はタイプが IP VPN でプレフィックスが 10/8、ルート識別子が RD-foo-Y である。いずれの場合も、MPLS echo request のラベルスタックは <1001, 23456> となる。(注: この例では、1001 が「外側」のラベル、23456 が「内側」のラベルである。)
3.2.1. LDP IPv4 プレフィックス (LDP IPv4 Prefix)
IPv4 プレフィックス FEC は [LDP] で定義されている。LDP IPv4 プレフィックスをラベルスタック内に符号化する際には、以下の形式を使用する。値は 4 オクテットの IPv4 プレフィックスと、それに続く 1 オクテットのプレフィックス長 (ビット単位) から成る。形式を以下に示す。IPv4 プレフィックスはネットワークバイトオーダであり、プレフィックスが 32 ビットより短い場合は、後続ビットをゼロに設定すべきである (SHOULD)。IPv4 FEC に対するマッピングの例は [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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. LDP IPv6 プレフィックス (LDP IPv6 Prefix)
IPv6 プレフィックス FEC は [LDP] で定義されている。LDP IPv6 プレフィックスをラベルスタック内に符号化する際には、以下の形式を使用する。値は 16 オクテットの IPv6 プレフィックスと、それに続く 1 オクテットのプレフィックス長 (ビット単位) から成る。形式を以下に示す。IPv6 プレフィックスはネットワークバイトオーダであり、プレフィックスが 128 ビットより短い場合は、後続ビットをゼロに設定すべきである (SHOULD)。IPv6 FEC に対するマッピングの例は [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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. RSVP IPv4 LSP (RSVP IPv4 LSP)
値は以下の形式をとる。各値フィールドは RFC 3209 の 4.6.1.1 節および 4.6.2.1 節から取られている。[RSVP-TE] を参照のこと。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.4. RSVP IPv6 LSP (RSVP IPv6 LSP)
値は以下の形式をとる。各値フィールドは RFC 3209 の 4.6.1.2 節および 4.6.2.2 節から取られている。[RSVP-TE] を参照のこと。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.5. VPN IPv4 プレフィックス (VPN IPv4 Prefix)
VPN-IPv4 ネットワーク層ルーティング情報 (NLRI) は [RFC4365] で定義されている。本文書では、BGP において MPLS ラベルとともに通知された VPN-IPv4 NLRI を指す用語として VPN IPv4 prefix を用いる。[BGP-LABEL] を参照のこと。
VPN IPv4 プレフィックスをラベルスタック内に符号化する際には、以下の形式を使用する。値フィールドは、その VPN IPv4 プレフィックスとともに通知されたルート識別子 (Route Distinguisher)、IPv4 プレフィックス (合計 32 ビットになるよう後続 0 ビットで埋める)、およびプレフィックス長から成り、以下のとおりである。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ルート識別子 (RD) は 8 オクテットの識別子であり、それ自体に固有の情報は含まない。RD の目的は、共通の IPv4 アドレスプレフィックスに対して別個のルートを作成できるようにすることだけである。ここでは RD の符号化は重要ではない。このフィールドをローカルの FEC 情報と照合する際には、不透明 (opaque) な値として扱う。
3.2.6. VPN IPv6 プレフィックス (VPN IPv6 Prefix)
VPN-IPv6 ネットワーク層ルーティング情報 (NLRI) は [RFC4365] で定義されている。本文書では、BGP において MPLS ラベルとともに通知された VPN-IPv6 NLRI を指す用語として VPN IPv6 prefix を用いる。[BGP-LABEL] を参照のこと。
VPN IPv6 プレフィックスをラベルスタック内に符号化する際には、以下の形式を使用する。値フィールドは、その VPN IPv6 プレフィックスとともに通知されたルート識別子 (Route Distinguisher)、IPv6 プレフィックス (合計 128 ビットになるよう後続 0 ビットで埋める)、およびプレフィックス長から成り、以下のとおりである。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ここでのルート識別子は VPN IPv4 プレフィックスの RD と同じものであるが、ここでは IPv6 プレフィックスに対して別個のルートを作成できるようにする役割を担う。3.2.5 節を参照のこと。このフィールドをローカルの FEC 情報と照合する際には、不透明な値として扱う。
3.2.7. L2 VPN エンドポイント (L2 VPN Endpoint)
VPLS は Virtual Private LAN Service (仮想専用 LAN サービス) の略である。VPLS BGP NLRI および VE ID (VPLS Edge Identifier、VPLS エッジ識別子) という用語は [VPLS-BGP] で定義されている。本文書では、VPLS BGP NLRI を指すより簡潔な用語として L2 VPN endpoint を用いる。ルート識別子は、あるノードが通知する各種 L2 VPN に関する情報を区別するために使用される 8 オクテットの識別子である。VE ID は、VPLS 内でサービス接続点として機能する特定のノードを識別するために使用される 2 オクテットの識別子である。ここではこれら 2 つの識別子の構造は重要ではない。これらのフィールドをローカルの FEC 情報と照合する際には、不透明な値として扱う。カプセル化タイプは、後述の 3.2.8 節における PW Type と同じものである。
L2 VPN エンドポイントをラベルスタック内に符号化する際には、以下の形式を使用する。値フィールドは、ルート識別子 (8 オクテット)、ping の送信側の VE ID (2 オクテット)、受信側の VE ID (2 オクテット)、およびカプセル化タイプ (2 オクテット) から成り、以下のとおりである。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.8. FEC 128 疑似回線 (廃止) (FEC 128 Pseudowire (Deprecated))
FEC 128 (0x80) は [PW-CONTROL] で定義されており、PW ID (Pseudowire ID、疑似回線 ID) および PW Type (Pseudowire Type、疑似回線タイプ) という用語も同様である。PW ID は非ゼロの 32 ビット接続 ID である。PW Type はカプセル化タイプを示す 15 ビットの数値である。これは、以下でカプセル化タイプ (encapsulation type) と呼ぶフィールド内に、最上位ビットをゼロとして右詰めで格納される。本プロトコルでは、これら両方のフィールドを不透明な値として扱う。
FEC 128 をラベルスタック内に符号化する際には、以下の形式を使用する。値フィールドは、遠端 PE アドレス (ターゲット LDP セッションの宛先アドレス)、PW ID、およびカプセル化タイプから成り、以下のとおりである。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
この FEC は廃止されており、後方互換性のためだけに残されている。LSP ping の実装はこの TLV を受け入れて処理すべきである (SHOULD) が、旧 TLV を使用するよう明示的に設定されていない限り、新しい TLV (次節参照) を伴う LSP ping echo request を送るべきである (SHOULD)。
この TLV を受信した LSR は、LSP echo request の送信元 IP アドレスを用いて送信側の PE アドレスを推測すべきである (SHOULD)。
3.2.9. FEC 128 疑似回線 (現行) (FEC 128 Pseudowire (Current))
FEC 128 (0x80) は [PW-CONTROL] で定義されており、PW ID (Pseudowire ID、疑似回線 ID) および PW Type (Pseudowire Type、疑似回線タイプ) という用語も同様である。PW ID は非ゼロの 32 ビット接続 ID である。PW Type はカプセル化タイプを示す 15 ビットの数値である。これは、以下でカプセル化タイプ (encapsulation type) と呼ぶフィールド内に、最上位ビットをゼロとして右詰めで格納される。
本プロトコルでは、これら両方のフィールドを不透明な値として扱う。これらのフィールドをローカルの FEC 情報と照合する際には、完全一致 (exact) でなければならない (MUST)。
FEC 128 をラベルスタック内に符号化する際には、以下の形式を使用する。値フィールドは、送信側の PE アドレス (ターゲット LDP セッションの送信元アドレス)、遠端 PE アドレス (ターゲット LDP セッションの宛先アドレス)、PW ID、およびカプセル化タイプから成り、以下のとおりである。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. FEC 129 疑似回線 (FEC 129 Pseudowire)
FEC 129 (0x81) ならびに用語 PW Type、Attachment Group Identifier (AGI、接続グループ識別子)、Attachment Group Identifier Type (AGI Type、接続グループ識別子タイプ)、Attachment Individual Identifier Type (AII Type、接続個別識別子タイプ)、Source Attachment Individual Identifier (SAII、送信元接続個別識別子)、および Target Attachment Individual Identifier (TAII、宛先接続個別識別子) は [PW-CONTROL] で定義されている。PW Type はカプセル化タイプを示す 15 ビットの数値である。これは、以下の PW Type フィールド内に最上位ビットをゼロとして右詰めで格納される。他のすべてのフィールドは不透明な値として扱われ、FEC 129 形式からそのままコピーされる。これらの値は全体として、送信元および遠端の PE アドレスによって識別される LDP セッションの範囲内で、その FEC を一意に定義する。
FEC 129 をラベルスタック内に符号化する際には、以下の形式を使用する。この TLV の Length は 16 + AGI 長 + SAII 長 + TAII 長である。パディングは全長を 4 の倍数にするために使用され、パディングの長さは Length フィールドには含まれない。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. BGP ラベル付き IPv4 プレフィックス (BGP Labeled IPv4 Prefix)
BGP ラベル付き IPv4 プレフィックスは [BGP-LABEL] で定義されている。BGP ラベル付き IPv4 プレフィックスをラベルスタック内に符号化する際には、以下の形式を使用する。値フィールドは IPv4 プレフィックス (合計 32 ビットになるよう後続 0 ビットで埋める) およびプレフィックス長から成り、以下のとおりである。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.12. BGP ラベル付き IPv6 プレフィックス (BGP Labeled IPv6 Prefix)
BGP ラベル付き IPv6 プレフィックスは [BGP-LABEL] で定義されている。BGP ラベル付き IPv6 プレフィックスをラベルスタック内に符号化する際には、以下の形式を使用する。値は 16 オクテットの IPv6 プレフィックスと、それに続く 1 オクテットのプレフィックス長 (ビット単位) から成る。形式を以下に示す。IPv6 プレフィックスはネットワークバイトオーダであり、プレフィックスが 128 ビットより短い場合は、後続ビットをゼロに設定すべきである (SHOULD)。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.13. 汎用 IPv4 プレフィックス (Generic IPv4 Prefix)
値は 4 オクテットの IPv4 プレフィックスと、それに続く 1 オクテットのプレフィックス長 (ビット単位) から成る。形式を以下に示す。IPv4 プレフィックスはネットワークバイトオーダであり、プレフィックスが 32 ビットより短い場合は、後続ビットをゼロに設定すべきである (SHOULD)。この FEC は、ラベルを通知するプロトコルが不明である場合、または LSP の存続期間中に変化しうる場合に使用する。例としては、ある自律システム (AS) では LDP によって、別の AS では RSVP-TE [RSVP-TE] によって、AS 間では BGP によってシグナリングされうる inter-AS LSP があり、これは inter-AS VPN でよく見られる。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.14. 汎用 IPv6 プレフィックス (Generic IPv6 Prefix)
値は 16 オクテットの IPv6 プレフィックスと、それに続く 1 オクテットのプレフィックス長 (ビット単位) から成る。形式を以下に示す。IPv6 プレフィックスはネットワークバイトオーダであり、プレフィックスが 128 ビットより短い場合は、後続ビットをゼロに設定すべきである (SHOULD)。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.15. Nil FEC (Nil FEC)
時として、負荷分散に影響を与えるなどの各種の診断目的で、予約範囲のラベル (例えば Router Alert や Explicit-null) がラベルスタックに追加されることがある。これらのラベルには、明示的に対応する FEC が存在しない場合がある。Nil FEC スタックは、そのようなラベルを勘定に入れるためのターゲット FEC スタック サブ TLV をターゲット FEC スタックに追加できるようにするために定義され、これにより適切な検証を引き続き実行できる。
Length は 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 | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label はラベルスタックに挿入される実際のラベル値である。MBZ フィールドは送信時にはゼロでなければならず (MUST)、受信時には無視される。
3.3. ダウンストリームマッピング (Downstream Mapping)
ダウンストリームマッピング (Downstream Mapping) オブジェクトは、echo request メッセージに含めることのできる (MAY) TLV である。echo request 内に出現できるダウンストリームマッピングオブジェクトは 1 つだけである。ダウンストリームマッピングオブジェクトの存在は、echo reply にダウンストリームマッピングオブジェクトを含めることの要求である。応答ルータがその FEC の宛先である場合、echo reply にダウンストリームマッピング TLV を含めるべきではない (SHOULD NOT)。それ以外の場合、応答ルータは、この FEC を転送しうるインタフェースごとにダウンストリームマッピングオブジェクトを含めるべきである (SHOULD)。「ダウンストリーム」という概念のより正確な定義については、3.3.2 節「ダウンストリームルータとインタフェース (Downstream Router and Interface)」を参照のこと。
Length は K + M + 4*N オクテットであり、M はマルチパス長 (Multipath Length)、N はダウンストリームラベル (Downstream Label) の数である。K の値は後述のアドレスタイプ (Address Type) の説明にある。ダウンストリームマッピングの 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
最大伝送単位 (Maximum Transmission Unit, MTU)
MTU は、ダウンストリーム LSR へのインタフェースに収まる最大の MPLS フレーム (ラベルスタックを含む) のサイズをオクテットで表したものである。
アドレスタイプ (Address Type)
アドレスタイプは、インタフェースが番号付き (numbered) か非番号 (unnumbered) かを示す。また、Downstream IP Address フィールドおよび Downstream Interface フィールドの長さを決定する。TLV の先頭部分の合計は、以下の表に "K Octets" として示す。アドレスタイプは以下のいずれかの値に設定する。
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
DS Flags (ダウンストリームフラグ)
DS Flags フィールドは、以下の形式のビットベクトルである。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
現在定義されているフラグは I と N の 2 つである。残りのフラグは送信時にゼロに設定しなければならず (MUST)、受信時には無視される。
| フラグ | 名称と意味 |
|---|---|
| I | Interface and Label Stack Object Request (インタフェースとラベルスタックオブジェクト要求): このフラグがセットされている場合、応答ルータが echo reply メッセージに Interface and Label Stack オブジェクトを含めるべきである (SHOULD) ことを示す。 |
| N | Treat as a Non-IP Packet (非 IP パケットとして扱う): echo request メッセージは非 IP フローの診断に使用される。しかし、これらのメッセージ自体は IP パケットで運ばれる。FEC または深いパケット検査に基づいて ECMP アルゴリズムを変更するルータに対して、このフラグは、IP ペイロードの判定に失敗した場合と同じように扱うことを要求する。 |
Downstream IP Address と Downstream Interface Address
IPv4 アドレスとインタフェースインデックスは 4 オクテットで、IPv6 アドレスは 16 オクテットで符号化される。
ダウンストリーム LSR へのインタフェースが番号付きである場合、アドレスタイプを IPv4 または IPv6 に設定しなければならず (MUST)、Downstream IP Address はダウンストリーム LSR の Router ID またはダウンストリーム LSR のインタフェースアドレスのいずれかに設定しなければならず (MUST)、Downstream Interface Address はダウンストリーム LSR のインタフェースアドレスに設定しなければならない (MUST)。
ダウンストリーム LSR へのインタフェースが非番号である場合、アドレスタイプは IPv4 Unnumbered または IPv6 Unnumbered でなければならず (MUST)、Downstream IP Address はダウンストリーム LSR の Router ID でなければならず (MUST)、Downstream Interface Address はアップストリーム LSR がそのインタフェースに割り当てたインデックスに設定しなければならない (MUST)。
LSR が隣接ノードの IP アドレスを知らない場合、アドレスタイプを IPv4 Unnumbered または IPv6 Unnumbered に設定しなければならない (MUST)。IPv4 の場合、Downstream IP Address を 127.0.0.1 に設定しなければならず、IPv6 の場合はアドレスを 0::1 に設定する。いずれの場合も、インタフェースインデックスを 0 に設定しなければならない (MUST)。LSR が、Downstream IP Address フィールドにこれらのアドレスのいずれかを持つ Echo Request パケットを受信した場合、これは、インタフェース検証を省略しなければならないが (MUST)、ラベル検証は継続することを示す。
Echo Request パケットの起動側がダウンストリームマッピング情報を取得したいが、期待されるラベルスタックを知らない場合、アドレスタイプを IPv4 Unnumbered または IPv6 Unnumbered に設定すべきである (SHOULD)。IPv4 の場合、Downstream IP Address を 224.0.0.2 に設定しなければならず (MUST)、IPv6 の場合はアドレスを FF02::2 に設定しなければならない (MUST)。いずれの場合も、インタフェースインデックスを 0 に設定しなければならない (MUST)。LSR が全ルータマルチキャストアドレス (all-routers multicast address) を持つ Echo Request パケットを受信した場合、これは、インタフェース検証とラベルスタック検証の両方を省略しなければならないが (MUST)、提供された情報を用いてダウンストリームマッピング TLV を返すことを示す。
マルチパスタイプ (Multipath Type)
以下のマルチパスタイプが定義されている。
| キー | タイプ | マルチパス情報 |
|---|---|---|
| 0 | no multipath (マルチパスなし) | 空 (Multipath Length = 0) |
| 2 | IP address (IP アドレス) | IP アドレス |
| 4 | IP address range (IP アドレス範囲) | 低位/高位アドレスの組 |
| 8 | Bit-masked IP address set (ビットマスク IP アドレス集合) | IP アドレスプレフィックスとビットマスク |
| 9 | Bit-masked label set (ビットマスクラベル集合) | ラベルプレフィックスとビットマスク |
タイプ 0 は、すべてのパケットがこの 1 つのインタフェースから転送されることを示す。
タイプ 2、4、8、9 は、提供されたマルチパス情報がこのパスを実際に使用させる (exercise) ために用いられることを示す。
深さ制限 (Depth Limit)
深さ制限はラベルスタックにのみ適用され、ハッシュ計算で考慮される最大ラベル数である。未指定または無制限の場合はゼロに設定すべきである (SHOULD)。
マルチパス長 (Multipath Length)
マルチパス情報 (Multipath Information) の長さ (オクテット単位)。
マルチパス情報 (Multipath Information)
マルチパスタイプに従って符号化されたアドレスまたはラベル値。符号化の詳細は次節を参照のこと。
ダウンストリームラベル (Downstream Label(s))
このルータがこのインタフェースを通してパケットを転送した場合にラベルスタック内にあるはずのラベルの集合。Implicit Null ラベルもすべて明示的に含める。ラベルは数値として扱われ、すなわちフィールド内で右詰めにされる。
ダウンストリームラベルは 24 ビットであり、TTL フィールドを除いて MPLS ラベルと同じ形式である。すなわち、ラベルの最上位ビット (MSBit) がビット 0、最下位ビット (LSBit) がビット 19、EXP ビットがビット 20〜22、ビット 23 が S ビットである。応答ルータは EXP ビットと S ビットを埋めるべきである (SHOULD)。echo reply を受信した LSR は、これらのビットを無視することを選択してもよい (MAY)。
プロトコル (Protocol)
プロトコルは以下の表から取る。
| Protocol # | シグナリングプロトコル |
|---|---|
| 0 | Unknown (不明) |
| 1 | Static (静的) |
| 2 | BGP |
| 3 | LDP |
| 4 | RSVP-TE |
3.3.1. マルチパス情報の符号化 (Multipath Information Encoding)
マルチパス情報 (Multipath Information) は、このパスを実際に使用させるラベルまたはアドレスを符号化する。マルチパス情報はマルチパスタイプに依存する。このフィールドの内容は上の表に示したとおりである。IPv4 アドレスは 127/8 の範囲から、IPv6 アドレスは 0:0:0:0:0:FFFF:127/104 の範囲から取る。ラベルは数値として扱われ、すなわちフィールド内で右詰めにされる。タイプ 4 では、アドレス対によって示される範囲は重複してはならず (MUST NOT)、昇順でなければならない (MUST)。
タイプ 8 は IP アドレスをより高密度に符号化できるようにする。IP プレフィックスは、非プレフィックスの下位ビットをゼロにしたベース IP アドレスとして整形される。最大プレフィックス長は 27 である。プレフィックスに続いて、IPv4 では 2^(32-プレフィックス長) ビット、IPv6 では 2^(128-プレフィックス長) ビットの長さのマスクが置かれる。1 にセットされた各ビットが有効なアドレスを表す。アドレスは、ベース IPv4 アドレスに、ビットが左から右へゼロから番号付けされるマスク内のそのビットの位置を加えたものである。例えば、IPv4 アドレス 127.2.1.0、127.2.1.5〜127.2.1.15、および 127.2.1.20〜127.2.1.29 は以下のように符号化される。
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 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
これらの同じアドレスを IPv6 に埋め込むと、以下のように符号化される。
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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
タイプ 9 はラベルをより高密度に符号化できるようにする。ラベルプレフィックスは、非プレフィックスの下位ビットをゼロにしたベースラベル値として整形される。最大プレフィックス長 (符号化による先行ゼロを含む) は 27 である。プレフィックスに続いて、長さ 2^(32-プレフィックス長) ビットのマスクが置かれる。1 にセットされた各ビットが有効なラベルを表す。ラベルは、ベースラベルに、ビットが左から右へゼロから番号付けされるマスク内のそのビットの位置を加えたものである。1152 から 1279 までのすべての奇数ラベル値は以下のように符号化される。
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
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
注: 英語原文 (RFC 4379) ではこの例のビットマップが組版の折り返し位置で分断されている。ここでは英語原文のとおりに逐語的に再現した。その意味するところは、先頭部分がベースラベル 1152 (= 0b10010000000) のプレフィックス、それに続く部分が 1 つおきにビットが立った奇数ラベルのマスクである。
受信したマルチパス情報が非ヌルである場合、ラベルおよび IP アドレスは提供された集合から選ばなければならない (MUST)。これらのラベルやアドレスのいずれも特定のダウンストリームインタフェースにマップされない場合、そのインタフェースについてタイプを 0 に設定しなければならない (MUST)。受信したマルチパス情報がヌルである場合 (すなわち Multipath Length = 0、またはタイプ 8 と 9 ではマスクが全ゼロ)、タイプを 0 に設定しなければならない (MUST)。
例えば、ホップ 10 にある LSR X が、問題の FEC に対して 2 つのダウンストリーム LSR Y と Z を持つとする。受信側の X はマルチパスタイプ 4 を返し、ダウンストリーム LSR Y には低位/高位 IP アドレス 127.1.1.1->127.1.1.255 を、ダウンストリーム LSR Z には 127.2.1.1->127.2.1.255 を与えることができる。ヘッドエンドはこの情報を LSR Y に反映する。3 つのダウンストリーム LSR U、V、W を持つ Y は、127.1.1.1->127.1.1.127 は U へ、127.1.1.128->127.1.1.255 は V へ行くと計算する。すると Y は 3 つのダウンストリームマッピングで応答する。U へはマルチパスタイプ 4 (127.1.1.1->127.1.1.127)、V へはマルチパスタイプ 4 (127.1.1.127->127.1.1.255)、W へはマルチパスタイプ 0 である。
マルチパス情報の計算は受信側に大きな処理負荷を課す可能性があることに注意する。したがって受信側は、受信したプレフィックスの一部のみを処理することを選択してもよい (MAY)。送信側は、部分的な情報を含むダウンストリームマッピングへの応答を受け取った場合、応答で欠落しているプレフィックスは受信側がスキップしたものと想定すべきであり (SHOULD)、それらに関する情報を新しい echo request で再要求してもよい (MAY)。
3.3.2. ダウンストリームルータとインタフェース (Downstream Router and Interface)
「ダウンストリームルータ」および「ダウンストリームインタフェース」という概念を説明する。LSR X を考える。TTL n>1 で生成され、最外ラベル L および TTL=1 で LSR X に到着したパケットがあった場合、X は、そのパケットが TTL=n+1 で生成されたならばどの LSR がそれを受信しうるか、要求がどのインタフェース経由で到着するか、それらの LSR がどのラベルスタックを見るかを計算できなければならない。(この計算をどのように行うかは本文書の範囲外である。) これらの LSR/インタフェースの集合が、L に関する X のダウンストリームルータ/インタフェース (およびそれに対応するラベル) である。ダウンストリームルータとインタフェースの各組について、応答に別個のダウンストリームマッピングを追加する必要がある。
X が echo request を生成する LSR である場合は特殊なケースである。X は、自身が TTL=1 で生成する特定の FEC スタックについて、どの LSR が MPLS echo request を受信するかを把握する必要がある。
X におけるダウンストリームルータの集合は、代替パス (後述の ECMP に関する議論を参照) であっても、同時パス (例えば MPLS マルチキャスト) であってもよい。前者の場合、マルチパス情報は、これらの代替の選択にどのように影響しうるかについてのヒントとして送信側に提供される。
3.4. パッド TLV (Pad TLV)
Pad TLV の値部分は可変個 (>= 1) のオクテットを含む。先頭のオクテットは以下の表の値を取り、それ以外のオクテット (もしあれば) は無視される。受信側は、この TLV が全体として受信されたことを検証すべきであるが (SHOULD)、それ以外は先頭オクテットを除いてこの TLV の内容を無視する。
| 値 | 意味 |
|---|---|
| 1 | Drop Pad TLV from reply (応答から Pad TLV を破棄する) |
| 2 | Copy Pad TLV to reply (Pad TLV を応答へコピーする) |
| 3-255 | 将来の使用のために予約 |
3.5. ベンダー企業番号 (Vendor Enterprise Number)
SMI プライベート企業番号 (SMI Private Enterprise Numbers) は IANA が管理している。Length は常に 4 であり、値はメッセージの固定部分のいずれかのフィールドにベンダープライベート拡張を持つベンダーの SMI プライベート企業コード (ネットワークバイトオーダ) である。この場合はこの TLV が存在しなければならない (MUST)。メッセージの固定部分のどのフィールドにもベンダープライベート拡張がない場合、この TLV を含めることは任意である (OPTIONAL)。メッセージタイプ、応答モード、リターンコードに対してベンダープライベートの範囲が定義されている。これらのいずれかを使用する場合、ベンダー企業番号 TLV をメッセージに含めなければならない (MUST)。
3.6. インタフェースとラベルスタック (Interface and Label Stack)
Interface and Label Stack TLV は、要求メッセージを受信したインタフェースと、受信時にパケットに付いていたラベルスタックを報告するために、応答メッセージに含めることができる (MAY)。このようなオブジェクトは 1 つだけ出現できる。このオブジェクトの目的は、アップストリームルータが、応答 LSR において実際に現れるとおりの正確なインタフェースおよびラベルスタック情報を取得できるようにすることである。
Length は K + 4*N オクテットであり、N はラベルスタック内のラベル数である。K の値は後述のアドレスタイプ (Address Type) の説明にある。ダウンストリームマッピングの 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Label Stack .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
アドレスタイプ (Address Type)
アドレスタイプは、インタフェースが番号付きか非番号かを示す。また、IP Address フィールドおよび Interface フィールドの長さを決定する。TLV の先頭部分の合計は、以下の表に "K Octets" として示す。アドレスタイプは以下のいずれかの値に設定する。
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
IP Address と Interface
IPv4 アドレスとインタフェースインデックスは 4 オクテットで、IPv6 アドレスは 16 オクテットで符号化される。
echo request メッセージを受信したインタフェースが番号付きである場合、アドレスタイプを IPv4 または IPv6 に設定しなければならず (MUST)、IP Address はその LSR の Router ID またはインタフェースアドレスのいずれかに設定しなければならず (MUST)、Interface はそのインタフェースアドレスに設定しなければならない (MUST)。
インタフェースが非番号である場合、アドレスタイプは IPv4 Unnumbered または IPv6 Unnumbered のいずれかでなければならず (MUST)、IP Address はその LSR の Router ID でなければならず (MUST)、Interface はそのインタフェースに割り当てられたインデックスに設定しなければならない (MUST)。
ラベルスタック (Label Stack)
受信した echo request メッセージのラベルスタック。このルータによっていずれかの TTL 値が変更されている場合は、それらを復元すべきである (SHOULD)。
3.7. エラーとなった TLV (Errored TLVs)
以下の TLV は echo reply に含めることのできる (MAY) TLV であり、echo request の送信側に対して、実装がサポートしていないか、または解析の結果エラーと判明した必須 (mandatory) TLV を通知する。
Value フィールドは、理解されなかった TLV をサブ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. 応答 TOS バイト TLV (Reply TOS Byte TLV)
この TLV は、echo request の起動側が、IP ヘッダの TOS バイトをこの TLV で指定した値に設定して echo reply を送信するよう要求するために使用してもよい (MAY)。この TLV の長さは 4 で、以下の値フィールドを持つ。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+