要約

  • RFC 3387 は、パケットを分類し優先できることと、定義され検証可能なサービスを提供できることの間に、管理機能の大きな空白があると整理した。
  • アクセス、コア、管理ドメイン境界に別々の受領書が必要であり、収益性の高い予約がベストエフォートを圧迫する危険も隠してはならなかった。

境界ルータに二つのパケットが届く。一方にはクラスを示す印があり、分類器が読み、スケジューラが先に送る。ログとパケットキャプチャは、設定どおりの局所動作を示す。

しかし、その時点ではサービス名さえ十分に決まっていない可能性がある。印を付けた主体は正当だったか。経路の資源は受け入れ済みか。次のドメインも同じ意味で処理するか。計測値に異議を申し立てられるか。復路が別事業者なら誰が請求するか。キューの成功は、これらの問いへの回答ではない。

2002 年 9 月の RFC 3387 は、IRTF Service Management Research Group の検討を Informational 文書としてまとめた。新しいプロトコルを標準化せず、完成した配備も報告していない。QoS の転送技術に対し、それをサービスとして運用する枠組みが遅れていたことを主題にした。

初期の IP 管理は単純さと非集中制御を重視し、ベストエフォートはその構造と相性がよかった。差別化された処理は、希少資源を誰に渡すかという判断を持ち込む。装置管理だけでなく、利用者、約束、資源、測定、責任を結ぶ必要が生じた。

文書はサービスの定義と具現化を分ける。定義は曖昧であってはならず、ネットワーク能力へ写像できなければならない。具現化は、その定義を実際の制御と資源に落とす。情報モデルやポリシー行は意図を保存するが、装置への反映、経路全体の受入れ、実測結果を自動的には証明しない。

アクセス側には認証、認可、アドミッション制御、トラフィック条件の検証、課金インターフェースが要る。障害通知、再構成、終了もサービスの一部である。認可は利用を許す判断であり、アドミッションは資源が足りるという判断である。両者を一つにすると、許可したが実行不能という状態を見失う。

コア側は資源情報、トラフィックエンジニアリング、装置設定、障害検出、復旧を担う。RFC 3387 はネットワーク全体の情報を使う比較的集中した計算を検討したが、それを必然とはしなかった。中間機能の便益が、複雑性や不安定化という構造費用に勝つかを同時に問うた。

管理ドメインの境界では、競合事業者が協力する。サービス信号、会計、検証、実トラフィック測定、請求情報の移送が必要になる一方、内部能力を相手に公開したくない。二者間 SLA を多数並べても、測定尺度、時計、例外、復旧条件が異なれば、端から端の一つの保証にはならない。

帯域ブローカや信頼される第三者は、その摩擦を減らす案として登場する。認可、価格、支払い、検証を仲介できるかもしれない。ただし RFC 3387 は採用を義務づけていない。証拠を運ぶ役割が、各ドメインの内部判断を支配する権限へ膨張してはならない。

請求は後付けできない。文書はセキュリティとともにサービス設計の初期から扱うべきだとした。RFC 2975 の区別を使えば、会計は資源使用の記録、料金計算は価格規則の適用、請求は支払い要求、決済は債務の処理である。正確な使用記録でも、料金表、請求先、支払い、技術的履行まで証明しない。

DiffServ の PHB にも境界がある。各ホップの処理は重要な実装事実だが、RFC 3387 はそれが端から端の保証ではないと明言した。有料利用者が求めるのは経路全体の帯域、遅延、誤り率であり、一つのキューが期待どおり動いたという事実だけではない。

さらに、予約に参加しないベストエフォート利用者が費用を負う可能性がある。専用容量が空いていても共有されなければ、一般通信は利用できない。高収益クラスを優先する経済的誘因もある。これは実測された被害の主張ではなく、監視すべき構造的な圧力である。

Lu Heng の Running-Code Primacy は共通層の範囲を限定する。相互運用、認可、測定、安全に必要な決定可能な規則は共有する。価格や内部資源配分まで中央機関に委ねる必要はない。記録者、検証者、ブローカは証拠の交換を支援できるが、証拠の真実を創造する主権者ではない。

RFC 3387 が残したのは完成図ではなく、混同を防ぐ一覧である。パケット処理、利用資格、資源受入れ、境界引継ぎ、測定、会計、請求、支払い、アプリケーション結果は別々の事実だ。キューはパケットを区別できた。サービスを成立させるには、その周囲の受領書を失わずにつなぐ必要があった。

出典