要約

  • RFC 3033 は Q.2941 Generic Identifier と Q.2957 User-to-user Signaling に Internet 用の割当てを設け、セッション識別子、資源識別子、設定プロトコルのデータを区別できるようにした。
  • 正しい識別子は調整の入力にすぎない。新しい VC の成功、着信側での解釈、IP 層への通知、実際の移行には、それぞれ別の確認が必要だった。

長時間続く通信を専用の仮想回線へ移したいとする。呼出側は、送信元と宛先のアドレス、プロトコル、二つのポートを信号に載せる。着信側は対象のセッションを一意に読める。それでも、その時点で専用 VC が存在するとは限らず、IP 層が経路を切り替えたとも限らない。

2001 年 1 月に Proposed Standard として公開された RFC 3033 は、Q.2941 と Q.2957 の情報フィールドに Internet 用の値を割り当てた。ATM 上の長時間セッションや QoS を意識したセッションに不可欠な枠組みだと述べる一方、相互運用可能な実装を成立させる完全なプロトコルまでは規定しない可能性がある、と明記した。割当てと実行手順の境界を隠さなかったのである。

移行までには条件があった

例では、最初に複数の通信がルータ間の既定 VC を共有する。ルータが長時間セッションを検知すると、新しい VC を設定する。RFC 3033 は、新 VC の確立に成功した場合にのみ、そのセッションを移すと書く。

着信側でも二つの層が動く。B-ISDN シグナリング実体は、着信呼が Internet セッションに対応すると判断し、その事実を IP 実体へ通知する。移行を行うのは IP 層である。識別子は両者が同じ対象を参照するための鍵だが、検知、呼確立、通知、転送状態の変更を実行する命令そのものではない。

したがって、識別子を受け取ったこと、新 VC が確立したこと、IP セッションが移ったこと、新経路にパケットが現れたことは別々の記録になる。最初の記録で後の三つを代用すると、制御面の名前をデータ面の結果へすり替えることになる。

二つの情報要素は用途が違った

Generic Identifier は制御プレーン間で識別子を運ぶためのものだった。ATM 網は内容を調べることができ、一つの要素に複数の型付き識別子を入れられた。User-to-user Signaling（UUS）は、制御プレーンを介して利用者データを運ぶためのものだった。ATM 網はその利用者情報の内容を調べない。例外処理と相互接続の規則も同一ではない。最大長は前者が 63 オクテット、後者が 133 オクテットだった。

「透過的に転送する」という表現は、符号化規則に誤りのない情報要素を所定の方法で通すという意味である。内容の正しさ、送信者の真正性、操作の承認、状態変更の完了を証明する語ではない。制御情報が壊れず到着しても、それはまだ提案であり得る。

型は意味を絞ったが、結果までは表さなかった

関連する標準またはアプリケーションの値として、IPv4 に 0x03、ST2+ に 0x04、IPv6 に 0x05、MPLS に 0x06 が割り当てられた。識別子型 0x01 は Session、0x02 は Resource であり、IANA 用の範囲と実験・組織固有の 0xFE も設けられた。

IPv4 セッション識別子は、二つのアドレス、プロトコル、二つのポートからなる 13 オクテットだった。IPv6 版は 37 オクテットである。どちらも明示的な予約向けで、ワイルドカード関連には別の型が必要とされた。MPLS VCID は四オクテットの Resource だった。型によって「これはセッションか資源か」は分かるが、「その資源が割り当てられたか」は分からない。

複数値の扱いにも未定義部分が残った。識別子の順序、同じ型が複数ある場合の意味、空要素の意味は規定されていない。SETUP または ADD PARTY が Generic Identifier を含む場合、応答する CONNECT または ADD PARTY ACK は少なくとも一つを含む必要があったが、同じ値を返す義務はなかった。これは交渉を可能にする規則であり、交渉の詳細手順ではなかった。

未対応の ATM 網は呼を切断したり、情報要素だけを捨てたり、信号メッセージ全体を捨てたりできた。番号の割当ては、届いた値を解釈可能にする。すべての網にその値を届けさせる力は持たない。

RSVP を運ぶことと予約の成立は別だった

UUS ではプロトコル識別子 0x06 が Internet プロトコル／アプリケーションを示し、続く 0x02 が RSVP メッセージを示した。Resv は SETUP、ResvConf は CONNECT、ResvErr または ResvTear は RELEASE に載せられた。

RFC 3033 は二つの方式を比較した。順次方式では、設定プロトコルを既定または特定の VC で運び、IP セッションと ATM VC を順に確立する。同時方式では、設定プロトコルを B-ISDN 信号に含め、二つの確立処理を並行させる。後者は受付制御やタイマーを簡単にできたが、少なくとも PVC の場合を支えられなかった。したがって両方が必要だった。

SETUP に Resv があることは受付成功の証明ではない。CONNECT が返ることも、要求した QoS が全層に設定された証明ではない。予約判断、VC 状態、転送状態、パケット観測、アプリケーション結果は、それぞれ独立した事実である。

狭い仕様は未解決を見える形にした

セッション集約、ワイルドカード識別子、IPv6 フローラベル、トラフィッククラスは未解決事項として残された。IANA の将来割当て用空間も、後の値や普及を意味しない。セキュリティ節は、網が確認または提供した発信者番号を認証の一部に使える可能性を述べたが、セッション識別子自体を認証情報にはしなかった。

RFC 3033 の教訓は、ATM の成否を評価することではない。複数の機構が同じ対象を扱うには共有名が要るが、共有名だけでは状態機械も権限も結果も共有されない。対象を正確に指すことと、対象の現実を変えること。その間にある距離を仕様に残した点こそ、長く使える設計である。

出典

Lu Heng は RFC 3033、関連する ITU-T 勧告、参照 RFC の著者でも承認者でもない。本稿では、その論考を明示した分析視角として用いている。