要約

  • RFC 2383 は ST2+ の一ホップを一つの ATM 仮想回線に対応させ、利用者・制御・管理の各プレーンを分けた。したがって、データを運ぶ予約済み回線と、その故障を知らせる制御経路は同じ証拠ではない。
  • ATM 障害を複数の ST2+ エージェントが同時に検知し得る一方、既存の復旧規則は不明瞭で不完全だった。このため仕様は NoRecover を要求し、共有できない復旧の約束を明示的な拒否に変えた。

帯域を確保しても、障害から帰ってくる道まで確保したことにはならない。

1998 年 8 月に Informational RFC として刊行された RFC 2383 は、ATM UNI 3.1 上で ST2+ を動かすための対応関係を定めた。一つの ST2+ ホップには一つの ATM 仮想回線を使う。その回線を別のホップと共有せず、一つのホップを複数回線へ分割もしない。抽象的な FlowSpec は具体的なベアラへ結びつき、各ホップの資源状態は観察可能な対象を得た。

ところが復旧について、文書は同じ確信を示さなかった。実装は CONNECT で NoRecover を選択しなければならない。そうでない要求には、受信側が REFUSE と NoRecover 理由で答える。ATM の障害通知が ST2+ の復旧意味論を完成させるとは扱わず、ストリーム復旧はサポートしないと明記し、アプリケーションに委ねた。

これは機能不足を隠すための表現ではない。ATM は接続断を知らせられる。ST2+ エージェントは SCMP を交換できる。資源はホップごとに予約でき、新しい仮想回線も作り得る。しかし、どのエージェントが再構築を開始するのか、旧状態を誰が解放するのか、競合する試行をどう重複排除するのか、新しい区間を元のストリームへどう結び直すのか、最後にアプリケーションが何を成功と認めるのかは、それだけでは決まらない。

一ホップ一回線でも、真実は一種類ではない

RFC 2383 は、ユーザープレーン、制御プレーン、管理プレーンを区別した。ユーザープレーンでは ST2+ データが当該ホップ用の ATM 回線を通る。制御プレーンではエージェントが SCMP を交換し、管理プレーンではアドレス選択、回線設定、状態監視といったローカルな機構を扱う。

これらは一つの経路へ収束しない。SCMP 用 VC をどう設けるかは仕様で固定されず、IPv4 用 VC を再利用する実装も、ST2+ 制御専用回線を設ける実装もあり得た。あるストリームのデータと SCMP は同じ ST2+ ルーティング方向に従う必要があるが、同じ IP アドレスへの IPv4 方向は逆になり得る。制御交換が続いているのに予約データ回線が切れている場合も、その逆もあり得る。

ゆえに「ネットワークは到達可能だ」という表示は、対象を欠いた弱い主張である。IPv4 パケットが経路を得たのか、SCMP がエージェントへ届いたのか、ATM 交換機が呼状態を保持しているのか、特定 VC 上で利用者データが流れているのか。それぞれは異なる層の証拠であり、一つの成功が残りを証明しない。

一ホップ一 VC の規則は、同時に故障の範囲も明らかにする。VC はそのホップの具体的ベアラである。しかしエンドツーエンドのストリームは、複数のホップ、回線、エージェントにまたがる。一回線の消失が特定区間の破断を示しても、ストリーム全体を自動的に再構成する権限は生まれない。

検知は復旧の調停ではなかった

ATM 上では、ST2+ の HELLO 機能を実装しなくてもよいとされた。ATM 自身が接続障害を十分に通知できるため、周期的な HELLO は不要に見えたからである。しかし同じ文書は、データと SCMP が別々の VC を通り得る点を示す。片方の経路で得た生存確認は、もう片方の状態を証明しない。

復旧では、この分離がさらに重くなる。RFC 1819 に ST2+ の復旧動作はあったものの、RFC 2383 は ATM 環境に対して不明瞭かつ不完全だと判断した。ATM は障害の影響を受ける各当事者へ通知できる。そのため複数の ST2+ エージェントがほぼ同時に同じ故障を知る可能性がある。

全員が独立して復旧を始めれば競合する。一方が旧状態を解放している間に他方が再接続し、二つの代替区間が生まれ、下流状態が別々の試行へ結びつくかもしれない。必要なのは単なるトリガーではなく、唯一の権限を選ぶ規則、共通の復旧 ID、順序、そして検知・解放・再確保・再結合・アプリケーション受領を区別する証跡である。

RFC 2383 は、それらを相互運用可能な契約として定義しなかった。NoRecover は諦めではなく、制御面に残った穴を正しく表示するための選択だった。交換機が「VC は失われた」と真実を報告し、エージェントが「通知を受けた」と真実を報告し、新しい回線が「受付に成功した」と報告しても、アプリケーションの結果には欠落や重複が残り得る。

最後の義務はアプリケーションへ移った

「アプリケーションが復旧を提供しなければならない」という記述は、アプリケーションに魔法の能力を与えない。継続性の意味を判断できる層へ、未解決の義務を移したのである。

ある用途ではシーケンス番号から再開すればよい。別の用途では、部分結果を捨てて新しいストリームを作る必要がある。重複送達が許されない処理なら、人間の判断や冪等性の証明が必要かもしれない。ネットワークは新しい経路を作れても、古い経路と新しい経路を一つの正しい業務として扱えるかは知らない。

この委譲には証明責任が伴う。ATM が代替 VC を設定しただけで「復旧済み」と表示してはならない。故障通知、旧・新回線の ID、旧予約の解放、ST2+ ホップ状態の再構築、エンドツーエンドのストリーム ID、アプリケーションの完了信号までを結合して初めて、復旧を観測結果として語れる。

Heng Lu の現実層という視点に立てば、物理リンク、ATM 呼、ST2+ エージェント、SCMP 交換、アプリケーションセッション、利用者の結果は近接していても同一ではない。それらを一つの緑色ランプへ圧縮すると、画面は分かりやすくなる一方、主張の真偽を決める差が消える。誰が「復旧」と名づける権力を持ち、誰が欠落や重複を引き受けるのかという問題も隠れる。

回線を始める方向は政策で決まった

障害以前にも、接続には行為者が必要だった。交換型仮想回線では、ATM 接続を開始する側を運用または課金方針によって選べる。この向きは、ST2+ ストリーム構築時の送信者から受信者への向きとは独立している。

課金される側が発呼を担い、ストリームを作る側が次ホップの動作を期待し、最初に障害を見たエージェントには有料回線を作る権限がないかもしれない。こうした権限と誘因を無視した復旧設計は、技術図の上では成立しても運用上は実行できない。

FlowSpec から ATM パラメータへの写像にも境界があった。RFC 2211 と RFC 2212 のサービスモデル、RFC 1755 の ATM 信令を参照して、トラフィック特性と品質を接続へ反映する。しかし UNI 3.1 では、既存接続の QoS を途中で変更できない。対応可能な FlowSpec 変更でも、必要なら旧 ATM 接続を解放し、新しい接続を作ることになる。

これは値の上書きではなく、二つの資源割当間の引き渡しである。旧回線をいつ止め、新回線をいつ認め、失敗時に利用可能状態を残すかは、実装と方針に依存する。RFC は写像と再確立の必要性を示したが、無損失切替や特定配備の成功を測定したわけではない。

この点は RFC 2380 を扱った既存記事とも異なる。RFC 2380 の中心は予約変更時の reduced reservation と旧・新割当の約束であり、RFC 2383 が所有する問いは、ATM 障害を複数のエージェントが同時に見るのに完全な復旧権限がないことである。

明示的な拒否も相互運用性を作る

NoRecover を未完成機能とだけ見ると、その価値を見落とす。ある実装が私的な復旧順序を実行し、他方が同じ状態を別に解釈すれば、重複、予約漏れ、両端で意味の異なるストリームが生じる。仕様は曖昧な成功より、名前の付いた拒否を選んだ。

CONNECT の時点で制限を明らかにし、要求には理由付き REFUSE を返す。故障後に初めて双方の理解が違うと判明するより、安全である。正確に失敗するインターフェースは、成功条件が曖昧なインターフェースより相互運用しやすい。

Heng Lu の最小初期仕様という考え方では、これは不完全さの統制である。未検証の領域を保証らしい文章で埋めず、共有できる核を定め、共有できない判断を局所化し、後の動くコードが強い契約を証明する余地を残す。専用 VC、アドレス、接続設定、資源写像は共有核だったが、ストリーム復旧は違った。

NoRecover を将来外すなら、文章の追加だけでは足りない。同じ ATM 障害を複数のエージェントへ同時に与え、唯一の復旧権限を選び、重複を抑え、旧予約を精算し、新しい区間を正しいストリームへ接続し、アプリケーションへ曖昧でない結果を返す実装試験が要る。制御メッセージの紛失、非対称経路、データ VC と制御 VC の独立故障も対象にしなければならない。

RFC 2383 はその合格を主張しない。Informational という地位は歴史解釈にも効く。これはプロトコル仕様であり、配備調査ではない。IETF Datatracker の履歴は文書の経緯を示すが、広範な実利用の証拠ではない。

セキュリティは証拠列の一辺を守る

セキュリティ節も範囲を限定した。ATM 向けの最小拡張と修正は ST2+ や UNI 3.1 の安全性を弱めないとし、ネットワークが提供する発信者番号が検証済みなら認証に寄与し得ると述べた。

寄与は完結ではない。発信者 ID は回線開始者の識別に役立つが、FlowSpec がアプリケーションに認可されたこと、新 VC が失敗したストリームに属すること、再構築後のセッションをアプリケーションが受け入れたことまでは証明しない。身元、資源、状態、結果には別々の証拠が要る。

この文書から、特定事業者の導入、遅延目標の達成、実障害の復旧、特定の課金方針を推測することもできない。それらは実装・運用記録の領域である。

RFC 2383 が確実に残したのは、資源予約、障害検知、制御到達性、再構築、アプリケーション成功が別の主張だという境界である。最初の三つがそろっても四つ目がなく、基盤が再建されても五つ目がない場合はある。1998 年の仕様は、その不確実性を NoRecover という一語で隠さなかった。

失敗後に何もできない、という意味ではない。権限、順序、最終受領が標準化される前に、ネットワークが完了済みの復旧を約束しない、という意味である。回線は資源を予約できる。エージェントは破断を知ることができる。それでも「再開」の意味を所有するのはアプリケーションだった。

出典