要約

  • Plutarchは既存のインターネットを廃止する提案ではない。世界規模のIPv4網を変更せず、一つのcontextとして他の仕組みと段階的に共存させる構想だった。
  • 名前や通信規則はcontextの内側で意味を持つ。別のcontextへ渡すinterstitial functionは、アドレスだけでなく、名前、経路、転送動作を再結合する制御点になる。
  • 論文は研究の出発点であり、セキュリティ、監査、権限管理、発見の拡張性、障害通知、context chainの選択方針を完成させたものではない。

「世界で一つ」を前提にしない名前

小さなセンサー群の中で、番号17が一台の機器を示しているとする。IPv4側の端末にとって、17は経路選択可能な世界共通アドレスではない。それでも、両者の間に対応関係を作れば通信はできる。

Plutarchが重視したのは、17を無理に世界共通の名前だと見なすことではなく、どの範囲で何を示す名前なのかを明らかにすることだった。contextは、ある観点で同質なネットワーク領域であり、名前のbindingを解決できる範囲でもある。その観点はアドレス形式、パケット、転送プロトコル、命名サービス、リンク、管理領域のいずれでもよい。

端末は複数のcontextに同時参加できる。メンバーは出入りし、contextは入れ子にもなる。ローカルEthernetがIP LANに含まれ、それがインターネットに含まれる場合だ。全体を意味づける唯一のroot contextは置かれない。

したがって、境界を越える名前には再bindingが必要になる。文字列が保存されても、指示対象が保存された証拠にはならない。

インターネットの成功を否定せず、中心性だけを外す

論文はIPの均質性がもたらした価値を率直に認める。強く定義されたプロトコル群、単純なデータグラム、ネットワーク内部に置く機能の節度は、アプリケーションと下位技術の独立した発展を支えた。

問題は、成功したモデルが将来の唯一の物差しになったことだった。センサー、無線アドホック網、モバイル網、中間装置を含む現実を、すべて一つの意味論へ押し込むと、内部の能力や制約が見えなくなる。

Plutarchでは、世界規模のIPv4インターネットもcontextになる。その内部は変えなくてよい。別のcontextはoverlayとして上に、別プロトコルとして隣に、私設リンクとして下に、あるいは境界に配置できる。インターネットを通過路に使っても、ローカルな名前や経路の規則を捨てる必要はない。

これはIPを弱くする主張ではない。非IPを周辺の例外と呼ばないための整理だった。

interstitial functionは変換内容を背負う

二つのcontextをつなぐ仕組みがinterstitial function、IFである。IFは両側に対応するインターフェースを持ち、一方のデータや機能を他方へ写す。複数のIFを並べればcontext chainになる。

著者らは既存例としてNAT、シグナリングゲートウェイ、BGPルーターを挙げた。さらに異種transportの橋渡し、映像のtranscoding、誤り訂正の付加まで想定した。ここまで含めれば、IFが単なる中継でないことは明らかだ。

アドレス変換は対応表を持つ。命名変換は複数の名前空間を接続する。routing変換は、オンデマンド無線網とOSPF/BGP領域で異なる変動の意味を調整する。transport変換は、そのネットワークに適した最適化をどこで適用するか決める。

変換の証拠には、入力と出力、同一性を主張する規則、設定権限、保持状態、失われた性質が要る。疎通確認は、そのうち「出力があった」しか示さない。

chainを隠す自由と、chainを選ぶ自由

Plutarchは、複数のcontextとIFをまとめたchain自体を一つのcontextとして扱える。GPRSにつながった端末がインターネットを経由して遠隔センサーへ到達する場合、アプリケーションは途中の全技術を理解しなくてもよい。

ただし、必要な端末は複数のchain候補と性質を受け取り、自ら選べる。アプリケーション固有の最適化を、ネットワーク中央だけの判断にしない設計である。

二つの自由は緊張する。詳細を隠せば利用は簡単になるが、障害修復で別の管理者のchainへ移ったことや、proxyがtransportを分割したことが見えにくくなる。選択肢を増やしても、発見サービスが順位を固定すれば実質的な選択は狭い。

論文は、複数の管理主体による分散サービスと、要求に添えるcapabilityを想定した。しかしcapabilityの管理方法は定義していない。rootが一つでなくても、権限発行が新しい根になる可能性は残る。

段階導入は「全員同時」を避ける仕掛けだった

Plutarchには、IPv4インターネットを変更せずに済むことと、新contextを少数から導入できることという二つの実務上の利点があった。既存網が先に置き換わるのを待たず、局所的な実装とIFから始められる。

この順序は採用の政治を変える。新しいpacket formatについて世界規模の同意を先に得る必要がない。利用者は動く実装を見て参加でき、合わなければcontextから離れられる。

一方、暫定IFへの依存が積み上がれば退出は難しくなる。対応表、障害処理、アプリケーション例外が一つの実装に固着すると、局所導入の橋が広域のlock-inになる。

段階導入が可逆的であるためには、contextだけでなく翻訳状態も移せなければならない。

未解決項目は脚注ではなかった

論文は対象外を明記した。resource allocation、timeliness、保証、security、auditを解いたわけではない。提示されたAPIはstrawmanで、性能値はない。capability管理も規定されていない。

context間routing、IF discovery、failure notification、chain選択のpolicy、programmer API、transport adaptation、name lookupの拡張性は将来課題だった。contextの種類は十程度、chainは短いだろうという見込みも、実運用データではない。

この境界を守れば、Plutarchの意義は小さくならない。異種性を隠さず構成する語彙を与え、何が未証明かも同じ設計図に残した。それは完成品を装うより厳密な貢献である。

五人の論文として読む

Cambridgeは現在、Jon Crowcroftを通信システムのMarconi Professorと紹介し、40年以上にわたるインターネット関連研究を記している。ネットワークと分散システムをまたぐ経歴は、Plutarchの問題設定とよく重なる。

ただし論文の著者はCrowcroft、Hand、Mortier、Roscoe、Warfieldの五人である。context-relative naming、late binding、end-to-end argument、同時代のfuture Internet研究も背景にある。後世のgatewayをすべてPlutarchの子孫とすることも、Crowcroft一人の発明とすることもできない。

残ったのは、境界を消さずに相互運用するという問いだ。異なる世界をつなぐなら、違いを誰がどう処理したかを示さなければならない。

出典