要約

  • RFC 877はIPとX.25の接点に必要な共通規則として、プロトコル識別子、データグラム単位の完全なパケット列、交渉可能な設備を定めた。
  • 仮想回線はデータグラム到着時に開き、アイドル時の閉鎖時間は回線コストに応じて決まる。TCP接続ごとに回線を開く設計ではない。

分析

回線には回線の経済的な時計があった

1983年9月、J. T. KorbはRFC 877で、X.25ベースの公衆データ網を通じてIPデータグラムを運ぶ方法を定めた。冒頭には、CSNETとVAN Gatewayなどがこの標準を採用したとある。ここに示されているのは名指しされた採用例であり、すべてのネットワークの調査結果ではない。

接続すべきなのは異なる運用モデルだった。IPはデータグラムを送り、X.25は公衆データ網上の仮想回線を提供する。RFC 877は回線をアプリケーション会話に似せるのではなく、小さな共通インターフェースを定め、運用上の選択の一部を接続するサイトに残した。

1バイトでプロトコルを識別する

X.25の呼設定に含まれるCall User Dataフィールドの先頭1オクテットでネットワーク層プロトコルを識別し、0xCCをIPに割り当てた。その後のIPデータグラムはX.25の完全なパケット列として送られる。データグラムはパケット境界から始まり、複数パケットにまたがる場合はMoreビットが後続を示す。データパケット内に追加ヘッダーは付けない。

サイズも無制限ではなかった。より大きなX.25パケットサイズを交渉しない限り、IPデータグラムは最大576オクテット。RFCは、1,024オクテットを交渉例として挙げる。ウィンドウやパケットサイズなどの設備はサイト間で交渉でき、全ネットワークに同じ値を強制するものではなかった。

TCPの会話が回線を占有するわけではない

仮想回線は別の時間軸を持つ。RFC 877では、送信対象のデータグラムがインターフェースに届くと回線をオンデマンドで開き、一定時間アイドル状態が続けば閉じる。その時間は回線を開いたままにする費用に左右される。回線が足りなくなればインターフェースが閉じることもあり、どちらのサイトも回線を閉じられる。

TCPなどIPより上のプロトコルはこの規格に影響しない、とRFCは明記する。TCP接続ごとに対応するX.25回線を開くこともしない。長いTCP接続があっても、公衆データ網の回線がその接続専用に維持されるとは限らない。アダプターが管理するのはネットワーク資源であり、TCPの接続状態とは別だ。

確認できる影響は限定されている。データグラム送信中に回線が閉じるかリセットされれば、そのデータグラムは失われる。発生頻度やアプリケーションが最終的に観測した結果は、RFCには記録されていない。上位層の挙動をこの資料から推定することはできない。

推奨と全ホストでの導入は違う

1984年の公式プロトコル状況報告RFC 924は、「Internet Protocol on X.25 Networks」をRecommendedとし、仕様としてRFC 877を挙げた。同報告のRecommendedは、ホストに実装を推奨する区分で、全ホストへの導入完了を意味しない。1992年のRFC 1356は、RFC 877が記録した方式は広く使われていたと振り返り、曖昧さやデータグラム・パケットサイズ、回線管理、マルチプロトコル相互接続の要件が変化したため後継仕様に置き換えた。

この記録から分かるのは、採用例、公式の推奨、後年の改訂である。各拠点の一覧、通信料金、具体的なアイドル時間は示されていない。

後年のNote 64を解釈の手掛かりに

Heng LuのNote 64は、相互運用に必要な共通規則を最初に限定し、その先の選択をシステムの運用者に委ねる設計原則を述べている。編集上の視点として使うと、RFC 877の境界が見えやすい。0xCCとパケット境界は共有される。一方、アイドル時の閉鎖間隔や交渉可能な設備には世界共通の値を設けなかった。

これは後からの解釈である。RFC 877はNote 64を引用しておらず、Note 64はKorbの意図を示す証拠でもない。RFCが示す事実は、IPを公衆X.25サービスに載せながら、各回線の費用や寿命まで一律に定める必要はなかったという点だ。

出典