要約

  • 1997 年 5 月の RFC 2143 は Experimental 文書であり、近接したホスト間で IPv4 データグラムを SCSI SEND MESSAGE(10) に封入する案を示した。インターネット標準の制定や実運用報告ではない。
  • 通常のイニシエータは、自分の命令への応答を受け取る。相手ホストが開始した命令を受け取るにはターゲットモード対応のアダプタと、それを上位へ渡すドライバが必要だった。
  • SCSI にリンク層の放送アドレスはない。宛先の探索は候補 ID への順次送信とキャッシュに頼る。64 ホスト構成などは設計上の可能性であり、実測値ではない。

十バイトで解けたこと

RFC 2143 の著者 Ben Elliston は、六・十・十二バイトの SEND MESSAGE のうち十バイトの形を選んだ。先頭のオペコードは 0x2A。第七・第八バイトに IPv4 データグラム長を上位バイトから入れ、「stream select」の下位四ビットをペイロードの種類に使う。SCSI ヘッダの後に IP データグラムが続く。16 ビット長が IPv4 の長さと合うという理由も示されている。

この記述は伝送形式を具体化する。だが、書けることと届くことは別だ。文書中の最大 360 Mbit/s に近い速度への期待は、IP アプリケーションの測定結果ではない。RFC Editor の記録 も Experimental と明記し、インターネット標準ではないとしている。

相手からの命令を受ける側

普通の SCSI では、イニシエータが命令を出し、ターゲットが返答する。イニシエータ宛てのメッセージは、原則として過去に自分が出した命令への応答だ。これでは、複数のホストが互いに非同期で IP パケットを送る形にならない。受信側のホストアダプタにもターゲットモードが必要であり、さらに受け取った命令をネットワーク層まで上げるデバイスドライバが要る。RFC が「重要」とした制約はここにある。

同じバス上に存在することは、同じ発言権を持つことではない。データグラムが正しい十バイト命令に収まっていても、受信側がターゲットとして動けなければ対等な通信は成立しない。アダプタ能力とソフトウェア経路を、ケーブルの速度から推定することはできない。

放送できない場所で宛先を探す

次に IP は、次ホップのアドレスを SCSI ID へ対応付けなければならない。Ethernet なら RFC 826 の ARP は放送アドレスで一斉に尋ねられる。RFC 2143 は SCSI にそのリンク層アドレスがないと明記し、各ターゲットを順番に調べる方法を提案した。方式によっては七回以上の独立したバスアクセスが必要になる。既知の対応付けをキャッシュし、解決失敗も短期間記憶する案が、繰り返しの負荷を抑える。

しかしキャッシュは放送機能ではない。未登録や変更直後の相手を探すコストは残る。従来の SCSI ID は 0–7、Wide SCSI では 0–15。文書の規模の説明には、十メートル未満のバスも登場する。物理距離と ID 数は、提案が狙った小さな集まりを限定していた。

八台のホストが追加アダプタを持ち、IP ルーティングで合計 64 台を結ぶ例も示された。これは短い複数のバスを経路でつなぐ構想であり、一つの放送領域が 64 台に広がったという意味ではない。分散計算や NFS、Web、データベースの高可用性は用途として挙げられたが、その上で動いた実績は示されていない。

根拠と留保

  • RFC 2143 第 2–7 節が命令形式、受信条件、探索、拡張案とセキュリティ記述の根拠である。
  • RFC 826 は Ethernet の放送 ARP を比較するための一次資料である。
  • RFC Editor の情報 が発行日と Experimental の位置付けを確認する。

実機アダプタの試験、パケット記録、性能測定、採用調査はここに含まれない。短いセキュリティ節から認証や機密性を推定できない。図像も実在の設置例ではなく概念図だ。