要約

  • Demand RIP は、X.25 と ISDN 上で周期的な WAN 更新を、確認応答付きのトリガー交換に置き換えた。これによりアイドル回線を閉じられる一方、トリガー応答から得た経路は通常、沈黙だけでは期限切れにならない恒久状態になった。
  • 実際の発呼に失敗すると回線管理部が circuit down を通知し、経路はエージング、ホールドダウン、削除へ進む。更新の ACK はパケットや断片の受領を示すが、経路の真実性や利用者通信の成功までは示さない。
  • RFC 1581 が報告した完成実装は一つで、新機能は X.25 と ISDN 上で自己対向試験された。RFC 1264 の基準では、これは実装証拠であって、独立した複数ベンダーの相互接続証拠ではない。

三十秒ごとの確認が回線を眠らせなかった

RFC 1582 は RFC 1581 と対になる Standards Track の Demand RIP 仕様で、公式記録によれば1994年2月の文書である。対象の公衆データ網では、データが来たときに仮想回線を張り、用が済めば解放できた。ところが通常の RIP は、新しい事実がなくても定期的に経路を送り続ける。

LAN の「ブロードキャスト」という言葉を WAN に持ち込むと、実態が隠れた。共通媒体への一送信ではなく、既知の宛先へ一件ずつ更新を並べる必要があった。RFC 1582 は N 台のルーターなら一周期に N × (N - 1) 回の更新が、N × (N - 1) / 2 本の接続上で発生し得ると説明した。しかもインターフェースの同時回線数は相手の数より少ない。ISDN 基本インターフェースの二回線という例は、知っている相手全員へ同時に電話できない現実を示す。

周期を長くすれば料金は下がるが、変化への反応は遅くなる。周期を守れば、経路表を繰り返すためだけに呼が維持される。そこで仕様は頻度の妥協ではなく、更新の理由を変えた。要求、データベース変更、または回線管理部による復旧通知があるときだけ、デマンド回線上の WAN 更新を送る。LAN と固定ポイントツーポイント回線では、通常の RIP と周期更新がそのまま残った。

無音は新しい観測ではなかった

対になる RFC 1581 は Informational の分析報告であり、RFC Editor の記録もその位置づけを示す。デマンド回線では周期送信を止め、トリガー更新を ACK が返るまで再送し、受信した情報を通常の時間切れにしない。それが中心となる取引だった。

RFC 1582 のデータベースには二種類の時間があった。LAN の通常応答で学習した経路は一時的で、更新がなければ消える。WAN のトリガー応答で学習した経路は通常「恒久」で、平常時にはタイムアウトしない。

ただし恒久は真理という意味ではない。前回受け入れた状態を、規則が反証と認める出来事まで保持するという意味である。完全な応答が経路を不可達と示す、以前あった項目を含まない、インターフェースが落ちる、更新の ACK が長く返らない、あるいは実際の転送で次ホップへの発呼が失敗する。これらはそれぞれ別の否定材料だった。

したがって「最近更新を聞いていない」は障害報告ではない。そもそも聞かないように設計したからだ。沈黙は肯定の測定でもない。以前の状態を再利用する条件にすぎない。

回線管理部が経路を老化させる

RFC 1582 の構成では、IP や IPX と経路制御アプリケーションの下に回線管理部が置かれる。論理的な次ホップと、X.25 や ISDN で発呼する物理アドレスを対応づけ、データや更新が来れば仮想回線を開く。アイドルタイマーが切れれば閉じる。

通常通信で回線を開けなかった場合、回線管理部は circuit down を上へ渡す。そこから経路制御側が、該当する次ホップ経由の項目を一時状態にし、エージングを始め、不可達として広告し、ホールドダウン後に削除する。復旧が間に合えば恒久状態へ戻せる。すでに期限を越えたなら、要求を送り、完全な応答で表を作り直す。

circuit up が証明する範囲も限られる。管理部が再び相手へ回線を張れたという事実であり、古い全経路が現在も正しいという証明ではない。だから復旧時には双方が情報を交換し直す。

さらに、回線管理部の復旧アルゴリズム自体は仕様外である。回線不足、アドレス対応の誤り、遠端の停止、媒体故障は同じ down 境界へ集約され得る。経路制御にとって安全な入力であっても、原因分析の完成品ではない。

ACK が閉じるのは配送の問いだけだった

周期更新をなくすと、一度失われた変更を次の周期が直してくれない。仮想回線の空きがない、送信キューが満杯、別の呼のために回線が奪われる、フレームが壊れる。RFC 1582 は、こうした損失に要求、応答、確認、再送で対処した。

大きな更新は複数断片に分かれ、各断片が個別に ACK される。受信側は全断片が揃うまでデータベースを更新しない。再構成時間を越えれば一式を捨て、完全更新を要求し直す。さらに、古い更新が未確認の間に経路データベースが変われば、新しいシーケンスの更新がその未確認更新を置き換える。受信側でも異なるシーケンスの新断片が来れば、不完全な古い組を残さない。

ここから得られる証拠は明確である。ACK は応答または断片の受領を示す。全断片の再構成は一つの更新を適用できる状態を示す。シーケンスは世代を区別する。しかし、広告された宛先が本当に到達可能か、FIB がその経路を選んだか、利用者パケットが通ったか、アプリケーションが成功したかは別途観測しなければならない。

設定された相手一覧も同じである。送信先を定めると同時に、どの相手から更新を受け入れるかを定め、一覧外の更新は捨てる。RIP-2 の認証も追加できる。それでも正しい相手から届いたという事実と、内容が運用上正しいという事実は同じではない。

電話代を状態の責任へ交換した

恒久経路は忘却で修復できない。RFC 1582 は、代替経路をすべて保持するか、限られた数だけ保持して、捨てた可能性を記録し、必要になる前に再取得するよう求めた。周期更新が再供給していた情報を、メモリーと明示要求が肩代わりした。

通信量の削減は、状態機械の簡素化ではなかった。正確な撤回、再送、断片の完全性、回線管理部との同期、再起動時の再構成が必要になった。見える回線費用を減らすため、ルーターは見えにくい状態債務を引き受けた。

RFC 1582 は、回線管理部と経路アプリケーションが別々に停止・再起動できる製品も扱った。記述された実装では両者がほぼ同じプログラムだったが、Unix では管理部がカーネル、経路処理が別プロセスになり得る。別カードの場合もある。独立した寿命を持つなら、keepalive と状態表の再同期が必要だった。片方の生存は、もう片方が同じ状態世代にいることを保証しない。

一つの自己試験を、一つの自己試験として読む

RFC 1581 は、完成実装は当時一つと考えられる、と記した。Spider Systems の実装は IP RIP-1、IPX RIP、IPX SAP に対応し、RIP-2 は未対応だった。X.25 と ISDN では自身を相手に試験し、Ethernet LAN では通常の複数実装と一緒に動かした。Novell 専用の二実装は開発中だった。

これは紙だけではない。二種類の WAN でコードが動いた。しかし、新しい WAN 形式について独立実装同士が断片、タイマー、再起動、up/down を同じように解釈したという記録ではない。

RFC 1264 とその公式記録は、経路制御プロトコルが分散リアルタイム算法であり、一環境・一実装の成功は別環境・複数ベンダーの成功を保証しないと説明した。独立実装、全機能の相互試験、セキュリティ機能の実証は別の段階である。

「実装済み」を「相互運用済み」に膨らませず、「自己試験」を無価値とも扱わない。その中間を正確に残すことが、歴史資料の役割である。

1997年の改良でも推定の責任は残った

RFC 2091 は1997年1月の文書で、記録も確認できる。RFC 1582 と比べ、完全交換の後は変更だけを送り、通信量とメモリーを減らし、旧方式の255断片上限をなくした。

しかし、WAN のトリガー応答から得た経路は引き続き通常恒久だった。回線管理部は down/up を通知し、更新は ACK と再送を使った。設定された回数の未確認送信が続けば、定めた期間の後に次ホップ経由の経路を不可達へ移し、ホールドダウンを始めた。復旧や再起動では flush と完全交換が必要だった。

後の文書は、発行されたから自動的に配備されたわけではない。変更されたのは更新の運び方であり、沈黙を採用したシステムが必要とする証拠境界は残った。回線の状態、経路の状態、更新の受領、転送、サービス結果を一つの表示に畳まない。それがこの古い設計から今も取り出せる規律である。

出典