要約
- RFC 2103はモビリティを、端点のlocator変化とnetwork topologyの変化という独立した二つの結果に分けた。片方だけが起こる場合もある。
- topologyが安定していればDynamic Association Moduleは端点–locator対応を更新できる。network全体が移動すればmapとrouterも関与し、bindingだけでは到達性を説明できない。
RFC 2103の四分類で最も重要なのは、一見すると矛盾した欄である。ロケータは変わらない。だがトポロジーは変わる。
あるnetwork nodeが同じ上位Nimrod nodeの内部にとどまりながら、隣接nodeだけを変えたとする。配下のendpointは同じlocatorを保持できる。問い合わせ結果は最新で正しい。それでも領域へ入るpacketには、新しいconnectivityの記述が必要だ。対応関係は正しく、古いmapから得たrouteは誤り得る。
きれいな抽象が届かない場所
RFC 1992は、topologyに意味を持たないEndpoint Identifierと、階層map内の位置を示すlocatorを分けた。providerを変えた組織はlocatorも変えなければならない。古いprefixを別の領域へ持ち込めば、階層routingは平板化するからである。
RFC 2103はこの分離をモビリティのモデルにした。Dynamic Association Module、略してDAMは、endpointとlocatorの可変な対応を維持する。DAMは必須serverでもDNSの別名でもなく、方式を比較するための抽象である。機能はdatabase、home representative、分散router stateのいずれにも置き得た。
文書は四つのscenarioを区別した。locatorもtopologyも変わらない。locatorだけが変わる。topologyだけが変わる。両方が変わる。「新しいlocatorへbindingを張り直す」という分かりやすい説明が完結するのは二番目だけだ。三番目ではDAMに更新対象がないのに、Nimrodのmapは更新を要する。四番目では両方が動く。
network mobilityが抽象の継ぎ目を見せた
例は、移転する組織や、列車・航空機・自動車・船舶に載ったwireless networkだった。nodeが隣接関係を変えればgraphが変わる。上位nodeの外へ移れば、配下deviceのlocatorも変わり得る。
RFC 2103は、通常のNimrod topology updateが比較的遅い変化向けに最適化されている可能性を指摘した。高速に移動するnetworkでは、node representativeへ専用updateを送り、流入packetを新しいtopologyでrouteする仕組みが必要かもしれない。具体的な相互作用は未規定である。記されたのは、network mobilityではendpoint mobilityよりDAMとrouting/routerの結合が強くなり得るという設計上の帰結だった。
したがって、最新のassociationが証明するのは、今どのlocatorがendpointに結び付くかだけである。現在の隣接、mapの配布、route再計算、forwarding stateの有効性までは証明しない。
stateを置く三つの場所
中央databaseをsourceが照会する方式は単純でdirect routeを得られる。しかし単一障害点を作り、長期的なscaleには足りないと評価された。
分散してassociationを維持し、homeでremappingする方式はMobile IP型である。sourceはhomeへ送り続け、代表が現在位置へ転送する。sourceや通常routerを変更せず、control trafficをある程度閉じ込め、位置を隠せる。一方でtriangular routing、home representativeへの依存、将来のscaleという問題を抱える。RFC 2103が「実用的なfirst cut」と呼んだのは、完成の宣言ではない。
三番目はrouterにstateを持たせる。複雑で関与するNimrod entityも増えるが、topologyが変わるscenarioには適していた。移動に近い場所で反応するため、DAMが切り離そうとしたrouting componentをあえて参加させる方式である。
Mobile IPは仕組みであって結果ではない
RFC 2002の適用は、discovery、registration、forwardingから成る。mobile hostはforeign agentまたは一時locatorをhome agentへ登録する。home agentはbindingをcacheし、packetを捕捉してencapsulateし、foreign agentへ送る。foreign agentはさらにdecapsulateし、visitor listを照合し、配送しなければならない。
registrationが認められても後段は失敗し得る。cacheされたlocatorは古くなり得る。visitor listにendpointがなければ、packetは破棄されerrorが返る。遠回りのpathは動作してもoptimalとは限らない。requestのauthenticationも、訪問先networkへ参加するauthorizationとは別である。
文書は、移動中にsessionを切るoffline mobilityと、sessionを保つonline mobilityも分けた。後者を望ましいとしながら、first cutが特定のtransport sessionを維持した証拠は示していない。scaleも未計測で、応答時間をoとする追跡系はattachmentが1/oより速く変われば追随できない、とだけ述べる。実運用でのoはない。
文書が止まったところ
RFC Editorの記録とIETF Datatrackerは、RFC 2103を1997年2月のInformational文書として残す。本文はprotocol specificationではないと明記し、deregistration、authentication詳細、高速topology update、predictive routing、DAMとrouterの相互作用を未解決のままにした。
その未完成さに歴史的意味がある。Nimrodはidentity、location、routingを別々の層へ置こうとした。RFC 2103は、その層が一致しなくなる地点を示した。endpointの移動は新しいassociationで表せる。networkの移動は、そのassociationを役立てるgraphそのものを変える。
Lu HengのRunning-Code Primacy、Minimum Initial Specification、Reality Layersは、歴史資料ではなく明示した現代的分析枠である。文書がinterfaceを示しても、実装がstateを更新し、routerが受け入れ、pathが観測されるまで運用上の現実にはならない。
結論は狭く保つべきだ。現在のbindingが証明するのは現在のbindingである。モビリティの成功を主張するには、topology revision、update propagation、route decision、forwarding、authorization、session、deliveryを別々に残さなければならない。
情報源
- RFC Editor — RFC 2103記録
- RFC 2103 — Mobility Support for Nimrod
- IETF Datatracker — RFC 2103
- RFC 1992 — The Nimrod Routing Architecture
- RFC 2102 — Multicast Support for Nimrod
- RFC 2002 — IP Mobility Support
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Lu Heng — On Reality Layers
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
