要約
- RFC 3317は、DiffServ装置が対応する機能だけでなく、要素を連結できる深さ、許される接続、方向、キューやスケジューラの限界をPDPへ先に通知する構造を定めた。
- 能力通知は完全な実現可能性証明ではない。組み上げたポリシーが実装できなければPEPは失敗を返す必要があり、受理や保存だけではパケットの処遇もサービス品質も証明しない。
RFC 3317のデータパスは、個々の物理ポートから始まらない。インターフェースの型、役割の組み合わせ、入力か出力かという抽象から始まる。中央のポリシーサーバは、その抽象に対して処理の入口を指定する。再利用しやすい一方で、特定のカードや共有資源の現実は最後まで残る。
2003年にInformational RFCとして公開されたこの文書は、Differentiated Services向けのPolicy Information Baseを定義した。DiffServでは、パケットを分類し、流量を測り、DSCPを付けるなどのアクションを行い、必要に応じて廃棄し、キューへ入れ、スケジューラから送り出す。RFC 3317は、それぞれをProvisioning Classとそのインスタンスで表した。
処理には基本順序があった。classifier、meter、action、algorithmic dropper、queue、schedulerである。同種の段階へ戻る必要があれば、別のTraffic Conditioning Blockを連結する。各要素のNext属性が次の要素を指し、分類結果や計測結果ごとに経路が分岐する。表の集合でありながら、実質は有向グラフだった。
グラフの配線と数値パラメータは別の行に置かれた。meterはトークンバケットのrateやburstを持つ行を参照でき、schedulerは最小・最大レートの定義を参照できる。同じパラメータを複数の処理から使え、新しい方式を別PIBで足しやすい。しかし、参照先がすべて正しいことと、装置がその組み合わせを実行できることは同じではない。
そこでPEPからPDPへの能力通知が先行する。PEPは理解できるPRC、インターフェース型、role combination、capability setを伝えた。能力には方向があり、入力だけ、出力だけ、または両方向に適用できた。分類で見られる情報、profile外パケットへの処理、廃棄アルゴリズム、キュー数とバッファ、スケジューリング方式と入力数、最大レートの段数などが対象だった。
さらに、装置が連続して置ける機能要素の最大深さと、ある種類の要素の次に何を接続できるかも通知できた。ここが単なる機能一覧との違いである。classifierとqueueをそれぞれ持っていても、特定のmeterを挟んだ五段の経路を構成できるとは限らない。能力は部品の存在だけでなく、部品間の辺とパイプラインの長さを制約した。
PDPは通知を踏まえ、管理ドメイン、インターフェース型、役割、方向に合うポリシーを送った。dsDataPathTableは最初の要素を指定する。該当行がない場合やzeroDotZeroが指定された場合、その組み合わせでは通常のIP処理を続ける。処理しないことも、曖昧な空欄ではなくデータパス選択の一つとして表せた。
ただし、文書は能力モデルを万能にしなかった。通知クラスは装置ができることの「一般的な指針」であり、可能・不可能な全構成を示すとは限らないと明記した。キュー、バッファ、内部プロセッサ、接続方式が相互作用すれば、個別条件を満たすグラフでも失敗する。実装不能なポリシーを受け取ったPEPは、PDPへ失敗報告を返さなければならない。
したがって、能力通知と失敗報告は競合する証拠ではない。前者は設計探索の範囲を狭め、後者は不完全なモデルが完全な構成に出会ったときの最終判定になる。その間にも、コントローラが作ったグラフ、COPS-PR取引の応答、装置に残る状態、パケットが実際に通った処理、利用者の品質という別々の事実がある。
情報の向きが二つあるため、保護対象も二つあった。install対象の行は顧客契約やフィルタを示し、改変されればDiffServ動作が変わる。notify対象の能力行は装置の内部的な特徴を明かす。RFC 3317はPDPとPEPの間でIPsecを用いることに言及した。偽の能力は誤ったグラフを作らせ、偽のポリシーは資源配分そのものを変える。
この規格群は長期の主流にはならなかった。IESGは2016年、RFC 3317、Framework PIB、COPS-PR、SPPIをHistoricへ移した。理由は限定的な展開と、運用管理の中心がNETCONFとYANGへ移ったことだった。これは実装普及についての後年の証拠であり、2003年の文書から普及を推測してはならない理由でもある。
歴史的に残るのは、中央制御にも「装置からの反証」が必要だという設計である。能力モデルは計画を現実へ近づけるが、現実を完全には代理しない。型、方向、辺、深さを明示し、なお最後の拒否を保存する。そうして初めて、ポリシーの形と実行可能性を同じ言葉で扱わずに済む。
出典:RFC 3317、RFC 3318、RFC 3290、RFC 3084、RFC 3159、RFC 2475、2016年のIESGによる状態変更。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
