要約

  • RFC 3034 は、DLCI を交換しても MPLS TTL を減らさない Frame Relay LSR の連なりを「非 TTL セグメント」とし、コアで行えないホップ計上を境界に負わせた。
  • LDP の Hop Count はユニキャスト入口の一括控除に使えたが、それは制御面が組み立てた主張であり、パケット経路の観測記録でも到達証明でもなかった。

古いスイッチが不得手だったのは転送ではない。入力 DLCI を表で引き、出力 DLCI に書き換え、次の回線へ流す仕事はこなせた。できなかったのは、ルーターなら各パケットで行う TTL の減算だった。こうした装置を MPLS の Label Switching Router として使うと、局所的な交換の成功と、経路全体の寿命管理との間に穴が開く。

2001 年 1 月に Proposed Standard として公開された RFC 3034 は、ハードウェアに存在しない命令を仮定しなかった。減算しない装置列を非 TTL セグメントと定義し、その区間分の負担を境界でまとめて処理した。

交換に使う値は DLCI に置かれた

Frame Relay リンクでは、現在の MPLS ラベル値を Frame Relay ヘッダーの DLCI が担った。追加ラベルと、TTL を含む現在のスタック項目の残りは、汎用 MPLS カプセル化に残る。コアの FR-LSR は DLCI を検索し、出力 DLCI へ置き換えてフレームを送った。

一つの論理スタックが二つの場所に表現されたことになる。リンク層の DLCI が実際の交換を決め、スタック上の他のフィールドは引き続き意味を持つ。別のカプセル化へ渡る境界では、LSR が論理スタックを読み解き、操作し、次のリンク向けに符号化し直す。同じ LSP でも、隣接リンクの見た目は同一とは限らない。

出口で最後のラベルを外す場合、スタックには後続のネットワーク層プロトコルを直接示す欄がない。ラベル対応から推定する必要があった。この対応は限定された解析・転送規則を与えるが、送信者の身元、経路の認可、想定回線の通過、配送完了までは保証しない。

数えない装置も経路から消えるわけではない

TTL はループを止めるだけでなく、パケットの到達範囲を制限する。5 台の Frame Relay スイッチを常に 0 ホップとして扱えば、同等の 5 台のルーターを通る場合より寿命が余る。DLCI 交換が各点で正しくても、この性質は守れない。

RFC 3034 は 出力 TTL = 入力 TTL - d と表し、d を入力・転送・出力の各カプセル化から決めた。同じレベルの Frame Relay コア交換では、区間分を別の場所で払うため 0 となる。通常の汎用 MPLS 転送なら概ね 1、非 TTL セグメントへ入る境界なら伝達された区間ホップ数をまとめて使える。

ユニキャストでは意味のある区間長を入口へ伝え、投入前に差し引いた。マルチキャストでは長さを出口へ送り、そこで境界処理を行った。課金場所は転送形態で変わるが、ハードウェア上の不可視性を経路上の不存在にしない点は共通している。

寿命が足りなければ入口で止める

先払いによって、最初の DLCI 交換より前に拒否できる。区間長を引くとユニキャストの TTL が出口前に尽きると判断した場合、入口 FR-LSR はラベル付きパケットを非 TTL セグメントへ投入してはならない。

その代わり、ラベルスタックの規則に従って ICMP エラーの返送を試みるか、IP 転送に対応した TTL でラベルなし転送を行う。入力 TTL が 1 なら、選べるのはエラー処理だけである。

ただし「試みる」は到達を意味しない。ICMP を生成しても送信元が受信したとは限らず、ラベルを外して渡しても宛先まで届いたとは限らない。入口で得られる証拠は、ある入力値と区間長から特定の判断をしたという範囲にとどまる。

Hop Count は測定値ではなく配布状態だった

LDP はラベル対応に Hop Count オブジェクトを付け、TTL 計算の区間長を供給できた。下流から既知の値を受けた FR-LSR は 1 を加えて上流へ送る。不明は不明のまま扱う。増分後に上限を超えるなら対応を上流へ渡さず、エラーを通知する。

Ordered control では下流対応を待ってから上流へ応答するため、増分済みの値を同時に返せる。Independent control では下流が完成する前に「不明」として対応を配り、後から正しい値を更新できる。LDP が値を供給しない、または不明とする場合、RFC 3034 の計算は既定値 1 を用いる。

既定値 1 は一ホップを観測した結果ではない。情報不足時の動作を決めただけである。既知の値も、経路選択と配布メッセージから作られた制御面情報にすぎない。全スイッチの稼働、特定パケットの通過、出口での受信を証明するものではない。

経路が変われば古い計算も権威を失う

上流に対応が配られた後でも、値は変わり得る。Independent control の不明値が既知になったり、ルーティングが別の次ホップを選んだりする。下流対応が既存の Hop Count を変えるなら、FR-LSR は新しい値を増分して入口方向へ伝えなければならない。上限を超える場合は、ループ検出を破綻した数字に任せず、該当 FEC のラベルを上流から撤回する。

障害も保存状態を無効にする。下流要求を満たせなければ、上流要求のために仮作成した対応を破棄して撤回を通知する。LDP セッションを失えば、その接続から学んだ対応を捨てる。Liberal retention で再利用できるのも、経路と Hop Count が RFC の条件に合う場合だけだった。

したがって、Label Information Base に一行残っていることは稼働経路の証拠ではない。由来となるセッション、下流依存、現経路に対応する値、更新の伝播まで確かめて初めて、その行の意味を評価できる。

制約への適応は証拠の層を統合しなかった

LSR になる Frame Relay スイッチは、ラベルの割り当てと維持を行い、ネットワーク層ルーティングにもピアとして参加する必要があった。一方、従来の Frame Relay 制御とラベル交換制御は、同じ装置・インターフェース上で独立に共存でき、共有は DLCI 空間の分割など限定的だった。組み合わせた装置の運用は RFC の範囲外である。

これは制御上の記号を実行結果に格上げする設計ではない。ルート、ラベル対応、Hop Count、入口の減算、実パケット、出口 TTL は別々の現実層に属する。RFC 3034 はコアができない処理を境界へ移した。その移動で、実経路まで制御面の数字に収まったわけではない。

出典

Lu Heng は RFC 3034 および関連標準の著者でも承認者でもない。本稿では、その論考を分析の枠組みとして明示的に用いた。