要約

  • RFC 3290は、ルーター内のDiffserv処理を機能要素が接続された有向非巡回グラフとして表し、分類、計測、マーキング、キューイング、スケジューリング、破棄の流れを管理システムが記述できるようにした。
  • このグラフは意図的に情報モデルにとどまる。設定や監視のための共通表現であり、特定実装を要求せず、パケットが約束されたサービスを受けた証明にもならない。

コードポイントは処理経路の入口にすぎない

パケットヘッダーのDSCPは見つけやすい。しかし、この6ビット値だけから特定のルーターが次に何をするかを推定することはできない。DSCPがビヘイビア・アグリゲート分類器の分岐を選ぶ場合でも、トラフィックにはフィルター、メーター、マーキングや破棄のアクション、キュー、スケジューラーが待っている。

RFC 3290『Diffserv Informal Management Model』はこの違いを明示した。2002年の情報提供RFCは、ルーターのトラフィック調整とキュー動作を、機能的なデータパス要素からなる有向非巡回グラフとして説明する。分類器はストリームを分割でき、メーターは適合度に応じてパケットを別の出力へ送る。後段のアクションはマーキング、計数、破棄、集約を行い、キューとスケジューラーは送出時期や損失に関係する。

説明の単位は機能の組み合わせだ。DSCPはBA分類器の分岐選択を助ける一方、別の分類器は他のヘッダーフィールドを見ることもある。メーターの各適合レベルを異なるマーキング、キュー、破棄へつなぐこともできる。最終的な扱いは、機能どうしの接続とパラメーターによって決まり、ラベル単独では決まらない。

RFC 3290は低レベルの要素をTraffic Conditioning Block（TCB）にもまとめた。管理者はインターフェースの入口または出口で使うブロックを考え、直列または並列につなげる。TCBは入力と一つ以上の出力を持つ論理的な「ブラックボックス」という管理上の便宜であり、ルーター間で物理構成が共通だという主張ではない。

管理の地図であり、シリコンの設計図ではない

この留保がRFCの重要な境界だ。モデルはSNMPなどの設定・管理ツール向けの抽象化であり、ルーターの実装を拘束したり指定したりする意図はない。論理上のキューやメーターが物理的な部品と一対一に対応する必要もない。

抽象化によって異なる機器を同じ語彙で扱えるが、見えなくなるものもある。RFC 3290のルーティングコアは理想化された相互接続であり、実際のスイッチングファブリックの遅延、損失、過負荷は別途モデル化しなければならない。キューのパラメーターは論理的な振る舞いを表すだけで、実機のバッファー構造を明かさない。グラフは設定された処理を示せても、転送経路への正しい反映や輻輳時の結果を単独では証明しない。

メーターの表現が分かりやすい例だ。Diffservアーキテクチャでは、メーターをトラフィックの観測者として、アクションへの制御信号を送る存在と説明できる。RFC 3290では論理的な1対Nのデータパス分岐として描き、適合レベルごとの出力を次の要素へ接続する。著者らは、記述の違いは機能を変えないと述べている。経路を組み立てやすくする一方で、図の配線が実装回路と同じとは限らないことも示す。

RFC 3444は後に、抽象的な情報モデルと個別の管理プロトコル向けデータモデルの違いを整理した。その観点から読めば、RFC 3290は共有語彙と構造であって、パケット処理エンジンの設計命令ではない。

グラフが示すこと、示さないこと

このグラフは、意図された分類、調整、キューイングのつながりや、パラメーター、カウンター、管理オブジェクトを検討する助けになる。「プロファイル外」の枝も、次に接続された機能や最終的なキュー／破棄の動作が分からなければ、運用上の意味は定まらない。

ただし、設定グラフは証拠の一層にすぎない。実際のサービスを確かめるには、機器ごとの設定読み戻し、実装の動作、カウンターやパケット観測、サービス境界での測定が要る。DSCPは遅延の約束ではない。PHBの名称はキュー長の測定値ではない。管理モデルも負荷時にスケジューラーが意図通り動いた証明ではない。

普遍的なルーター設計と誤解しなくても、RFC 3290は有用だ。パケットのマーキングと送出の間にある処理ロジックを記述する方法を与えた。そのロジックをマーキング自体に縮約せず、意図を描いた図を実測された性能の証拠にすり替えないためである。

出典