要約
- RFC 3060は、グループ、ルール、条件、アクションとその関係を扱う再利用可能な情報モデルを標準化した。一方、それらの属性から結果を導くアルゴリズムは共通モデルの範囲外だと明記した。
- PCIMは優先順位やアクション順序が必須か推奨かを表せるが、共通の実行エンジンではない。後続のRFC 3460が決定戦略などを追加しても、異なる装置が同じ結果を出した証拠にはならない。
同じルール名でも、同じ動作とは限らない
同じ名前のポリシー項目を受け取った二つのルーターが、同じ挙動になるとは限らない。装置ごとの能力、拡張、条件評価のコードが異なるからだ。2001年2月のRFC 3060「Policy Core Information Model (PCIM) Version 1」は、その記述と実行の隔たりを示している。
PCIMは情報の構造を定めた。クラスがポリシー項目を表し、関連クラスがインスタンス間の関係を示す。PolicyRuleは条件とアクションを結び、PolicyGroupはルールまたは別のグループをまとめる。優先順位は一般ルールと例外を区別できる。条件はANDの集合をORでまとめる形式、またはその逆で表せ、個々の条件は否定もできる。
RFCの例では、エンジニア部門の通信にBronzeサービスを与える一般ルールと、特定の一人にGoldサービスを与える例外が重なる。モデルはこの二つの条件と優先順位を記述できる。しかし実際の装置は条件を評価し、競合を解決し、選ばれたアクションを装置固有の設定へ変換しなければならない。
「宣言的」でも、結果を計算する手順は別
RFCはPCIMを宣言的なモデルと呼ぶが、その意味を直ちに限定する。モデルは属性と対象を定義する一方、属性から結果を出すアルゴリズムも、処理の明示的な手順も定義しない。アクションの望ましい順序や、それが必須か推奨かは記録できる。それでも評価手順を共通化するものではない。
その差は境界条件に出る。条件が欠けたらどうするか。未対応の拡張をどう扱うか。二つのルールが競合したらどちらを選ぶか。装置の能力が違うときに同じポリシーをどう処理するか。PCIMはベンダー固有の条件クラスやアクションクラスを拡張点として含めた。共通の土台を広げられる反面、土台の上に異なる意味を載せる余地も残る。
著者たちは設計上の理由も記録している。人が定義や診断をしやすい表現と、能力の異なる装置が処理しやすい簡潔さとの均衡である。当時のポリシー管理には集団的な経験が十分ではないため、完全性を追い求めるべきでないとした。まずVPNやQoSといった共通の要求を扱い、経験に応じて拡張していく考え方だった。
RFCは、IETF Policy Framework WGとDMTF Common Information Modelの活動にまたがる経緯にも触れ、LDAPv3ディレクトリなど具体的実装へのマッピングは後続文書が定めると説明する。つまりPCIMは実装への入力であり、採用済みのディレクトリやルーターを示す記録ではない。
周辺の標準は別の層を扱う
RFC 2753は、ポリシー判断を行うPolicy Decision Point(PDP)と、ネットワークで実際に適用するPolicy Enforcement Point(PEP)を分けた。RFC 2748は両者の要求・決定を運ぶCOPSプロトコルを定め、RFC 3084はCOPSでPolicy Information Baseをプロビジョニングする用途を定めた。これらは関連するが、PCIMそのものではない。情報モデル、通信プロトコル、設定データの供給は別の問いに答える。
だから、証拠も段階ごとに必要になる。リポジトリにルールがあること、PDPが評価したこと、PEPが決定を受け取ったこと、ルーターが設定を入れたことは別々の事実だ。モデル準拠のオブジェクトを見つけても、装置がどの版を読み、拡張を理解し、通信をどう扱ったのかは分からない。
後続版はモデルを更新した
2003年1月のRFC 3460はPCIMを更新した。新しい要素を追加し、一部を廃止・置換し、優先順位の表現を変え、管理者が指定する決定戦略を導入した。情報モデルが進化した証拠であり、その構造が固定されていなかったことを示す。
ただし、決定戦略を表す項目の追加は、装置間の実行一致を保証しない。モデル上で選択を記述できても、それぞれのPDPが同じ手順で解釈し、各PEPが同じ設定を受け入れるとは限らない。RFC 3198も、業務上の目的を装置固有のパラメーターへ変換する際に、ネットワークや装置能力に関する追加情報が要る場合があると説明する。
歴史的な主張はここにとどめたい。RFC 3060は異なる管理環境で再利用できるポリシー情報を目指しながら、共通の評価アルゴリズムは定めなかった。規格の公開と改訂は確認できるが、どの製品が実装したのか、実ネットワークで同じ判断が行われたのかは、この標準記録だけでは分からない。
相互運用性を確かめるには、どのクラスと拡張を使ったか、PDPがどの版を評価したか、競合ルールをどう裁いたか、PEPが何を設定し、パケットにどんな効果があったかを追う必要がある。共通モデルは語彙を揃える。それだけで結果まで揃うわけではない。
出典
- RFC 3060 — Policy Core Information Model, Version 1
- RFC Editor — RFC 3060 情報ページ
- Datatracker — RFC 3060
- RFC 3460 — Policy Core Information Model Extensions
- RFC 2753 — A Framework for Policy-based Admission Control
- RFC 2748 — The COPS Protocol
- RFC 3084 — COPS Usage for Policy Provisioning
- RFC 3198 — Terminology for Policy-Based Management
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
