要約

  • RFC 2379は、QoSパラメーターを持つ別個のATM仮想回線を作るためのRSVP制御メッセージであっても、既存のベストエフォート・データ経路に載せることを推奨した。
  • PATHまたはRESV、RSVPの状態、受付判断、設定済みVC、アプリケーションが得た性能は連続する証拠であり、どれか一つを残り全部の証明にしてはならない。

保証を求める信号に保証はなかった

RSVPは資源予約を要求するための仕組みであり、ATMはサービス特性を指定した仮想回線を作ることができた。それでもRFC 2379は、信号用の保護された回線を先に用意しなかった。ユニキャストなら宛先に届く既存VC、マルチキャストならグループへの通常トラフィックが使う経路にRSVPメッセージを送る、とした。

理由は回線数にある。セッションを始め予約を要求する前から、通常の通信経路は存在しなければならない。その経路を制御にも使えば、別の回線を要求するためだけのATM回線を増やさずに済む。弱い輸送手段の上で、より強いサービスを要求する非対称性は、欠陥ではなく選択だった。

文書はベストエフォートVCを信頼できるものと言い換えてはいない。RSVP制御が望むほどの信頼性を持たない可能性を認めたうえで、損失への耐性をソフトステートに求めた。予約状態は一度の取引で永久に確定するのではなく、時間とともに更新される。制御パケットが一つ欠けても、後のリフレッシュが状態を維持、あるいは回復できる。

したがって、一つの欠損は即時の消滅を意味しない。しかし送信成功も予約成立を意味しない。後続のリフレッシュ、期限切れ、受付結果、関連回線の存続を見て初めて、その信号の意味が決まる。

一つの予約に一つのVC

ATMでは複数セッションを同じVCに集約すれば効率が上がる可能性があった。しかしRFC 2379の時点で集約は研究課題だった。そのため実装には、RSVP予約ごとに独立したVCを使うよう勧めた。

この保守性は変換の段階を見えやすくした。RSVPセッションはATM回線そのものではない。予約をATMサービスパラメーターへ写し、受付を判断し、VCを作成または選択し、トラフィックを分類する必要がある。逆にVCが存在しても、パケットが要求どおり扱われた証明にはならない。

同時期の文書も役割を分けた。RFC 2380は実装要件、RFC 2381はIntegrated Servicesのcontrolled-loadとguaranteed serviceからATMへの対応、RFC 2382は全体フレームワークを扱った。この分割は、一つの信号を全工程の成功証明にしないための境界でもある。

ショートカットは終点を継承した

ATMショートカットは論理IPサブネットの境界を越えることがあり、PATHとRESVが非対称な経路を通り得た。RFC 2379は、NHOPオブジェクトと、誤ったインターフェースに到着したメッセージの転送という既存RSVP動作で、その非対称性に対処した。

さらに重要なのは終点を決める権限である。QoSショートカットが独自に宛先を発見するのではない。ベストエフォート・トラフィックがすでにショートカット終点を選んでいるなら、RSVPが起動するQoS VCも同じ終点を使う。推奨モデルでは、ベストエフォートのショートカットがなければ、サブネットを越えるQoSショートカットも生まれない。

これは予約サービスの禁止ではない。ホップ単位のQoS VCは残る。制約されたのはショートカット終点の由来であり、ベストエフォート転送が先に決め、QoS構築がそれを継ぐ。完成した回線は設定の証拠だが、経路発見、受付、配信の成功を遡って証明しない。

マルチキャストには一つの正解がなかった

同じマルチキャスト・セッションでも、受信者ごとに異なるQoSを要求したり、何も要求しなかったりする。関連フレームワークは、完全異種、限定異種、同種、修正同種のモデルを示した。RFC 2379は万能の一案を選ばず、少なくとも限定異種か修正同種を、できれば選択機構とともに両方を実装するよう求めた。

この慎重さにも歴史的価値がある。運用上の差を消して図を整えるのではなく、実装可能な下限を定め、受信者間の違いを観測できるままにした。

四つの受領証

安全な読み方では、少なくとも四つを分ける。制御を運んだベストエフォート経路、生成と更新を繰り返すRSVP状態、受付と構成により作られたATM VC、そしてカウンターやアプリケーションが示す実際のサービスである。

PATH送信はRESV受信ではない。RESV受信は受付成功ではない。生きているVCは正しい分類ではない。QoSという名称は遅延、損失、到達の実測ではない。RFC 2379の設計は、それらを接続しつつ同一視しなかった。