要約

  • RFC 3037 は、宛先ベースの通常経路で MPLS 転送を行う装置に LDP 実装を推奨したが、すべての MPLS 装置への義務や導入実績を示したわけではない。
  • 基本 LDP の逐次転送と明示経路のトラフィックエンジニアリングを区別し、発見から実パケットまでを一つの成功状態にまとめなかった。

「推奨される」は、過去を振り返ると「広く動いていた」に化けやすい。しかし規格が適切な機能を選ぶことと、現場でその機能が使われたことは別である。2001 年 1 月の Informational RFC である RFC 3037 は、LDP の居場所を示したのであって、配備地図を描いたのではなかった。

文書が推奨したのは、宛先ルーティングに従う通常の MPLS 転送である。そこから先の実装、起動、ピア関係、転送結果は、規格作者ではなく製品と運用とパケットが答える領域だった。

基本 LDP は通常ルートの上に意味を置いた

隣接する Label Switching Router は、やり取りするラベルの意味を共有しなければならない。LDP は、一方の LSR が作った FEC とラベルの対応を他方に伝える。RFC 3037 の中心は、宛先ベースのルーティングが選んだ次ホップに沿う、MPLS の hop-by-hop forwarding だった。

独立した LDP には異種装置をつなぐ利点があった。IP ルーティング面と ATM または Frame Relay の cross-connect 表を書き込むソフトウェアを組み合わせれば、専用のオーバーレイやアドレス・ルーティング方式なしに IP を運べる。また全ホップに同じラベル情報付きルーティングプロトコルを要求しない。

だが、構成可能性は構築済みという意味ではない。表を書けるソフトウェア、確立したセッション、形成された LSP、実際のトラフィックは、それぞれ別に観測する必要がある。

明示経路は基本 LDP の外から始まった

トラフィックエンジニアリングの明示 LSP は、通常のルーティング経路から外れ得る。RFC 3037 はその設定方法として CR-LDP と RSVP-TE の拡張を挙げ、当時は技術的優劣の合意がないと記録した。管理者は自らの必要と状況に応じて選ぶとされた。

拡張点があるだけで、拡張機能が存在するわけではない。新しい message や TLV を識別し、未知要素を処理する手順は進化の土台になる。しかし個別機能には仕様、両端の実装、設定、合意がなお必要である。

2003 年の RFC 3468 は後の判断を記録した。MPLS Working Group と IESG は新しい作業を RSVP-TE に集中し、CR-LDP の新規 WG 作業を行わないとした。一方で既存 RFC の状態は維持し、個人提案も禁止しなかった。これは標準化労力の配分を変えた証拠であり、2001 年の記述を遡って誤りにしたり、全運用網の即時移行を証明したりしない。

推奨文には対象条件があった

RFC 3037 は、MPLS に関係する全装置へ LDP を義務付けなかった。推奨対象は、通常の宛先経路に沿って MPLS を転送する装置である。機能条件を外すと、要求レベルの意味が変わってしまう。

実装済みでも、プロセスは無効かもしれない。有効でもピアを発見しないかもしれない。発見できても TCP が成立せず、成立してもパラメータに合意できず、運用セッションになっても必要な対応を受けず、対応を受けても転送表に入らず、表に入ってもパケットが来ないことがある。

推奨が証明できるのは、規格上その能力を用意する価値があるという判断までである。後続状態を一括して「対応」と呼べば、証拠の主体が失われる。

TCP の信頼性はサービス全体へ伝播しなかった

手順には順番がある。Discovery が候補ピアを見つけ、session setup が TCP 接続を作り、双方が label distribution method などを交渉する。合意後に初めてセッションが operational となり、ラベル配布に使われる。

TCP の信頼性によって、セッションメッセージは確実に運ばれ、対応情報を周期的に refresh しなくてもよくなった。保証対象はストリームである。相手が意味を受理したこと、経路依存が最新であること、ハードウェアに書かれたこと、パケットが届いたことまでは含まない。

周期更新がないからこそ、時系列を保存すべきでもあった。現在残る対応表だけでは、古いセッションや経路に由来する状態か判断できない。

モードの組合せには資源観が埋め込まれた

Downstream Unsolicited は、FEC を転送できると判断した LSR が自発的に対応を広告する。Downstream on Demand は要求を待つ。Liberal retention はすべての学習ラベルを保存し、conservative retention は即時に必要なものだけを残す。Independent control は局所判断で広告し、ordered control は FEC の次ホップからラベルを受けるか、自らが出口になるまで待つ。

ATM や Frame Relay のようにラベル値が乏しい場面では、on-demand・conservative・ordered の組合せが適切とされた。ラベルが豊富なら、unsolicited・liberal・independent は次ホップ変更に備えた対応を保持できる。

「適切」は前提付きである。別の組合せや hybrid も許されていた。節約は予備状態を減らし、保持は資源を消費する。早い広告は待ち時間を減らす一方、下流完成より先に上流の主張を作る。最適性には現場の測定が要る。

実装必須でも利用は無効にできた

Loop Detection は能力と運用の違いを明文化した。非 TTL MPLS cloud を通る LSP を保護する仕組みを、準拠 LSR は実装しなければならない。しかし設定で無効にできた。

製品が対応していることと、ドメインが保護されていることは別である。一台の有効化だけでも足りない。関連する全 LSR の設定、伝達属性、ルート、実転送を結び付ける必要がある。

任意の TCP MD5 も範囲が限定された。LDP セッションのストリームへ偽造セグメントを差し込む危険を抑えるためであり、FEC の正当性、経路の権限、対応内容の真実、利用者サービスの安全を保証しない。

スケールの説明は製品の限界値ではなかった

増分配布は周期 refresh を不要にする。保守的な方法は希少ラベルを節約し、liberal retention は次ホップ変更時の再配布を減らす。反面、装置が支えられる TCP 接続数はピア数を制限し、path vector によるループ検出はメモリ、処理、LDP トラフィックを増やす。

これは因果関係であってベンチマーク値ではない。実容量にはピア数、ラベル消費、CPU、メモリ、メッセージ量、収束、パケットの観測が必要である。

RFC 3037 を配備証明に膨らませなければ、文書は今も明快である。規格は用途を推奨する。コードは能力を持つ。設定は有効にする。プロトコルは合意する。表は実行し、パケットが利用を示す。それぞれの動詞には別の所有者がいる。

出典

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