要約

  • RFC 1201はARCNETの重複フレームを再構成時に無視し、一つのデータグラムを最大120フレームに分けて運ぶ方式を定義した。
  • 60,480オクテットは形式上の上限であり、ネットワークの実用MTUは各機器が合意して設定する必要があった。

重複は必ずしも新しいデータではない

ARCNETでは、受信側がデータフレームを受け取っても、その確認応答が送信側へ届かないことがある。送信側が再送すれば、受信側には同じフレームがもう一度現れる。RFC 1201は、これをパケット全体の破棄理由にしないよう求めた。重複フラグメントを見分けて無視できなければ、再送のたびに正常な再構成が壊れてしまうからだ。

この細部は、固定長フレームを大きなIPパケットへ結び付ける仕様の中心にある。RFC 1051は1988年、IPとARPをARCNETに載せる前の形式を記録した。拡張フレームを扱えないホストがいる場合はIP MTUを253オクテットにし、IP層での分割を勧めていた。1991年のRFC 1201はこの方式を置き換え、分割と再構成をARCNETのリンク層に移した。

512オクテットのうち、データは504

ARCNETの長フレームは512オクテット、短フレームは256オクテットで固定される。ただし512オクテットすべてをIPに使えるわけではない。ハードウェアヘッダー、ソフトウェアヘッダー、固定長に合わせるパディングがあり、長フレームが運べるクライアントデータは最大504オクテットだった。250、251、252オクテットのデータには例外フレームが要る。物理媒体に固有の形が、そのままプロトコル設計を制約した。

分割フラグは、未分割のパケット、最初のフラグメント、後続のフラグメントを示す。同じパケットの全断片は同じシーケンス番号を使い、送信順に届くことを前提にする。受信側は最初の片が来た時点で全体分のバッファを確保するのが推奨され、途中で順序が崩れれば破棄できる。さらに数秒、新しい断片が来なければ未完成の再構成をあきらめてもよい。

上限を示す数値と設定値は別

120片に最大504オクテットを割り当てると60,480オクテットになる。RFC 1201はこの長さを非現実的と述べ、最大パケット長を設定可能にするよう求めた。実装には少なくとも576オクテットの受信が必須で、1,500オクテットまで扱うことが強く推奨されていた。いずれも特定のARCNETでそのMTUが設定された、または送受信に成功した証拠ではない。

504オクテットに抑えればリンク層での分割を避けられるが、経路上の各ノードが処理するIPパケットは増える。RFCはTCPの最大セグメントサイズやRFC 1063のようなMTU通知手段を挙げた。RFC 1191が後に説明するのはIPv4の経路MTU探索であり、ARCNETのインターフェース設定値そのものではない。フレーム容量、設定済みMTU、経路の上限、宛先まで届いたデータグラムは分けて確認する必要がある。

同じ媒体でも互換とは限らない

RFC 1201は、五社が1989年に新しいARCNETリンク形式を使うことに合意したと記す。新方式ではIP、ARP、RARPに212、213、214を割り当てた。前身のRFC 1051とは値が違い、RFC 1201自身が、両方式は同じARCNET上に存在できても相互通信はできないと明記する。物理ネットワークを共有するだけでは、解釈規則は一致しない。

IP自身のデータグラムと分割はRFC 791、ARPはRFC 826が背景になる。RFC 1201は現在、RFC Editorの一覧でSTD 46 / Internet Standardと分類される。これは仕様の出版記録であり、実装台数、配備率、アプリケーションへの配送を示す統計ではない。資料が示すのは、固定長フレームを越えるにはリンク層の再構成が必要であり、その最大値と移行方法は実際に使うネットワークで合意しなければならなかったという点だ。

参照した一次資料