要約

  • RFC 1223 は、真のブロードキャストもマルチキャストもない HYPERchannel 上で ES-IS と IS-IS を扱った。
  • 集団送信は、設定または学習した名簿ごとのコピーへ展開され、間隔を置いて送られた。
  • 正しい PDU や一件の成功は、名簿の完全性、全員の受信、隣接形成、経路収束、データ到達を証明しない。

一つの抽象の下に複数の送信

1991 年 5 月の RFC 1223 は NSC HYPERchannel 上の OSI CLNS/LLC1 を記録した。RFC Editor は Informational、IETF Datatracker は Legacy として保存する。現用網の証明ではない。

ES-IS と IS-IS は一つの制御 PDU が集団へ届く下位網を想定した。HYPERchannel は点ごとの配送しか持たず、文書も一般的なマルチキャストを提供しないと限定した。実際には名簿のスナップショット、コピー生成、キュー、個別送信、各受信者の処理が必要だった。

End System は設定済み IS ごとに ESH を送り、名簿外から ISH を受ければ holding time の間だけ学習できた。設定と観測は出所も寿命も異なる。さらに各コピーは多くのシステムで約 0.1 秒離すことが推奨され、先頭と末尾は同じ回線状態を共有しなかった。

完全な名簿がプロトコルを支えた

Intermediate System 側も他の IS を設定し、IS-IS では Level 1/Level 2 の対象集合を分断しない完全性が重要だった。IS は各宛先へ個別コピーを送り、その多重送信を IS-IS から透明にした。

RFC 1142 は当時の IS-IS、RFC 1195 は IP/OSI 共存、RFC 995 は ES-IS の文脈を示す。しかし、どれも特定名簿や全コピーの受信を証明しない。

真の IS がなければ SNARE address manager がその役を演じ、End System は全管理者を設定する必要があった。SNARE の冗長性も漏れた名簿を直さない。しかも query configuration は使えず、最低一つの IS または SNARE という初期設定が不可欠だった。

RFC 1223 の教訓は、抽象が責任を消さず移すことだ。集団意図、名簿権限、コピー、送信、受信、状態更新、収束は別記録である。欠けた相手を、漏れた設定、期限切れ、キュー損失、回線障害、処理失敗から区別できなければ、透明性は監査不能を意味する。

情報源