要約

  • RFC 2067 は、RFC 1374 が認めた先頭の short burst、D1 fill、ゼロでない D2 offset を、稼働実装の利用がないとして廃止した。
  • ANSI に適合するパケットでも、より狭い RFC 2067 profile から外れ得た。その場合、受信側は受理しても無視してもよかった。
  • 相互運用性は一台の HIPPI-SC スイッチか単純な point-to-point 接続に限って主張され、複数スイッチの blocking 問題は範囲外だった。

新しい文書で最初に見るべきなのは、増えた欄ではない。RFC 2067 では、以前は合法だった三本の道が閉じられた。

short burst はパケット末尾にしか置けない。D1 area は 64 bit word 三個に固定され、fill は認められない。D2_Offset はゼロでなければならない。RFC 1374 の推奨形が、全実装の共通文法になった。

選択肢には全員分の維持費がかかる

wire format の分岐は小さく見えるが、受信 parser、組合せ試験、障害解析の状態数を増やす。誰も使っていない自由でも、仕様に残れば独立実装すべてが対応可否を決め続けなければならない。

RFC 2067 は RFC 1374 に基づく IP encapsulation と switch discipline の実装が少なくとも十あったと報告した。一方、削った三項目を使用中の実装はなかったという。そのため既存システムは新しい制約をすでに満たし、変更で相互運用問題は起きないと判断した。

これは限定された記録である。十実装の名称、codebase の独立性、全組合せ表は本文にない。観測されなかったことは、私的な試作が歴史上一度もなかったことを証明しない。確かに示されるのは、採用されない自由を共通契約に残す根拠は弱い、という当時の工学判断だ。

RFC 2026 はその手続きを説明する。Draft Standard には、少なくとも二つの独立し相互運用する実装と十分な運用経験が必要だった。要件は option や feature ごとに及び、証明されないものは通常削除すべきとされた。RFC 2067 の三項目は、手続きが packet header に作用した例として読める。

ANSI適合とInternet profile適合は別の受領証だった

HIPPI-FP と HIPPI-LE の許容範囲は、RFC の profile より広い。RFC 2067 は、ANSI standard に従う encapsulated IP datagram がこの文書では違法になり得ると明記した。受信側はその datagram を受け入れることも、無視することもできた。

したがって「標準準拠」だけでは証明対象が欠ける。ANSI準拠は link layer の形式を示す。RFC準拠は IP peer が互いに期待できる部分集合を示す。hardware が運べる全形式を Internet implementation が必ず解釈する、という意味ではない。

ARPはIPの実績を借りられなかった

RFC 1374 は IP と ARP を一緒に扱った。しかし ARP 部分には Draft Standard へ進めるだけの実装経験がなかった。RFC 2067 は ARP を別の Informational memo に移し、将来の関心と実装が整えば再検討できる形にした。

IP packet が switch を通る事実は、address resolution、network configuration、broadcast emulation の成功を証明しない。RFC 2834 は 2000 年に HIPPI-800 の ARP と IP broadcast を改めて明確化し、拡張した。未成熟な課題は別の名前と証拠経路を保った。

一台のスイッチが主張の境界になった

準拠 host は、一台の HIPPI-SC switch から成る network と、switch のない単純な双方向直結で相互運用すると考えられた。より複雑な network は動くかもしれないが、switch 内部と接続方法に依存した。

単一 switch は non-blocking とみなされた。複数 switch 間で link を共有すると、別の source/destination pair が占有し、目的地への経路が塞がることがある。正しい header だけではこの contention を解けない。文書は理解していない fabric まで保証しなかった。

packet capture で確かめられるのは、D1 size、D2 offset、fill、burst 位置である。application delivery、他経路の非blocking性、peer identity、authorization は別の証拠を要する。「既知の security problem を導入しない」という記述も、認証や暗号化を提供しない。

Lu Heng の後年の Minimum Initial Specification を通して見ると、実証された相互運用規則だけを共通層に残し、topology choice を局所化した例と解釈できる。これは後世の編集上の比較で、John Renwick の意図を示す資料ではない。一次資料が示す歴史はそれだけで明瞭だ。running code が削除の根拠となり、試験された topology が約束の限界となった。

出典