要約

  • データVCにRSVP信号を同居させる方式は追加VCとPATH送信前の設定遅延を省く一方、非適合データによる廃棄へ更新メッセージもさらした。
  • 信号専用VCは独立したトラフィック契約を与えるだけで、サービス成功の証明ではない。受付、搬送、期限内の状態更新、データ処理を別々に確認する必要がある。

障害の起点は、節約としては正しかった。RSVPはPATHとRESVを周期的に送り、予約状態を保つ。ATMは仮想回線ごとのトラフィック契約で資源を扱う。制御メッセージを対象データと同じVCに通せば、追加回線はいらず、PATHのためにATM回線を新設する待ち時間もない。

だが、そのVC上のデータが契約から外れた時、廃棄処理は「これは予約を維持する重要なメッセージだ」とは限らない。信号も失われる。RSVPは少数の損失に耐えるよう設計されていたが、連続損失はsoft stateを期限切れにする。QoS VCが解体され、再び設定されるなら、信号を節約した方式が信号処理を増やす。

soft stateは受信時刻を結果に含める

RFC 2205の予約は永続的な記録ではない。ルータとホストの状態はPATHとRESVで更新され、cleanup timeoutまでに対応する更新が届かなければ削除される。変化する経路やマルチキャスト参加者に対して、信頼できる削除取引を待たず古い状態を消せる仕組みだった。

周期更新は、時々起きるパケット損失を吸収する。timeoutを更新周期の複数倍にすれば、何回かの連続損失にも耐えられる。しかしこれは、制御経路が恒常的に混雑してもよいという意味ではない。RFC 2205はRSVPメッセージを輻輳損失から守る最低限の帯域を用意するよう求めていた。

従って送信ログは、受信の証拠ではない。どのVCに分類されたか、そのVCがどの契約を持ったか、ATM区間を越えたか、相手が期限前に処理したかをつなぐ必要がある。ATM VCが存在してもRSVP状態が消えている場合があり、RSVP状態があってもデータ用QoS呼が拒否されている場合がある。両方が緑でも、アプリケーションへの到達は別の測定である。

四方式は失敗領域の割り振りだった

RFC 2382は主に四方式を挙げた。データと同じVCを使う。予約ごとに並行するRSVP信号VCを持つ。同一入口と同一出口集合のセッションを一つのpoint-to-multipoint信号VCへ多重化する。複数のpoint-to-point信号VCをセッション間で共有する。

共用方式はVC数を最小にし、データと同じ経路を進むPATHに追加のATM設定遅延を与えない。その代わり、信号はデータVCの扱いを受ける。非適合データがあるとRSVP信号も捨てられ、過大な損失はQoS VCの解体と再設定を繰り返させる、とRFCは警告した。

best effortのデータ経路に信号だけを載せる変形なら、QoS VC上の非適合トラフィックからは離れられる。しかしATM網の輻輳からは離れない。RFC 2382は制御メッセージに優先クラスを与えるべきだとし、ATMへ入る前のIPスケジューラで優先する案は有望だが難しく、追加研究が必要だとした。

予約ごとの専用信号VCは境界が明快である。別契約を持つため、データVCの違反を理由に適合する制御メッセージが捨てられない。ただし最低VC数は二倍になり、ATM信号処理と設定遅延も増える。隔離は無料ではなく、接続資源で買うものだった。

多重化すると、証明対象も増える

専用VCの費用を下げる案が多重化である。同じ入口と同じ出口ルータ集合を持つ複数セッションなら、point-to-multipoint制御VCを共有できる。ところが参加者が変わると出口集合も変わる。入口は別の既存VCを探す、新設する、現在のVCへ出口を加える、または不要な宛先へ送り続ける、という選択を迫られる。

したがって節約量は静的な数字ではない。トポロジーとトラフィックの組合せで変わる。coreで長寿命のpoint-to-point信号VCを使えば設定費を薄め、逆方向チャネルを活用できる場合もある。それでも必要本数は参加IPノードと通信パターンに依存する。

best effort VCの再利用は本数をさらに減らすが、信号損失確率を上げる。評価すべきなのはVC総数だけではなく、必要な条件下で一つの信頼できる制御経路がいくつの予約を維持できたかである。

記録方法も変わる。専用VCならPATHまたはRESVを制御VC IDと契約へ結び付ける。多重VCなら、その時点のセッション対応表、入口、出口集合も必要だ。「制御VC稼働中」という集計だけでは、障害時にどの予約が依存していたか復元できない。

強いQoSを与えれば終わり、ではない

制御トラフィックを大きなQoS枠で守ればよいように見える。RFC 2382はその答えにも限界を置いた。RSVP信号は通常およそ30秒ごとで、必要な割当ては比較的小さい。大きく要求しすぎれば、資源不足時に信号VCそのものが拒否される。

QoS呼が拒否された後のbest effort fallbackにも同じ矛盾がある。拒否原因がATM網の輻輳なら、fallbackメッセージも同じ輻輳を、より弱い保護で通らなければならない。fallbackの存在は到着の証拠ではない。

RFC 1755は既にconnection thrashingを避ける接続管理を求めていた。RFC 2382が示したのは別の発生経路である。制御搬送の損失からsoft stateが消え、QoS VCを解体し、再建の信号を増やす。

監査可能な結果は一つのランプでは表せない。特定RSVPメッセージの生成、VCと処理の選択、そのVCの受付と稼働、ATM区間の通過、期限内の状態更新、データVCの継続、実データの処理という連鎖が必要である。一段の成功は次段の成功ではない。

RFC 2382は普遍的な制御トポロジーを選ばなかった。共用、専用、多重化のどれを選んでも、その費用と失敗領域を同じものとして扱わないための枠を与えた。最低条件は、soft stateを維持する機構が十分に保護され、観測でき、その状態を事実として説明できることだった。