要約

  • RFC 3475 は、Call Release の受信・処理後に、その Call に関連するすべての Connections の解放を開始するよう求めた。
  • 各 Connection は通常の Label Withdraw と Label Release を使うため、Call の確認だけでは全分岐の原子的完了、物理資源返却、サービス終了を証明できなかった。

一つの終了通知は、複数の後処理の開始点になり得る。2003 年3月の RFC 3475 は、その構造を ASON 制御面に示した。

この文書は Informational であり Internet Standard ではない。ITU-T の ASON 作業が選んだ CR-LDP 拡張に必要な IANA コードポイントを記録し、使用方法は ITU-T 文書に委ねた。したがって提案の存在は示すが、一般導入は示さない。

ASON は関係としての Call と、資源を使う Connections を分離した。一つの Call に複数 Connections を関連づけられる。Call Setup と Call Release は上位関係を操作し、ラベル手順は各実装を個別に操作した。

Call Release には Source ID、Destination ID、CALL_ID が入り、ネットワークの任意の主体が確立済み Call の終了に使えた。適切な状態コードを持つ Notification が発信者へ解放を確認した。しかし、その受領は Call 層の事実だった。

受信して処理すると、関連する全 Connections の解放を起動しなければならない。各解放は通常の CR-LDP Label Release と Label Withdraw に従った。単一命令が複数のピア、FEC、ラベル状態変更へ広がったのである。

RFC 3036 では、下流 LSR が Label Withdraw で対応を撤回し、受信側は Label Release を返す。上流 LSR も対応が不要になれば Release を送る。これらは限定された相手と状態の受領であり、世界全体の消去証明ではない。

三つの Connections が、完了、相手待ち、ローカル状態維持に分かれることは可能だった。全解放の義務は、同時完了する原子取引を作らない。Call の Notification と各分岐の完了台帳は別の証拠である。

解放時点の関連集合を固定して残す必要がある。後で空になった一覧からは、当初の本数、順番、再試行、ハードウェア返却前に在庫から消えた分岐を復元できない。

CALL_ID は扇状の処理を結びつけるが完了を作らない。各 Withdraw の処理、ラベル削除、クロスコネクト容量返却、信号停止、トラフィックや課金終了を証言できなかった。

soft permanent connection では、利用者・ネットワーク区間が恒久設定のまま、制御面のネットワーク区間だけを撤去できた。交換 Connection の終了は、全設備の撤去と同義ではない。

Crankback は逆方向の対比を与える。ER-HOP を含む Notification が資源不足の場所を示し、再計算を可能にした。しかし障害位置の把握は、代替経路の資源や次の要求成功を証明しない。

後年の RFC 4974 などを遡及して RFC 3475 の標準資格や実装証拠にしてはならない。Heng Lu の現実層で見れば、Call Release は命令、処理は判断、各ラベル交換は限定受領、状態削除、ハードウェア、信号、トラフィック、サービスは別の観測である。解放時の Connection 一覧を保存し、各枝を独自の証拠で閉じた後にだけ Call 全体を終了できる。

失敗も履歴に残す必要がある。ある Connection がタイムアウトし、別のピアが応答せず、資源が手動回収を待つなら、それぞれに状態、責任主体、次の確認時刻を持たせる。集約状態を「Call 解放済み」だけにすると、完了、再試行可能、資源残留の違いが消える。母集団を固定し、全メンバーに結論があって初めて、全体の終了は監査可能になる。

出典