同じコンテキストラベルが二つあった。別の LAN なら衝突ではない

要約

Context label は同じ LAN 内で一意でなければならない。異なる LAN で同じ値が使われても、受信インターフェースが lookup context に含まれるため曖昧ではない。
Upstream-assigned label は context-specific table で解釈される。MPLS トンネルの外側ラベルが根を示す場合、PHP でそれを消してはならない。

RFC 5331 は context label と受信 LAN インターフェースを組み合わせて表を選ぶ。同じ数値が別インターフェースに存在しても衝突しない。

一方、同じ LAN 上の複数 LSR が同じ context label を使えば、下流ノードは上流隣接の空間を誤り得る。問題はグローバルな数値重複ではなく、同じ lookup key の範囲内での重複である。

在庫がインターフェースを落とすと、安全な再利用を違反として報告する。ローカル割当が LAN 全参加者を見なければ、危険な重複を見逃す。検査のキーは forwarding のキーと一致しなければならない。

仕様は手動プロビジョニングに加え、IPv4 のホスト部から context label を作る方法を示す。マスク条件、予約値回避、範囲制約があり、IPv6-only インターフェースには適用できない。

同じ LAN 上の二つの LSR が同じ低位 20 ビットを持てば、他ノードはパケットを誤配送する可能性が高い。アルゴリズムが決定的であることは、入力の一意性を証明しない。

生成記録には元アドレス、マスク、変換、予約値オフセット、LAN スコープと同時参加者集合が必要である。出来上がった番号だけでは前提を監査できない。

共有 LAN では専用 EtherType が upstream assignment を示せる。しかし、どの上流 LSR の空間かは示さない。

そこで最上位に context label、その下に upstream-assigned label を置く一ホップ MPLS トンネルを使う。受信側は最初のラベルと入口インターフェースで隣接表を選び、次の数値を解釈する。

EtherType だけを記録して「上流表で lookup 済み」と扱うのは一段飛ばしである。上流表は一つではない。

MPLS トンネルでは内側ラベルの上にあるラベルがトンネルと根を特定する。PHP が外側を出口前で削除すると、内側番号は残っても表選択が失われる。

RFC 5331 はこの場合 PHP を無効にする。最適化の可否は処理量ではなく、削除対象がまだ意味選択に使われるかで判断される。

受信後の番号から根を推測してはならない。同じ値は platform table や別 root の表で正当に別 FEC を表せる。

下流 LSR は tunnel head-end IP ごとに Upstream Neighbor Label Space を持つ。同じルータでも異なる head-end アドレスなら別空間である。

Label distribution が示す assigner IP は tunnel setup の root IP と同じでなければならない。別プロトコルの各レコードが有効でも、この join が違えば意味は一致しない。

GRE を単純なカプセル化で作る場合は送信元 IP が root となる。アドレスは単なる表示属性ではなく table selector へ入る。ただし認証・権限は別証拠である。

Upstream assignment は任意機能であり、下流が対応すると分かっていなければ使えない。知る方法は RFC 5331 の外にある。本体コード、設定項目、登録番号は peer ごとの知識ではない。

これらは規則、履歴、登録を示す。現在の実装、トンネル、PHP、根、表、衝突、誤配送、multicast、forwarding、配達は示さない。