要約
- RFC 2102 は、動的なグループ、複数の状態作成者、競合する木の最適化目標があるため、経路生成とパケット転送の双方を Nimrod の中核仕様で一本化しなかった。
- 代わりに、共有木でも送信元木でも、作成された転送情報を各実装が同じ構造と意味で解釈できることを相互運用の条件とした。
- したがって一つの枝や FIB 行が示すのは局所的な複製関係だけで、現在の参加者、許可、網羅性、最短性、資源予約、配送成功までは示さない。
木の絵を消してみると、RFC 2102 の判断がよく見える。残るのは、ある flow-id に対する parent、child、target、そして Join と Prune の遷移である。どの算法が枝を選んだかより、隣の実装がその行をどう実行するかが相互運用の核心になった。
ユニキャストとマルチキャストはいずれも経路生成と転送を必要とする。Nimrod はユニキャストの転送モードを定めたが、経路生成は routing agent に残した。マルチキャストでは二つとも固定しなかった。グループは変動し、状態は送信者、受信者、中間ルーターのどこからでも作り得る。さらに総コスト、遅延、計算量、最適性は同時には最小化できない。
異なる木は異なる責任配置だった
DVMRP は reverse path forwarding により送信元を根とする木を作る。CBT は core を中心に受信者が共有木へ接続する。PIM は共有木と source-specific tree を併存させ、後者へ切り替えられる。MOSPF はリンク状態とメンバー情報から各ルーターが木を計算する。IDPR は送信元が policy route を作り、中間装置へ複製状態を設定する。
違うのは経路だけではない。誰がグループ情報を持つか、誰が計算費用を負担するか、誰が状態変更を始めるか、メンバー変化を誰が追うかが異なる。
相互運用は計算結果の形で成立する
RFC 2102 は、この多様性を無条件に許したわけではない。配送木はルーター内の forwarding information によって実行される。そこで状態構造と解釈をそろえれば、状態を作った方法が違っても同じ木に参加できる、と整理した。
Nimpim の例では、既存 flow に Join が来ると前のノードが child list に加わる。未登録 flow なら parent、child、target を設定し、要求を parent へ送る。Prune は child を除き、最後の child が消えた時だけ flow 状態を削除する。データは flow-id を持ち、forwarding agent はその状態に従って複製する。
このため、送信者が作った木へ、受信者が送信者の知らない場所から枝を継ぐことも可能になる。共有木から送信元木への移行も、グループ分布に応じた方式変更も排除されない。必要なのは、変更後の状態が同じ文法で読めることだった。
設置済みの枝は世界全体の証明ではない
child が一つあるからといって、受信者一覧が現在も正しいとは限らない。RFC 1112 の IGMP は直結リンクで受信意向を扱い、独自のタイマーと集約を持つ。転送行はその後段にある投影である。
また、政策許可も証明しない。RFC 2102 は宛先別制約によって一つのグループを複数の木に分ける場合を想定した。一本の枝から、全宛先の包含や transit 方針の有効性は読めない。
最短性も別である。CBT の共有木は遠回りし得る。PIM の reverse shortest path はメトリックの対称性に依存する。資源予約と QoS も独立した判断で、枝の存在は遅延、ジッター、共有可能性や予約成立を示さない。さらに送信、リンク通過、最終ホップ、アプリケーション消費は後続の証拠である。RFC 2102 は security considerations を論じてもいない。
歴史的価値は「何を共通化しないか」にある
RFC 1992 は複数の地図と転送モードを受け入れ、RFC 1753 は user state と service state を分けた。RFC 2102 はその分離をマルチキャストへ延ばし、実装境界を越えるために必要な最小限の実行意味だけを共通化した。
Lu Heng の Minimum Initial Specification は、後年この設計感覚を「共通層には相互運用の決定的規則だけを置く」と表現する。Running-Code Primacy は、文書を採用実績と混同しないための別の検査になる。両者は解釈上の平行であり、RFC 2102 が Nimrod の実運用を証明するわけではない。
RFC 2102 が残したのは一本の木ではなく、主張の境界だった。状態は実行できる。しかし、その一行から世界全体を推測してはならない。
出典
- RFC 2102: Multicast Support for Nimrod
- RFC 1992: The Nimrod Routing Architecture
- RFC 1753: Nimrod の IPng 技術要件
- RFC 1075: DVMRP
- RFC 1112: IP マルチキャストのホスト拡張
- RFC 1584: MOSPF
- RFC 2201: RSVP Applicability Statement
- Lu Heng, Running-Code Primacy
- Lu Heng, Minimum Initial Specification
- Lu Heng, On Reality Layers
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
