要約

  • ATM UNIは稼働中VCのQoSを変更できないため、RFC 2380は旧回線で通信を続けながら代替を完成させ、完成後にだけ切替と撤去を認めた。
  • 代替失敗時、増量要求はエラーになる一方、減量要求は大きな旧割当を残したまま成功と扱われ、要求状態と物理状態が一致しないことがあった。

回線が変わらなくても変更は成功した

RSVPは予約を随時変更できたが、ATM UNI 3.x/4.0は設定済みVCのQoSをその場で書き換えられなかった。RFC 2380の答えは置換だった。旧VCを変更せず稼働させたまま、適切な大きさの新VCを作る。成功後に通信を移し、それから旧VCを閉じる。新設に失敗すれば旧VCを使い続ける。

増量時の失敗は追加資源を提供できないのでエラーとなる。減量時は、旧VCが小さい要求をすでに満たせるため、物理割当が大きいままでも成功と扱った。非効率ではあるが、会計上の一致のために通信を止めるより、サービスとRSVPのエラー規則を守る選択だった。

成功応答はATM資源が縮小した証明ではない。「現在の要求」と「実際に確保中の容量」を別々に残さなければならない。

無通信は解放命令ではない

通常のIP over ATMでは、無接続IPに終了通知がないため、非活動タイマーでVCを消すことがあった。RSVPには資源寿命を決めるメッセージとタイムアウトがある。そこでRSVP管理VCの発信側タイマーは実質無限、受信側も無通信だけで接続を消してはならないとされた。

データ面の静けさは観測であり、制御面の解放命令ではない。この二つを混同すると、有効な予約を破壊する。

受信者が要求し、送信者が回線を作る

RSVP予約は受信者側から始まるが、ATM接続は送信者側が制御する。サブネット送信者がQoS VCを開始し、受信者は着信VCを受け入れる必要があった。RESV受信は回線作成そのものではない。

制御メッセージと関連データも同じQoS VCに載せてはならなかった。復旧不能なデータVC障害は割当失敗、復旧不能な制御VC障害は関連QoS VCの解放となる。予約状態を失った転送だけが残らないためである。

マルチキャストは空白より短い重複を選んだ

未完成の新VCと旧VCの両方で送れば重複し、新VCだけなら未参加受信者が欠落する。新しいマルチキャストQoS VCは全員の追加完了まで送信しない。一方、既存QoS VCへ一端点を移すときは、先に新側へ追加し、その後旧best-effort側から削除する。損失を避けるため、一時重複を受け入れた。

どちらも継続性の規則であり、会員追加完了、切替時刻、重複窓を別々に観測する必要がある。

移行中の真実は一つではない

要求は小さく、応答は成功、回線は大きく、費用は変わらず、通信は継続することがある。RFC 2380はこの一時的不一致を隠さず、移行後に照合できる証拠を求める設計だった。