要約

  • RFC 2216における「サービス」は一つのネットワーク要素が提供する協調した機能であり、アプリケーションが見るエンドツーエンドの「振る舞い」とは別物だった。
  • テンプレートは、呼び出し情報、パケット処理、外部へ出す情報、ポリシング、順序付けと併合を明示させ、名前だけが実行結果を代弁することを防いだ。
  • 登録番号や受理された要求は限定された段階の記録にすぎず、実トラフィックの適合、全要素での資源受付、配送、アプリケーション成功を証明しない。

番号が示したのは読むべき仕様だった

RFC 2216は、サービスとそのパラメータに二段の数値名前空間を与えた。公開利用するサービスがIETF領域の番号を得る最低条件は、この形式に従うRFCを公表することだった。設定プロトコル、ルーター、管理系は、同じサービス番号.パラメータ番号を使って意味を参照できた。

しかし番号が確定しても、サービスはまだ動いていない。番号はどの契約を読むべきかを示すだけで、要求者の権限、装置の実装、資源の受付、パケットの適合、利用者の結果については語らない。

RFC 2216は「サービス」を意図的に狭くした。ルーター、サブネット、終端OSなど、一つのネットワーク要素が提供する名前付きQoS制御能力である。一方、「振る舞い」は、経路上の各要素を合成した後にアプリケーションが経験する性能を指す。異なるサービスが混在したり、制御を行わない要素が挟まったりすれば、最終的な振る舞いは複雑になり、定義できない場合すらある。

名前はローカルな契約を指す。結果は経路全体の事実である。

仕様は内部機構ではなく外部責任を開示する

RFC 2216は特定のスケジューラーを採用させる文書ではない。サービス仕様が答えなければならない質問を順番に定めた文書だった。エンドツーエンドの振る舞いと動機に加え、ネットワーク要素のデータ処理、呼び出し情報、外部へ出す情報、ポリシング、順序付けと併合が必須となる。実装評価の基準も必要で、実装例や利用例は任意だった。

データ処理の節では、何を制御するか、どの程度強く制御するか、どんな前提に依存するかを述べる。「数学的に保証する」と「通常の条件で満たすべきだ」は異なる。可能なら、アルゴリズム名ではなく最大遅延や最小帯域配分のような観測可能な性能で義務を表す。

この設計は実装の自由を残しながら、主張の比較可能性を守った。内部構造が違っても同じ外部要件を満たせる。逆に、同じ商品名を掲げても、定義された要件を満たさなければ同じサービスとは言えない。

データ項目にも型、範囲、精度が必要だった。推奨する具体形式は示せるが、共通の意味を一つの符号化方式に閉じ込めない。意味とワイヤ表現を分けたのである。

TSpecは申告であって観測ではない

呼び出し情報は通常、TSpecとRSpecに分かれる。TSpecはサービス対象となる許容トラフィックの形を述べる。RSpecは要素に求める品質を述べる。両者は別の構成要素が作ることもあるため、独立に定義されなければならない。

要求を受け入れたサービスモジュールは、実トラフィックがTSpecに収まる間、RSpecの品質を提供するという条件付き契約に入る。重要なのは、TSpecが許容形を示すだけで、現在流れているパケットを測定した結果ではないことだ。

そこでポリシングの仕様が不可欠になる。違反パケットを破棄するのか、遅延させるのか、印を付けるのか、ベストエフォートへ落とすのか。別の処置は合法か。入口だけで検査するのか、各ホップか、マルチキャストの分岐点か、複数送信源の合流点か。これらを明記する必要があった。

場所は判定そのものを変える。トラフィックは経路の途中でバースト性を増すことがある。入口のTSpecをそのまま内部で適用すると、入口では適合していた流れをネットワーク自身の変形のために罰する恐れがある。ポリシング記録を解釈するには、TSpecの版、観測点、トポロジー上の役割、そこまでの経路が要る。

シグナリングは意味を運ぶが、意味を実現しない

サービスモジュールは設定、経路制御、管理機構とインターフェースを持つ。だがサービス定義は、状態を設置するプロトコルとは分離された。RSVP、ST-II、管理プロトコルなどが呼び出し情報を運べる。サービス仕様が要求できるのは、パラメータの運搬と要素が発したエラーの通知までだった。

したがって、正しいRSVPオブジェクトが存在しても、証明されるのは制御面の一段階である。RFC 2210はIntegrated Services情報をRSVPで表す方法を規定したが、そのオブジェクトが全要素の受付、実際の設置、トラフィック適合、パケット処理を自動的に証明するわけではない。

外部へ出す情報にも限界がある。サービス専用の帯域、対象フロー、経路推定用の特性値などを公開できる。経路を合成するなら、要素を処理する順序に左右されない合成則が必要になる。値を提供できない要素は有効性フラグを立て、それを後段まで保持する。後の正常な要素が、前の欠落をなかったことにはできない。

特性値が揃っても、端点へ届く保証はない。計算や提示を行うかどうかは設定・経路制御プロトコル側の仕様である。サービスの有用性がその情報に依存するなら、作者は欠落時の危険を明記しなければならない。

併合は圧縮ではなく新しい契約計算だった

同じフローを複数の要求が覆う場合がある。マルチキャストの受信者が異なる品質を求めたり、恒久設定と動的予約が重なったりする。実行可能な一つの要求を作るには、サービス固有の判断が必要だった。

テンプレートが求めた操作は五つある。順序関係はTSpecとRSpecの代替可能性を比べる。総和は複数フローを収容する要求を作る。最小は目標の記述と適用すべき実トラフィック記述を調整する。RSVP併合はローカルな呼び出しと上流へ返す値を同時に計算する。最小共通要求は、どの入力よりも劣らない上界を作る。

比較不能な要求があってもよい。上界は最小上界でなくてもよく、要素ごとに異なる適合値を選べる。余剰を許容できるパラメータは枝の最大値を使える一方、全経路で処理可能でなければならないパケット長などは、全枝に安全な控えめな値を選ぶ。

最終的に設置された要求は、入力、順序則、併合関数、分岐状況、上流へ返した値から生まれる派生判断である。「サービス有効」という一行だけでは、その判断の出所が失われる。

隣接する仕様は別の証拠面を担当した

RFC 2211はControlled-Loadを定義し、RFC 2212はGuaranteed Serviceの数量的境界を定義した。RFC 2213とRFC 2214は管理オブジェクトを、RFC 2215は共通特性値を扱った。

サービスの意味、要求の運搬、実装、管理上の状態、観測結果は相互に補強できるが、同一ではない。MIBの行は経路結果ではない。パケットの観測は送信者の契約全体を示さない。予約の受付はアプリケーションの完了を示さない。

RFC 2216の評価基準も、隔離した一つのネットワーク要素を試すものだった。本番の結果にはリンク、設定プロトコル、他の要素も影響する。文書は万能なエンドツーエンド測定を定めていない。

必要な証拠は、仕様とその状態、番号、要求者と権限、TSpec・RSpecの出所、シグナリングとエラー、要素ごとの受付、実トラフィック適合、ポリシング、併合結果、特性値と有効性、経路の時点、配送観測、アプリケーション処理へと続く。前の段階は次の段階を支えられるが、代わりにはならない。

動くコードの優先という編集上の視点を当てれば、共通仕様の役割は最小の相互運用契約に限定される。公開だけでは運用事実にならず、実装、採用、利用が別途必要だ。これは証拠を読む枠組みであり、RFC 2216が後の制度変化を引き起こしたという主張ではない。

RFC 2216の強さは、名前に大きな権威を与えたことではない。名前が証明できる範囲を小さく保ったことにある。

出典と限界

中心資料はRFC 2216であり、RFC 1633と上記の関連RFCを構造上の背景とした。これらは1997年の仕様上の意味を示す。現在の普及率、特定機器の動作、現行予約、実測性能、配送、利用者の成功は示さない。

RFC Editorの記録とIETF Datatrackerの記録は公開状態を確定し、最小初期仕様という編集上の視点は、共通契約とその後の実装・採用・利用を切り分ける。