要約

  • RFC 3474 は、ASON Call の存続期間を通じて一定となる CALL_ID を提案し、事業者固有形式とグローバル一意を意図した形式を定義した。
  • 持続したのは関係の識別である。Connections、RSVP 状態、ローカルラベル、実装資源、物理信号、トラフィック、提供サービスは別々に確かめる必要があった。

同じ番号が残っているからといって、同じ回線が残っているとは限らない。2003 年 3 月の RFC 3474 は、その差を ASON と GMPLS RSVP-TE の境界に刻んだ文書である。

まず史実上の位置づけが重要だ。この RFC は Informational として公開された提案であり、Internet Standard ではない。soft permanent connection、Call と Connection の分離、再起動時の扱い、追加エラーなど、ASON の要件を GMPLS に持ち込むための仕組みを記述した。後年の標準化や特定網への導入を、この文書だけから推定してはならない。

Call は端点間の関係であり、Call controller が扱う。Connection は資源を伴ってトラフィックを運ぶ実体で、Connection controller が扱う。一つの Call のもとで Connection は増え、置き換わり、消えることができる。関係を管理する記録と、運用中の経路は同じライフサイクルを持たなかった。

CALL_ID はその関係を追跡する鍵だった。RFC 3474 は事業者固有形式とグローバル一意形式を示した。後者は ISO 国コード、ITU キャリアコード、組織が管理するアクセスポイントコード、送信元 LSR アドレス、ローカル識別子を組み合わせる。64 ビットのローカル識別子は Call の存続中、一定でなければならない。

多数の名前空間を組み合わせると、強い権威が生まれたように見える。しかし、そこで強くなるのは区別能力であって接続能力ではない。CALL_ID は「どの Call か」を示すが、波長を予約せず、クロスコネクトを設定せず、光ファイバーを点灯せず、パケットを届けない。送信元 LSR のアドレスが事業者内だけの値なら、事業者固有形式が自動的に世界一意になるわけでもなかった。

割り当ての境界も明記された。最初の利用者は CALL_ID をゼロにできる。最初のネットワークノードが新しい値を割り当てるか、既存の非ゼロ値を検証する。中継ノードは ASON 拡張を理解しなくても値を変えずに転送する。Path、Resv、PathTear、PathErr、Notify に同じ参照を保持できる一方、ResvConf は変更されない。この連続性は記録を結ぶが、個々の Connection 状態を一致させるものではない。

基本分離モデルでは、Call は通常一つ以上の Connections を持つ。ただし break-before-make 復旧では、古い Connection を外してから新しいものを作るため、一時的にゼロになり得る。その空白でも Call と CALL_ID は残る。Call の存在をサービス稼働と表示する監視画面は、まさに接続が失われた時間を隠してしまう。

任意の完全分離モデルは、さらに明瞭だった。CALL_OPS により Connection を同時に作らず Call だけを確立、同期できる。定常状態でも Connections はゼロ、一つ、複数のいずれでもよい。ゼロは設計の破綻ではなく、関係と接続が別の事実であることを表す正規の状態だった。

SPC_LABEL も別の境界を示す。soft permanent connection では、恒久設定された入口区間と交換区間を関連づけるが、関連づけの方法は文書外のローカルポリシーである。非 GMPLS サブネットワークを越えるラベルは制御ノードのローカル値であり、手動設定または事前発見に依存できた。境界で正しい対応表があっても、端から端まで物理的に連続している証明にはならない。

再起動時には、永続ストレージ、隣接ノードからの推定、管理面の指示など複数の情報源が使われる。CALL_ID を復元できたことは、関係を記憶していた証拠にすぎない。隣接側の合意、RSVP の収束、ハードウェア設定、信号、トラフィック、アプリケーション結果はそれぞれ確認が必要である。

Notify も層を統合しない。CALL_ID とセッションを同じ通知に含められ、一つの Notify に複数 Calls のセッションが入る場合もあった。通知の封筒、Call の識別、Connection の状態は関連づけるべき情報であって、一つの事実ではない。

後続文書は年代順に扱う必要がある。RFC 4139 は ASON の適用性と要件を整理した。2007 年の Standards Track RFC 4974 は、より完全な Call 手続きを定め、Call 自体はトラフィック接続性を提供せず、Connections はゼロ、一つ、複数になり得ると明記した。RFC 6004 はさらに UNI 属性を拡張した。これは設計の発展であり、2003 年提案への遡及的な標準資格や実装証明ではない。

Heng Lu の現実層という見方を使えば、CALL_ID は調整のための記号、Call controller の受理は決定、Connection controller の信号処理も別の決定である。設定済み資源、物理信号、双方向トラフィック、利用者が受けたサービスは観測層に属する。共通キーは結合を助けるが、上位の名前から下位の現実へ権威を移すことはできない。

したがって履歴は複数の時間軸を保つべきだ。CALL_ID の割当主体、形式、一意性の範囲、送信元アドレス文脈、Call の開始と終了を残す。各 Connection には固有の識別、関連期間、RSVP メッセージ、ラベル由来、資源設定、解放記録を与える。信号、トラフィック、サービス観測は、実際に測定した Connection に結びつける。この構造だけが、関係の連続性を物理接続の連続性と取り違えずに記録できる。

出典