要約

  • RFC 1070はOSIネットワーク層のPDU全体をIPデータグラムに入れ、既存のIPゲートウェイを変更せずに、複数拠点でOSIルーティングを試す環境を提案した。Internetは下位のサブネットとして使われた。
  • EONの論理的な1ホップ関係は、IP到達性から自動的には生まれない。NSAP、core.EON、SNAcPキャッシュ、ES/IS設定、構成交換は別々の事実を表し、古い初期リストと現在の役割が食い違うこともあった。

RFC 1070 は、提案の適用範囲を冒頭で限定している。方法は小規模な実験だけに適し、運用環境には適さない。OSIネットワーク層の標準化と実装はまだ途上にあり、動的で複雑な構成に置いた試験が必要だった。しかし未成熟な処理を多数のInternetゲートウェイに追加すれば、試験対象の不具合が既存通信を巻き込む。

そこで、ゲートウェイには手を加えない。ローカルなリンクではOSIを直接動かし、IPゲートウェイの向こうへ行くときだけ、OSIのPDU全体をIPに包む。文書はこの既存の輸送面をIP subnetと呼び、その上に作るExperimental OSI-based NetworkをEONと名づけた。

プロトコル番号80が与えたのは輸送路だった

直接IPを使うEONでは、CLNP、ES-IS、IS-ISなどのISO-gramを IP のデータ部へ置き、Protocolフィールドに80を設定した。OSI CLNL自体の分割機能を試すため、上位での分割を優先する。ただし途中のIP分割は避けられないので、宛先は下位でも再構成できなければならない。

ここで観測できる段階は一つではない。IP断片の到着、IP再構成、OSI PDUの処理、役割に応じた受理、経路の学習は、それぞれ別の出来事である。RFC 1070も、参加拠点の多くの機械がIPで到達可能でも、EONのIP subnetへ直接接続したものとして設定されるのは一部だと想定した。

宛先を導くためのNSAP形式は RFC 1069 に基づき、終端近くの4オクテットへInternetアドレスを埋め込んだ。その次がNSAP selectorで、routing domain numberはIANAが割り当てる。当初のlocal areaはゼロとされた。これによりNSAPからSNPAとしてのIPアドレスを計算できる。

しかし計算できるのは下位の送信先だけである。そこにいるシステムがOSIのend system、intermediate system、または両方のどれかは、設定とプロトコル動作が示す。物理的なInternet接続を変えずに役割や論理関係を変えられることこそ、動的ルーティングを試すための条件だった。

提案は、IPのルーティング方式でISO-gramを参加者間に転送すること、巨大な本番環境を作ること、IPとCLNPの相互ゲートウェイを提供することを目的から外した。既存InternetはOSIネットワークへ改名されたのではない。OSI側が自分のアドレスとルーティングを保持したまま利用するリンクだった。

SNAcPは全員宛てを1台ずつ複製した

ES-ISとIS-ISは、broadcast subnetに「すべてのES」「すべてのIS」という宛先があることを前提にする。IP subnetは、その意味をEONへそのまま渡さない。RFC 1070はOSI CLNLとIPの間にSubNetwork Access Protocol、SNAcPを設けた。

各SNAcPは、自分からISO 8473の1ホップで届くとみなすcore systemのInternetアドレスをキャッシュする。単一宛先なら1個、all ES、all IS、broadcastならキャッシュ内のSNPAごとにISO-gramを複製する。先頭にはversion、宛先意味、Fletcher checksumを持つ短いヘッダーが付く。

受信側は、個別宛てとbroadcastを受け入れる。一方、all ESとall ISは自分の現在の役割設定に合う場合だけ受け入れる。したがって送信範囲は送信者のキャッシュ、受理範囲は受信者の設定で決まる。IP上の同じ到達性を共有していても、参加者全員が同じ論理サブネット像を持つ保証はない。

ICMP のエラーも、そのままOSIの結論になるわけではない。destination unreachable、parameter problem、time exceededに対して、SNAcPは該当キャッシュを使用不能にすることが提案された。source quenchなら一時的な無効化である。管理への通知はコンソール、ログ、カウンター、ローカルプロセス、さらには何もしない場合まで許された。下位の観測から上位の隣接状態を作るのはローカルポリシーだった。

起動に使う一覧と、人が見る一覧は異なった

起動直後のシステムは、経路交換の相手をまだ学んでいない。IANAが維持する core.EON と core.EON-UDP は、各実験で論理的に1ホップと扱うSNPAの初期集合を与える。一方、hosts.EON と hosts.EON-UDP は、アプリケーションや利用者向けに参加end systemの名前を並べるだけで、OSI CLNLは使用しない。

coreという語も役割を確定しない。core.EON の項目はESでもISでも、その両方でもよい。新しいcore systemは一覧へ反映される前から動作できるが、古いファイルで起動した他システムは、その相手へESHやISHを送ることを知らない。ファイルは初期接触の種であって、現在の役割台帳ではなかった。

文書の仮想的なFordor拠点では、この遅れだけでトポロジーが変わる。192.5.2.1 は当初ISかつcore system、192.5.2.2 はESである。両者が役割を交換しても、Internet上の物理接続はそのまま残る。ところがIANAの一覧が古ければ、他のcore systemsは引き続き .1 へ構成メッセージを送り、そこからESとしての応答を受ける。新しいIS .2 へは最初の問い合わせが届かないため、EON上では到達不能に見える。

.2 自身が起動してOSIの構成交換を送ると、他のISは応答してキャッシュを更新する。そこで新しい論理リンクが成立する。回復したのはIPの経路ではない。初期リストでは表現できなかった現在の役割を、動的な交換が補ったのである。

UDP版は同じ参加者の別入口ではなかった

実装によってはIP層を直接扱えず、UDP だけ利用できた。EON-UDPはOSI NPDUをポート147で送り、UDPとISO 8473の間にSNAcPを置く。その他の仕組みは似ていても、RFC 1070は直接の相互運用がないと明記した。両者をつなぐゲートウェイは考えられるが、その構築とルーティングは対象外である。別のcore/hostsファイルが必要なのも、二つが並行した実験だったからだ。

近接するRFCとの違いも層にある。RFC 1006 はTCP上にOSI transport serviceを提供し、session以上を動かした。RFC 1070はOSIのnetworkとtransportをIP internetworkで運ぶ。RFC 1069はInternetのアドレスとルーティングを使うCLNP gatewayを扱うのに対し、RFC 1070はOSIのアドレスとルーティングを試した。

情報源と限界

RFC 1070は実験シナリオと合意案を記録した文書である。EONの大規模導入、本番利用、後世の特定overlayへの直系関係は示していない。Fordorは障害記録ではなく仮想例である。RFC 994 と RFC 995 は当時のCLNPとES-ISの仕様を示すが、個々のEON実装の正しさまでは証明しない。

残る教訓は、下位ネットワークが上位ネットワークのリンクになっても、そのメンバーシップを所有しないという点にある。アドレス、初期一覧、キャッシュ、役割、学習済み経路には、それぞれ別の根拠が必要だった。