[要約] RFC 2753は、ポリシーベースのアドミッション制御のためのフレームワークを提供しています。このRFCの目的は、ネットワークリソースの効果的な管理と制御を可能にすることです。
Network Working Group R. Yavatkar
Request for Comments: 2753 Intel
Category: Informational D. Pendarakis
IBM
R. Guerin
U. Of Pennsylvania
January 2000
A Framework for Policy-based Admission Control
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
The IETF working groups such as Integrated Services (called "int-serv") and RSVP [1] have developed extensions to the IP architecture and the best-effort service model so that applications or end users can request specific quality (or levels) of service from an internetwork in addition to the current IP best-effort service. Recent efforts in the Differentiated Services Working Group are also directed at the definition of mechanisms that support aggregate QoS services. The int-serv model for these new services requires explicit signaling of the QoS (Quality of Service) requirements from the end points and provision of admission and traffic control at Integrated Services routers. The proposed standards for RSVP [RFC 2205] and Integrated Services [RFC 2211, RFC 2212] are examples of a new reservation setup protocol and new service definitions respectively. Under the int-serv model, certain data flows receive preferential treatment over other flows; the admission control component only takes into account the requester's resource reservation request and available capacity to determine whether or not to accept a QoS request. However, the int-serv mechanisms do not include an important aspect of admission control: network managers and service providers must be able to monitor, control, and enforce use of network resources and services based on policies derived from criteria such as the identity of users and applications, traffic/bandwidth requirements, security considerations, and time- of-day/week. Similarly, diff-serv mechanisms also need to take into account policies that involve various criteria such as customer identity, ingress points, and so on.
IETFアプリケーションやエンドユーザーが特定の品質（またはレベル）を要求することができるように、このような統合サービス（「INT-SERV」と呼ばれる）と、RSVPなどのワーキンググループは、[1] IPアーキテクチャとベストエフォート型サービスモデルへの拡張機能を開発したの現在のIPベストエフォート型サービスに加えて、インターネットからのサービス。差別化サービスワーキンググループでの最近の努力も集約QoSサービスをサポートするメカニズムの定義に向けられています。これらの新しいサービスのためにINT-SERVモデルは、QoS（サービス品質）のエンドポイントおよびサービス統合型ルータでの入場とトラフィック制御の提供からの要求事項の明示的なシグナリングを必要とします。提案されたRSVPのための標準[RFC 2205]および統合サービス[RFC 2211、RFC 2212]は、それぞれ、新たな予約セットアッププロトコルや新しいサービスの定義の例です。 INT-SERVモデルでは、特定のデータフローが他のフロー上の優遇措置を受けます。アドミッション制御のコンポーネントのみを考慮したQoS要求を受け入れるか否かを判断するために、要求者のリソース予約要求および使用可能な容量をとります。制御、ネットワーク管理者やサービスプロバイダが監視できるようにする必要があり、そのような利用者の身元などの基準から派生したポリシーに基づいてネットワークリソースおよびサービスの使用を強制：しかし、INT-SERVメカニズムは、アドミッション制御の重要な側面が含まれていません。やアプリケーション、トラフィック/帯域幅要件、セキュリティ上の考慮事項、およびタイムの日/週。同様に、差分-SERVメカニズムはまた、そのようなので、上の顧客のID、進入ポイント、などさまざまな基準を伴うアカウントポリシーを考慮する必要があります。
This document is concerned with specifying a framework for providing policy-based control over admission control decisions. In particular, it focuses on policy-based control over admission control using RSVP as an example of the QoS signaling mechanism. Even though the focus of the work is on RSVP-based admission control, the document outlines a framework that can provide policy-based admission control in other QoS contexts. We argue that policy-based control must be applicable to different kinds and qualities of services offered in the same network and our goal is to consider such extensions whenever possible.
このドキュメントでは、入場コントロール決定にポリシーベースの制御を提供するためのフレームワークを指定すると懸念しています。特に、機構をQoSシグナリングの一例としてRSVPを使用して、アドミッションコントロールオーバーポリシーベースの制御に焦点を当てています。仕事の焦点は、RSVPベースのアドミッションコントロール上にあるにもかかわらず、文書は他のQoSコンテキストでポリシーベースのアドミッション制御を提供することができますフレームワークの概要を説明します。私たちは、ポリシーベースの制御は、同じネットワークに提供されるサービスの種類と質に適用する必要があり、私たちの目標は、可能な限りそのような拡張を考慮することであると主張しています。
We begin with a list of definitions in Section 2. Section 3 lists the requirements and goals of the mechanisms used to control and enforce access to better QoS. We then outline the architectural elements of the framework in Section 4 and describe the functionality assumed for each component. Section 5 discusses example policies, possible scenarios, and policy support needed for those scenarios. Section 6 specifies the requirements for a client-server protocol for communication between a policy server (PDP) and its client (PEP) and evaluates the suitability of some existing protocols for this purpose.
私たちは、3つのリストセクション2節で定義のリストとのより良いのQoSへのアクセスを制御し、強制するために使用されるメカニズムの要件と目標を開始します。我々は、次に、第4のフレームワークのアーキテクチャ要素を概説し、各コンポーネントの想定機能を記述する。第5節では、これらのシナリオのために必要な例ポリシー、可能なシナリオ、およびポリシーのサポートについて説明します。第6節は、ポリシーサーバ（PDP）とそのクライアント（PEP）との間の通信のためのクライアントサーバプロトコルのための要件を規定し、この目的のために、いくつかの既存のプロトコルの適合性を評価します。
The following is a list of terms used in this document.
以下は、このドキュメントで使用される用語のリストです。
- Administrative Domain: A collection of networks under the same administrative control and grouped together for administrative purposes.
- 管理ドメイン：同じ管理下のネットワークの収集と管理目的のために一緒にグループ化されました。
- Network Element or Node: Routers, switches, hubs are examples of network nodes. They are the entities where resource allocation decisions have to be made and the decisions have to be enforced. A RSVP router which allocates part of a link capacity (or buffers) to a particular flow and ensures that only the admitted flows have access to their reserved resources is an example of a network element of interest in our context.
- ネットワーク要素またはノード：ルータ、スイッチ、ハブ、ネットワーク・ノードの例です。彼らは、資源配分の決定を行わなければならないとの決定を施行する必要があるエンティティです。特定のフローへのリンク容量（またはバッファ）の一部を割り当て、唯一許可されたフローは、その予約されたリソースへのアクセス権を持っていることを保証RSVPルータは、我々の文脈で関心のネットワーク要素の一例です。
In this document, we use the terms router, network element, and network node interchangeably, but the should all be interpreted as references to a network element.
この文書では、我々は、互換的用語ルータ、ネットワーク要素、およびネットワーク・ノードを使用しますが、インクルードは、すべてのネットワーク要素への参照として解釈されるべきです。
- QoS Signaling Protocol: A signaling protocol that carries an admission control request for a resource, e.g., RSVP.
- QoSシグナリングプロトコル：リソースのための受付制御要求、例えば、RSVPを運ぶシグナリングプロトコル。
- Policy: The combination of rules and services where rules define the criteria for resource access and usage.
- ポリシー：ルールは、リソースへのアクセスと利用のための基準を定義するルールとサービスの組み合わせ。
- Policy control: The application of rules to determine whether or not access to a particular resource should be granted.
- ポリシー制御：特定のリソースへのアクセスかどうかを判断するためのルールの適用が認められるべきです。
- Policy Object: Contains policy-related information such as policy elements and is carried in a request or response related to a resource allocation decision.
- ポリシーオブジェクト：そのようなポリシー要素としてポリシー関連情報を含み、リソース割当決定に関連する要求または応答で搬送されます。
- Policy Element: Subdivision of policy objects; contains single units of information necessary for the evaluation of policy rules. A single policy element may carry an user or application identification whereas another policy element may carry user credentials or credit card information. The policy elements themselves are expected to be independent of which QoS signaling protocol is used.
- ポリシー要素：ポリシーオブジェクトの区;ポリシールールの評価に必要な情報の単一単位が含まれています。別のポリシーエレメントは、ユーザーの資格情報やクレジットカード情報を運ぶことができるのに対し、単一のポリシー要素は、ユーザまたはアプリケーション識別情報を搬送することができます。ポリシー要素自体は、どのプロトコルが使用されているQoSシグナリングとは無関係であることが期待されます。
- Policy Decision Point (PDP): The point where policy decisions are made.
- ポリシー決定ポイント（PDP）：政策決定がなされるポイント。
- Policy Enforcement Point (PEP): The point where the policy decisions are actually enforced.
- ポリシー実行ポイント（PEP）：政策決定が実際に施行されているポイント。
- Policy Ignorant Node (PIN): A network element that does not explicitly support policy control using the mechanisms defined in this document.
- ポリシー無知なノード（PIN）：明示的にこの文書で定義されたメカニズムを使用してポリシー制御をサポートしていないネットワーク要素。
- Resource: Something of value in a network infrastructure to which rules or policy criteria are first applied before access is granted. Examples of resources include the buffers in a router and bandwidth on an interface.
- リソース：ネットワークインフラストラクチャ内の値の何かの規則またはアクセスが許可される前に、ポリシーの基準を最初に適用されます。リソースの例は、インターフェイス上のルータおよび帯域幅内のバッファが含まれます。
- Service Provider: Controls the network infrastructure and may be responsible for the charging and accounting of services.
- サービスプロバイダー：ネットワークインフラストラクチャをコントロールし、サービスの充電および会計を担当することがあります。
- Soft State Model - Soft state is a form of the stateful model that times out installed state at a PEP or PDP. It is an automatic way to erase state in the presence of communication or network element failures. For example, RSVP uses the soft state model for installing reservation state at network elements along the path of a data flow.
- ソフトステートモデル - ソフト状態は時間が出PEPやPDPの状態を設置しステートフルモデルの形です。これは、通信又はネットワーク構成要素の故障の存在下での状態を消去するための自動方法です。例えば、RSVPは、データフローの経路に沿ったネットワーク要素において予約状態をインストールするためのソフト状態モデルを使用します。
- Installed State: A new and unique request made from a PEP to a PDP that must be explicitly deleted.
- インストールされた状態：明示的に削除する必要がありPEPからPDPに作られた新しい、ユニークなリクエスト。
- Trusted Node: A node that is within the boundaries of an administrative domain (AD) and is trusted in the sense that the admission control requests from such a node do not necessarily need a PDP decision.
- 信頼されたノード：管理ドメイン（AD）の境界内であり、そのようなノードからのアドミッション制御要求は必ずしもPDPの決定を必要としないという意味で信頼されているノード。
In this section, we describe the goals and requirements of mechanisms and protocols designed to provide policy-based control over admission control decisions.
このセクションでは、目標とアドミッション制御の決定にポリシーベースの制御を提供するために設計されたメカニズムとプロトコルの要件について説明します。
- Policies vs Mechanisms: An important point to note is that the framework does not include any discussion of any specific policy behavior or does not require use of specific policies. Instead, the framework only outlines the architectural elements and mechanisms needed to allow a wide variety of possible policies to be carried out.
- メカニズム対ポリシー：重要な点は、注目すべきは、フレームワークは、特定のポリシーの動作のいずれかの議論が含まれていないか、特定のポリシーを使用する必要がないということです。代わりに、フレームワークは、唯一の可能な政策のさまざまなを行うことができるようにするために必要な建築要素とメカニズムの概要を説明します。
- RSVP-specific: The mechanisms must be designed to meet the policy-based control requirements specific to the problem of bandwidth reservation using RSVP as the signaling protocol. However, our goal is to allow for the application of this framework for admission control involving other types of resources and QoS services (e.g., Diff-Serv) as long as we do not diverge from our central goal.
- RSVP特異：メカニズムは、シグナリングプロトコルとしてRSVPを使用して、帯域予約の問題に対する特定のポリシーベースの制御要件を満たすように設計されなければなりません。しかし、私たちの目標は限り、我々は中央の目標から乖離していないなどのリソースおよびQoSサービス（例えば、差分-SERV）の他のタイプを含むアドミッション制御のために、このフレームワークの適用を可能にすることです。
- Support for preemption: The mechanisms designed must include support for preemption. By preemption, we mean an ability to remove a previously installed state in favor of accepting a new admission control request. For example, in the case of RSVP, preemption involves the ability to remove one or more currently installed reservations to make room for a new resource reservation request.
- プリエンプションのサポート：設計されたメカニズムは、プリエンプションのサポートが含まれている必要があります。先取りすることで、私たちは、新しいアドミッション制御要求を受け入れるの賛成で、以前にインストールされた状態を除去する能力を意味します。例えば、RSVPの場合、プリエンプションは、新しいリソース予約要求のための部屋を作るために、1つ以上の現在インストールされている予約を除去する能力を必要とします。
- Support for many styles of policies: The mechanisms designed must include support for many policies and policy configurations including bi-lateral and multi-lateral service agreements and policies based on the notion of relative priority. In general, the determination and configuration of viable policies are the responsibility of the service provider.
- 政策の多くのスタイルのサポート：設計されたメカニズムは、相対的な優先順位の概念に基づいて横バイとマルチラテラルサービス契約やポリシーなど、多くのポリシーとポリシー設定のサポートが含まれている必要があります。一般的には、決意と実行可能な政策の構成は、サービスプロバイダの責任です。
- Provision for Monitoring and Accounting Information: The mechanisms must include support for monitoring policy state, resource usage, and provide access information. In particular, mechanisms must be included to provide usage and access information that may be used for accounting and billing purposes.
- 監視と会計情報のための引当金：メカニズムは、ポリシー状態、リソースの使用状況を監視するためのサポートが含まれ、アクセス情報を提供する必要があります。具体的には、機構は、使用を提供し、課金および請求の目的のために使用することができる情報にアクセスするために含まれなければなりません。
- Fault tolerance and recovery: The mechanisms designed on the basis of this framework must include provisions for fault tolerance and recovery from failure cases such as failure of PDPs, disruption in communication including network partitions (and subsequent merging) that separate a PDP from its associated PEPs.
- 耐障害性と復旧：このフレームワークに基づいて設計されたメカニズムは、その関連のPDPを分離し、このようなプラズマディスプレイパネルの故障、ネットワークパーティション（およびその後のマージ）を含む通信の中断などの故障ケースからフォールトトレランスおよび回復のための規定を含まなければなりませんPEP。
- Support for Policy-Ignorant Nodes (PINs): Support for the mechanisms described in this document should not be mandatory for every node in a network. Policy based admission control could be enforced at a subset of nodes, for example the boundary nodes within an administrative domain. These policy capable nodes would function as trusted nodes from the point of view of the policy-ignorant nodes in that administrative domain.
- ポリシー無知ノード（ピン）のサポート：この文書で説明されたメカニズムのサポートは、ネットワーク内のすべてのノードのために必須であるべきではありません。ポリシーベースのアドミッション制御は、例えば、管理ドメイン内の境界ノードについて、ノードのサブセットに適用することができます。これらの政策対応ノードは、管理ドメイン内のポリシー・無知ノードの観点から信頼されるノードとして機能します。
- Scalability: One of the important requirements for the mechanisms designed for policy control is scalability. The mechanisms must scale at least to the same extent that RSVP scales in terms of accommodating multiple flows and network nodes in the path of a flow. In particular, scalability must be considered when specifying default behavior for merging policy data objects and merging should not result in duplicate policy elements or objects. There are several sensitive areas in terms of scalability for policy control over RSVP. First, not every policy aware node in an infrastructure should be expected to contact a remote PDP. This would cause potentially long delays in verifying requests that must travel up hop by hop. Secondly, RSVP is capable of setting up resource reservations for multicast flows. This implies that the policy control model must be capable of servicing the special requirements of large multicast flows. Thus, the policy control architecture must scale at least as well as RSVP based on factors such as the size of RSVP messages, the time required for the network to service an RSVP request, local processing time required per node, and local memory consumed per node.
- スケーラビリティ：ポリシー制御のために設計されたメカニズムのための重要な要件の一つは、スケーラビリティです。機構は、少なくとも流路に複数のフロー及びネットワークノードを収容するという点でスケールをRSVP同程度に拡大しなければなりません。ポリシーデータオブジェクトをマージし、重複したポリシー要素またはオブジェクトになってはならないマージするためのデフォルトの動作を指定するときに、特に、拡張性を考慮しなければなりません。 RSVP以上のポリシー制御のための拡張性の面でいくつかの敏感な部分があります。まず、インフラでなく、すべてのポリシーを認識したノードは、リモートPDPに連絡することが期待されなければなりません。これはホップでホップを移動しなければならない要求を検証する際に潜在的に長い遅延が発生します。第二に、RSVPは、マルチキャストフローのためのリソース予約を設定することができます。これは、ポリシー制御モデルが大マルチキャストフローの特別な要件にサービスを提供することが可能でなければならないことを意味しています。したがって、ポリシー制御アーキテクチャは、少なくともならびにRSVPメッセージのサイズ、RSVP要求を、ノードごとに必要なローカル処理時間にサービスを提供するネットワークのために必要な時間、及びノード当たりに消費ローカルメモリなどの要因に基づいて、RSVPを拡張しなければなりません。
- Security and denial of service considerations: The policy control architecture must be secure as far as the following aspects are concerned. First, the mechanisms proposed under the framework must minimize theft and denial of service threats. Second, it must be ensured that the entities (such as PEPs and PDPs) involved in policy control can verify each other's identity and establish necessary trust before communicating.
- セキュリティとサービスの考慮事項の拒否：ポリシー制御アーキテクチャは限り以下の側面が懸念しているとして、安全でなければなりません。まず、フレームワークの下で提案されたメカニズムは、サービスの脅威の盗難や拒否を最小限に抑える必要があります。第二に、ポリシー制御に関与する（例えばのPEPとPDPのような）エンティティが互いの身元を確認し、通信する前に必要な信頼関係を確立できることを確実にしなければなりません。
The two main architectural elements for policy control are the PEP (Policy Enforcement Point) and the PDP (Policy Decision Point). Figure 1 shows a simple configuration involving these two elements; PEP is a component at a network node and PDP is a remote entity that may reside at a policy server. The PEP represents the component that always runs on the policy aware node. It is the point at which policy decisions are actually enforced. Policy decisions are made primarily at the PDP. The PDP itself may make use of additional mechanisms and protocols to achieve additional functionality such as user authentication, accounting, policy information storage, etc. For example, the PDP is likely to use an LDAP-based directory service for storage and retrieval of policy information[6]. This document does not include discussion of these additional mechanisms and protocols and how they are used.
ポリシー制御のための2つの主要アーキテクチャ要素は、PEP（ポリシー実行ポイント）とPDP（ポリシー決定ポイント）です。図1は、これら2つの要素を含む単純な構成を示す図です。 PEPは、ネットワークノードの成分であり、PDPはポリシーサーバに常駐することができる遠隔エンティティです。 PEPは常に政策を意識ノードで実行コンポーネントを表します。これは、政策決定が実際に施行されている点です。政策決定は、主にPDPで作られています。 PDP自体が追加のメカニズムとプロトコルの使用は、例えば、等のユーザ認証、アカウンティング、ポリシー情報記憶、などの追加機能を達成するために行うことができる、PDPはポリシー情報の記憶及び検索のためのLDAPベースのディレクトリサービスを使用する可能性があります[6]。この文書では、これらの追加のメカニズムとプロトコルとそれらがどのように使用されているの議論が含まれていません。
The basic interaction between the components begins with the PEP. The PEP will receive a notification or a message that requires a policy decision. Given such an event, the PEP then formulates a request for a policy decision and sends it to the PDP. The request for policy control from a PEP to the PDP may contain one or more policy elements (encapsulated into one or more policy objects) in addition to the admission control information (such as a flowspec or amount of bandwidth requested) in the original message or event that triggered the policy decision request. The PDP returns the policy decision and the PEP then enforces the policy decision by appropriately accepting or denying the request. The PDP may also return additional information to the PEP which includes one or more policy elements. This information need not be associated with an admission control decision. Rather, it can be used to formulate an error message or outgoing/forwarded message.
コンポーネント間の基本的な相互作用は、PEPで始まります。 PEPは、通知や政策決定を要求するメッセージが表示されます。このようなイベントを考えると、PEPは、政策決定のための要求を策定し、PDPに送信します。 PEPからPDPにポリシー・コントロールのための要求は、元のメッセージに（例えば、要求された帯域幅のフロースペックや量など）アドミッション制御情報に加えて、1つのまたは複数のポリシー要素を（1つまたは複数のポリシーオブジェクトにカプセル化された）を含んでいてもよい、または政策決定の要求をトリガしたイベント。 PDPはポリシー決定を返し、PEPは、次いで適切要求を受け入れるか拒否することによってポリシー決定を施行します。 PDPはまた、1つまたは複数のポリシー要素を含むPEPに追加情報を返すことができます。この情報は、アドミッション制御の決定に関連付けする必要はありません。むしろ、エラー・メッセージまたは発信/転送メッセージを定式化するために使用することができます。
________________ Policy server
| | ______
| Network Node | | |------------->
| _____ | | | May use LDAP,SNMP,.. for accessing
| | | | | | policy database, authentication,etc.
| | PEP |<-----|------->| PDP |------------->
| |_____| | |_____|
| |
|________________|
Figure 1: A simple configuration with the primary policy control architecture components. PDP may use additional mechanisms and protocols for the purpose of accounting, authentication, policy storage, etc.
図1：プライマリポリシー制御アーキテクチャコンポーネントと簡単な構成。 PDPは、アカウンティング、認証、ポリシー記憶、等の目的のために追加のメカニズムおよびプロトコルを使用してもよいです
The PDP might optionally contact other external servers, e.g., for accessing configuration, user authentication, accounting and billing databases. Protocols defined for network management (SNMP) or directory access (LDAP) might be used for this communication. While the specific type of access and the protocols used may vary among different implementations, some of these interactions will have network-wide implications and could impact the interoperability of different devices.
PDPは、コンフィギュレーション、ユーザー認証、会計および課金データベースにアクセスするために、例えば、接触その他の外部のサーバーをオプションかもしれません。ネットワーク管理（SNMP）またはディレクトリアクセス（LDAP）のために定義されたプロトコルは、この通信のために使用されるかもしれません。使用されるアクセスの特定のタイプ及びプロトコルが異なる実装の間で変化し得るが、これらの相互作用の一部は、ネットワーク全体の意味を有し、異なるデバイスの相互運用性に影響を与える可能性があります。
Of particular importance is the "language" used to specify the policies implemented by the PDP. The number of policies applicable at a network node might potentially be quite large. At the same time, these policies will exhibit high complexity, in terms of number of fields used to arrive at a decision, and the wide range of decisions. Furthermore, it is likely that several policies could be applicable to the same request profile. For example, a policy may prescribe the treatment of requests from a general user group (e.g., employees of a company) as well as the treatment of requests from specific members of that group (e.g., managers of the company). In this example, the user profile "managers" falls within the specification of two policies, one general and one more specific.
特に重要なのは、PDPによって実装されるポリシーを指定するために使用される「言語」です。ネットワークノードで適用可能なポリシーの数は、潜在的に非常に大きくなる可能性があります。同時に、これらのポリシーは、意思決定に到達するために使用されたフィールドの数、および意思決定の広い範囲の面で、高い複雑さを示すであろう。さらに、いくつかのポリシーが同じ要求プロファイルに適用できると思われます。例えば、ポリシーは、一般のユーザグループからの要求の処理を規定してもよい（例えば、会社の従業員）並びにそのグループの特定のメンバーからのリクエストの処理（例えば、会社の経営）。この例では、ユーザプロファイル「マネージャー」は、2つのポリシー、一つの一般的と一つ以上の特定の仕様内に入ります。
In order to handle the complexity of policy decisions and to ensure a coherent and consistent application of policies network-wide, the policy specification language should ensure unambiguous mapping of a request profile to a policy action. It should also permit the specification of the sequence in which different policy rules should be applied and/or the priority associated with each one. Some of these issues are addressed in [6].
政策決定の複雑さに対処するために、ネットワーク全体のポリシーの一貫性と一貫性のあるアプリケーションを確保するためには、政策の仕様言語は、ポリシーアクションを要求プロファイルの明確なマッピングを確認する必要があります。それはまた、異なるポリシールールが適用されるべき順序および/またはそれぞれに関連付けられた優先順位の指定を可能にするはずです。これらの問題のいくつかは、[6]で扱われています。
In some cases, the simple configuration shown in Figure 1 may not be sufficient as it might be necessary to apply local policies (e.g., policies specified in access control lists) in addition to the policies applied at the remote PDP. In addition, it is possible for the PDP to be co-located with the PEP at the same network node. Figure 2 shows the possible configurations.
いくつかのケースでは、ローカルポリシーを適用する必要があるかもしれないように、図1に示した簡単な構成では十分ではないかもしれない（例えば、アクセス制御リストに指定されたポリシー）リモートPDPに適用されるポリシーに加えました。 PDPは、同じネットワークノードでPEPと同じ場所に配置されるのに加えて、それが可能です。図2は、可能な構成を示しています。
The configurations shown in Figures 1 and 2 illustrate the flexibility in division of labor. On one hand, a centralized policy server, which could be responsible for policy decisions on behalf of multiple network nodes in an administrative domain, might be implementing policies of a wide scope, common across the AD. On the other hand, policies which depend on information and conditions local to a particular router and which are more dynamic, might be better implemented locally, at the router.
図1および図2に示す構成は、分業の柔軟性を示します。一方では、管理ドメイン内の複数のネットワーク・ノードに代わって政策決定に関与している可能性がある集中管理ポリシーサーバは、AD間で共通の広い範囲のポリシーを実装することがあります。一方、よりダイナミックで特定のルータにローカルな情報や条件に依存ポリシーとは、より良いルータで、ローカルに実装される可能性があります。
________________ ____________________
| | | |
| Network Node | Policy Server | Network Node |
| _____ | _____ | _____ _____ |
| | | | | | | | | | | |
| | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | |
| |_____| | |_____| | |_____| |_____| |
| ^ | | |
| | _____ | |____________________|
| \-->| | |
| | LPDP| |
| |_____| |
| |
|________________|
Figure 2: Two other possible configurations of policy control architecture components. The configuration on the left shows a local decision point at a network node and the configuration on the right shows PEP and PDP co-located at the same node.
図2：ポリシー制御アーキテクチャコンポーネントの他の二つの可能な構成。左側の構成は、ネットワークノードのローカル決定点を示し、右側の構成は、PEPとPDPが同じノードで同じ場所に配置示します。
If it is available, the PEP will first use the LPDP to reach a local decision. This partial decision and the original policy request are next sent to the PDP which renders a final decision (possibly, overriding the LPDP). It must be noted that the PDP acts as the final authority for the decision returned to the PEP and the PEP must enforce the decision rendered by the PDP. Finally, if a shared state has been established for the request and response between the PEP and PDP, it is the responsibility of the PEP to notify the PDP that the original request is no longer in use.
それが利用可能な場合、PEPは、最初にローカルの決定に到達するためにLPDPを使用します。この部分的な決定と元のポリシー要求は、次の（おそらく、LPDPをオーバーライド）最終決定をレンダリングPDPに送られます。意思決定のための最終的な権限は、PEPに戻り、PEPはPDPによってレンダリング決定を執行しなければならないとして、PDPが作用することに留意しなければなりません。共有状態は、PEPとPDPの間で要求および応答のために確立されていれば最後に、元の要求が使用中でなくなったことをPDPに通知しないようにPEPの責任です。
Unless otherwise specified, we will assume the configuration shown on the left in Figure 2 in the rest of this document.
特に指定しない限り、私たちは、この文書の残りの部分では、図2の左側のような構成を想定しています。
Under this policy control model, the PEP module at a network node must use the following steps to reach a policy decision:
このポリシー制御モデルでは、ネットワーク・ノードでのPEPモジュールは、政策決定に到達するために、次の手順を使用する必要があります。
1. When a local event or message invokes PEP for a policy decision, the PEP creates a request that includes information from the message (or local state) that describes the admission control request. In addition, the request includes appropriate policy elements as described below.
ローカルイベントまたはメッセージがポリシー決定のためにPEPを呼び出し1、PEPは、アドミッション制御要求を説明するメッセージ（またはローカル状態）からの情報を含む要求を作成します。また、要求は、以下に説明するように、適切なポリシー要素を含みます。
2. The PEP may consult a local configuration database to identify a set of policy elements (called set A) that are to be evaluated locally. The local configuration specifies the types of policy elements that are evaluated locally. The PEP passes the request with the set A to the Local Decision point (LPDP) and collects the result of the LPDP (called "partial result" and referred to as D(A) ).
2. PEPは、局所的に評価されるポリシー要素（セットAと呼ばれる）のセットを識別するためのローカル構成データベースを調べることができます。ローカル設定は、ローカルで評価されているポリシー要素の種類を指定します。 PEPは、ローカル決定ポイントにセットA（LPDP）で要求を渡し、LPDP（「部分的な結果」と呼ばれ、D（A）とも呼ばれる）の結果を収集します。
3. The PEP then passes the request with ALL the policy elements and D(A) to the PDP. The PDP applies policies based on all the policy elements and the request and reaches a decision (let us call it D(Q)). It then combines its result with the partial result D(A) using a combination operation to reach a final decision.
3. PEPは、次いでPDPのすべてのポリシー要素およびD（A）との要求を渡します。 PDPは、すべてのポリシー要素と要求に基づいてポリシーを適用し、意思決定に到達した（私たちはD（Q）、それを呼びましょう）。これは、最終的な決定に到達するために組合せ操作を使用して部分的結果D（A）との結果を組み合わせます。
4. The PDP returns the final policy decision (obtained from the combination operation) to the PEP.
前記PDPはPEPに（組み合わせ動作から得られた）最終的なポリシー決定を返します。
Note that in the above model, the PEP MUST contact the PDP even if no (or NULL) policy objects are received in the admission control request. This requirement helps ensure that a request cannot bypass policy control by omitting policy elements in a reservation request. However, "short circuit" processing is permitted, i.e., if the result of D(A), above, is "no", then there is no need to proceed with further policy processing at the PDP. Still, the PDP must be informed of the failure of local policy processing. The same applies to the case when policy processing is successful but admission control (at the resource management level due to unavailable capacity) fails; again the PDP has to be informed of the failure.
全く（またはNULL）ポリシーオブジェクトはアドミッション制御要求に受信されない場合でも、上記のモデルでは、PEPは、PDPに連絡しなければならないことに留意されたいです。この要件は、要求が予約要求にポリシー要素を省略することにより、ポリシー制御をバイパスすることができないようにします。しかし、処理が許可されている「短絡」、即ち、D（A）の結果であれば、上記、「NO」である場合、PDPでさらにポリシーの処理を続行する必要はありません。それでも、PDPは、ローカルポリシー処理の失敗を通知する必要があります。ポリシー処理は成功したが（使用不能容量によるリソース管理レベルで）許可制御に失敗した場合も同様でケースに適用されます。再びPDPは、障害が通知する必要があります。
It must also be noted that the PDP may, at any time, send an asynchronous notification to the PEP to change an earlier decision or to generate a policy error/warning message.
また、PDPは、いつでも、以前の決定を変更したり、ポリシーのエラー/警告メッセージを生成するために、PEPへの非同期通知を送ることができることに留意しなければなりません。
In the case of a RSVP router, Figure 3 shows the interaction between a PEP and other int-serv components within the router. For the purpose of this discussion, we represent all the components of RSVP-related processing by a single RSVP module, but a more detailed discussion of the exact interaction and interfaces between RSVP and the PEP is provided in a separate document [3].
RSVPルータの場合には、図3は、ルータ内のPEP及び他のINT-SERVコンポーネント間の相互作用を示します。この議論の目的のために、我々は、単一のRSVPモジュールによってRSVP関連処理のすべてのコンポーネントを表すが、RSVPとPEPとの間の正確な相互作用とインターフェースのより詳細な議論は、別の文書[3]で提供されます。
______________________________
| |
| Router |
| ________ _____ | _____
| | | | | | | |
| | RSVP |<------->| PEP |<--|---------->| PDP |
| |________| |_____| | |_____|
| ^ |
| | Traffic control |
| | _____________ |
| \---->| _________ | |
| | |capacity | | |
| | | ADM CTL | | |
| | |_________| | |
--|----------->| ____ ____ | |
| Data | | PC | PS | | |
| | |____|____| | |
| |_____________| |
| |
|______________________________|
Figure 3: Relationship between PEP and other int-serv components within an RSVP router. PC -- Packet Classifier, PS -- Packet Scheduler
図3：RSVPルータ内のPEP及び他のINT-SERVコンポーネント間の関係。 PC - パケット分類器、PS - パケットスケジューラ
When a RSVP message arrives at the router (or an RSVP related event requires a policy decision), the RSVP module is expected to hand off the request (corresponding to the event or message) to its PEP module. The PEP will use the PDP (and LPDP) to obtain the policy decision and communicate it back to the RSVP module.
RSVPメッセージは、ルータに到着（又はRSVP関連イベントは、ポリシー決定を必要とする）場合、RSVPモジュールはそのPEPモジュール（イベントまたはメッセージに対応する）要求をハンドオフすることが期待されます。 PEPはポリシー決定を得るために、PDP（およびLPDP）を使用し、RSVPモジュールにそれをバック通信します。
Typically, PDP returns the final policy decision based on an admission control request and the associated policy elements. However, it should be possible for the PDP to sometimes ask the PEP (or the admission control module at the network element where PEP resides) to generate policy-related error messages. For example, in the case of RSVP, the PDP may accept a request and allow installation and forwarding of a reservation to a previous hop, but, at the same time, may wish to generate a warning/error message to a downstream node (NHOP) to warn about conditions such as "your request may have to be torn down in 10 mins, etc." Basically, an ability to create policy-related errors and/or warnings and to propagate them using the native QoS signaling protocol (such as RSVP) is needed. Such a policy error returned by the PDP must be able to also specify whether the reservation request should still be accepted, installed, and forwarded to allow continued normal RSVP processing. In particular, when a PDP sends back an error, it specifies that:
一般的に、PDPは、受付制御要求および関連するポリシー要素に基づいて、最終的なポリシー決定を返します。 PDPは、時々ポリシー関連のエラーメッセージを生成するために、PEP（又はPEPが存在するネットワーク要素におけるアドミッション制御モジュール）を依頼するためしかし、それが可能でなければなりません。例えば、RSVPの場合には、PDPは、要求を受け入れることができ、前のホップに予約のインストールおよび転送を可能にする、しかし、同時に、下流ノード（NHOPに警告/エラーメッセージを生成することを望むかもしれません）、このような「あなたの要求は10分などに取り壊さなければならないことがある」などの条件について警告します基本的に、ポリシー関連のエラーおよび/または警告を作成すると（例えばRSVPのような）シグナリングプロトコルネイティブQoSを使用して伝播する能力が必要です。 PDPによって返されるようなポリシー誤差も予約要求が依然として受け入れられインストールされ、継続的な通常のRSVP処理を可能にするために、転送されるべきかを指定することができなければなりません。 PDPがエラーを返したとき、特に、それがあることを指定します：
1. the message that generated the admission control request should be processed further as usual, but an error message (or warning) be sent in the other direction and include the policy objects supplied in that error message
1.アドミッション制御要求を生成したメッセージは通常通りさらに処理されなければならないが、エラーメッセージ（または警告）が他の方向に送信され、そのエラーメッセージに供給されるポリシー・オブジェクトを含みます
2. or, specifies that an error be returned, but the RSVP message should not be forwarded as usual.
2.または、エラーが返されますが、RSVPメッセージは通常通りに転送されないように指定します。
All the details of RSVP message processing and associated interactions between different elements at an RSVP router (PEP, LPDP) and PDP are included in separate documents [3,8]. In the following, a few, salient points related to the framework are listed:
RSVPルータ（PEP、LPDP）及びPDPにおけるRSVPメッセージ処理と異なる要素間の関連する相互作用のすべての詳細は、別のドキュメント[3,8]に含まれています。以下では、フレームワークに関連するいくつかの、顕著なポイントが記載されています：
* LPDP is optional and may be used for making decisions based on policy elements handled locally. The LPDP, in turn, may have to go to external entities (such as a directory server or an authentication server, etc.) for making its decisions.
* LPDPはオプションであり、ローカルに処理ポリシーの要素に基づいて決定を行うために使用することができます。 LPDPは、今度は、その意思決定を行うために（そのようなディレクトリサーバや認証サーバなど）外部エンティティに行かなければならないことがあります。
* PDP is stateful and may make decisions even if no policy objects are received (e.g., make decisions based on information such as flowspecs and session object in the RSVP messages). The PDP may consult other PDPs, but discussion of inter-PDP communication and coordination is outside the scope of this document.
* PDPは、ステートフルであるとNOポリシーオブジェクトが受信されない場合であっても（例えば、RSVPメッセージにおけるフロースペック及びセッションオブジェクトなどの情報に基づいて決定を下す）決定を下すことができます。 PDPは、他のPDPを協議することができるが、PDP間の通信と調整の説明は、この文書の範囲外です。
* PDP sends asynchronous notifications to PEP whenever necessary to change earlier decisions, generate errors etc.
* PDPは、以前の決定を変更、エラーなどが発生するたびに必要なPEPに非同期通知を送信します
* PDP exports the information useful for usage monitoring and accounting purposes. An example of a useful mechanism for this purpose is a MIB or a relational database. However, this document does not specify any particular mechanism for this purpose and discussion of such mechanisms is out of the scope of this document.
* PDPは、使用の監視及び会計目的のために有用な情報をエクスポートします。この目的のために有用な機構の例は、MIBまたはリレーショナルデータベースです。しかし、この文書は、この目的のために、任意の特定の機構を指定しないと、このようなメカニズムの議論は、この文書の範囲外です。
By allowing division of labor between an LPDP and a PDP, the policy control architecture allows staged deployment by enabling routers of varying degrees of sophistication, as far as policy control is concerned, to communicate with policy servers. Figure 4 depicts an example set of nodes belonging to three different administrative domains (AD) (Each AD could correspond to a different service provider in this case). Nodes A, B and C belong to administrative domain AD-1, advised by PDP PS-1, while D and E belong to AD-2 and AD-3, respectively. E communicates with PDP PS-2. In general, it is expected that there will be at least one PDP per administrative domain.
LPDPとPDPの間の分業を可能にすることによって、ポリシー制御アーキテクチャは、ポリシーサーバと通信するために、限りポリシー制御に関しては、洗練の様々な程度のルータを可能にすることによって、展開を上演することを可能にします。図4は、3個の異なる管理ドメイン（AD）（各広告は、この場合、異なるサービスプロバイダに対応することができる）に属するノードの集合の例を示します。 D及びEは、それぞれ、AD-2およびAD-3に属しながら、ノードA、B及びCは、PDP PS-1の助言、管理ドメインAD-1に属します。 Eは、PDP PS-2と通信します。一般的には、管理ドメインごとに少なくとも1つのPDPが存在するであろうことが期待されます。
Policy capable network nodes could range from very unsophisticated, such as E, which have no LPDP, and thus have to rely on an external PDP for every policy processing operation, to self-sufficient, such as D, which essentially encompasses both an LPDP and a PDP locally, at the router.
ポリシー可能なネットワークノードは、本質的にLPDP両方を包含するD、として、自給自足に、そのようないかなるLPDPを持たないEとして、非常に洗練されていない範囲で、したがってすべてのポリシーの処理動作のために外部のPDPに依存する可能性があり、およびルータでの地元PDP、。
AD-1 AD-2 AD-3
________________/\_______________ __/\___ __/\___
{ } { } { }
A B C D E
+-------+ +-----+ +-------+ +-------+ +-------+
| RSVP | | RSVP| | RSVP | | RSVP | | RSVP |
+----+ |-------| |-----| |-------| |-------| |-------|
| S1 |--| P | L |--| |----| P | L |----| P | P |----| P | +----+
+----+ | E | D | +-----+ | E | D | | E | D | | E |-| R1 |
| P | P | | P | P | | P | P | | P | +----+
+-------+ +-------+ +-------+ +-------+
^ ^ ^
| | |
| | |
| | +-------+
| | | PDP |
| +------+ | |-------|
+-------->| PDP |<------+ | |
|------| +-------+
| | PS-2
+------+
PS-1
Figure 4: Placement of Policy Elements in an internet
図4：インターネットでのポリシーの要素の配置
In the following, we present examples of desired policies and scenarios requiring policy control that the policy control framework should be able to support. In some cases, possible approach(es) for achieving the desired goals are also outlined with a list of open issues to be resolved.
以下では、ポリシー・コントロール・フレームワークがサポートすることができなければならないポリシー制御を必要とする所望のポリシーおよびシナリオの例を提示します。いくつかの例においては、所望の目標を達成するための可能な方法（複数可）も解決すべきオープン問題のリストに概説されています。
5.1. Admission control policies based on factors such as Time-of-Day, User Identity, or credentials.
5.1. このように、デイタイム、ユーザーID、または資格情報などの要因に基づいてアドミッション制御ポリシー。
Policy control must be able to express and enforce rules with temporal dependencies. For example, a group of users might be allowed to make reservations at certain levels only during off-peak hours. In addition, the policy control must also support policies that take into account identity or credentials of users requesting a particular service or resource. For example, an RSVP reservation request may be denied or accepted based on the credentials or identity supplied in the request.
ポリシー制御を表現し、一時的な依存関係を持つルールを適用することができなければなりません。たとえば、ユーザのグループは、オフピーク時に特定のレベルでの予約を行うさせて頂く場合がございます。また、ポリシー制御も、アカウントIDまたは特定のサービスやリソースを要求したユーザーの資格情報を考慮するポリシーをサポートしている必要があります。例えば、RSVP予約要求が拒否されてもよいし、要求で指定された認証情報又は識別情報に基づいて受け入れられます。
Until recently, usage agreements between service providers for traffic crossing their boundaries have been quite simple. For example, two ISPs might agree to accept all traffic from each other, often without performing any accounting or billing for the "foreign" traffic carried. However, with the availability of QoS mechanisms based on Integrated and Differentiated Services, traffic differentiation and quality of service guarantees are being phased into the Internet. As ISPs start to sell their customers different grades of service and can differentiate among different sources of traffic, they will also seek mechanisms for charging each other for traffic (and reservations) transiting their networks. One additional incentive in establishing such mechanisms is the potential asymmetry in terms of the customer base that different providers will exhibit: ISPs focused on servicing corporate traffic are likely to experience much higher demand for reserved services than those that service the consumer market. Lack of sophisticated accounting schemes for inter-ISP traffic could lead to inefficient allocation of costs among different service providers.
最近まで、彼らの境界を通過するトラフィックのためのサービスプロバイダ間の利用契約は非常に簡単でした。例えば、2つのISPがしばしば行わ「外国人」トラフィックのための任意の会計や課金を行なうことなく、互いからのすべてのトラフィックを受け入れることに同意するものとがあります。しかし、統合及び差別化サービス、トラフィックの差別化とサービス保証の品質に基づくQoSメカニズムの利用可能性と、インターネットに段階的にされています。 ISPが顧客サービスの異なるグレードの販売を開始し、トラフィックの異なるソースを区別することができたように、彼らはまた、自社のネットワークを通過するトラフィックのためにお互いを充電するためのメカニズム（および予約）目指します。そのようなメカニズムを確立する上で一つの追加的なインセンティブが異なるプロバイダが示すことが顧客基盤の面で潜在的な非対称です：ISPは、企業のトラフィックにサービスを提供に焦点を当てた消費者市場にサービスを提供するものより予約サービスのための非常に高い需要を経験する可能性が高いです。 ISP間のトラフィックのための洗練された会計制度の欠如は、異なるサービスプロバイダ間のコストの非効率的な配分につながる可能性があります。
Bilateral agreements could fall into two broad categories; local or global. Due to the complexity of the problem, it is expected that initially only the former will be deployed. In these, providers which manage a network cloud or administrative domain contract with their closest point of contact (neighbor) to establish ground rules and arrangements for access control and accounting. These contracts are mostly local and do not rely on global agreements; consequently, a policy node maintains information about its neighboring nodes only. Referring to Figure 4, this model implies that provider AD-1 has established arrangements with AD-2, but not with AD-3, for usage of each other's network. Provider AD-2, in turn, has in place agreements with AD-3 and so on. Thus, when forwarding a reservation request to AD-2, provider AD-2 will charge AD-1 for use of all resources beyond AD-1's network. This information is obtained by recursively applying the bilateral agreements at every boundary between (neighboring) providers, until the recipient of the reservation request is reached. To implement this scheme under the policy control architecture, boundary nodes have to add an appropriate policy object to the RSVP message before forwarding it to a neighboring provider's network. This policy object will contain information such as the identity of the provider that generated them and the equivalent of an account number where charges can be accumulated. Since agreements only hold among neighboring nodes, policy objects have to be rewritten as RSVP messages cross the boundaries of administrative domains or provider's networks.
二国間協定は、2つの広いカテゴリーに分類できました。ローカルまたはグローバル。問題の複雑さのために、最初は前者のみが展開されることが期待されます。これらには、ネットワーククラウドまたは接触（隣人）の彼らの最も近い点で管理ドメイン契約を管理プロバイダは、アクセス制御およびアカウンティングのグランドルールや取り決めを確立します。これらの契約は、主にローカルであり、世界的な合意には依存しません。従って、ポリシーノードは、その隣接ノードに関する情報を維持します。図4を参照すると、このモデルは、プロバイダAD-1は、互いのネットワークの使用のためではなく、AD-3と、AD-2と取り決めを確立していることを意味します。プロバイダーAD-2は、順番に、所定の位置にようにAD-3とで協定を結んでいます。 AD-2へ予約要求を転送するときしたがって、プロバイダAD-2は、AD-1のネットワークを越えて、すべてのリソースの使用のためにAD-1を充電します。予約要求の受信者に到達するまで、この情報は、再帰的に（隣接する）プロバイダとの間のすべての境界で二国間協定を適用することによって得られます。ポリシー制御アーキテクチャの下でこの方式を実現するために、境界ノードは、隣接するプロバイダのネットワークに転送する前に、RSVPメッセージに適切なポリシーオブジェクトを追加しなければなりません。このポリシーオブジェクトは、それらとの電荷を蓄積することができ、口座番号と同等のものを生成したプロバイダのIDなどの情報が含まれています。契約のみ隣接ノード間で保持するので、ポリシー・オブジェクトは、RSVPメッセージは管理ドメインまたはプロバイダのネットワークの境界を越えるように書き換えなければなりません。
In many settings, it is useful to distinguish between reservations on the basis of some level of "importance". For example, this can be useful to avoid that the first reservation being granted the use of some resources, be able to hog those resources for some indefinite period of time. Similarly, this may be useful to allow emergency calls to go through even during periods of congestion. Such functionality can be supported by associating priorities with reservation requests, and conveying this priority information together with other policy information.
多くの設定では、「重要度」のいくつかのレベルに基づいて予約を区別するのに便利です。たとえば、これは最初の予約は、いくつかのリソースの使用を許可されることを避けるために役立つことができ、時間のいくつかの無期限にこれらのリソースを占有することができます。同様に、これは緊急呼び出しが輻輳期間中であっても通過することができるように有用である可能性があります。そのような機能は、予約要求に優先順位を関連付ける、およびその他のポリシー情報とともに、この優先度情報を伝達することによって支持することができます。
In its basic form, the priority associated with a reservation directly determines a reservation's rights to the resources it requests. For example, assuming that priorities are expressed through integers in the range 0 to 32 with 32 being the highest priority, a reservation of priority, say, 10, will always be accepted, if the amount of resources held by lower priority reservations is sufficient to satisfy its requirements. In other words, in case there are not enough free resources (bandwidth, buffers, etc.) at a node to accommodate the priority 10 request, the node will attempt to free up the necessary resources by preempting existing lower priority reservations.
その基本的な形では、予約に関連した優先順位は、直接それが要求したリソースに予約の権利を決定します。優先度の低い予約が保持しているリソースの量が十分である場合、例えば、優先度の予約が10、優先順位が最も高い優先度である32と32の範囲0の整数で表現されていることを言うと仮定すると、常に、受け入れられますその要件を満たします。換言すれば、ケースに優先10要請を収容するノードで十分な空きリソース（帯域幅、バッファなど）がない、ノードは、既存のより低い優先度の予約を先取りすることにより、必要なリソースを解放しようとします。
There are a number of requirements associated with the support of priority and their proper operation. First, traffic control in the router needs to be aware of priorities, i.e., classify existing reservations according to their priority, so that it is capable of determining how many and which ones to preempt, when required to accommodate a higher priority reservation request. Second, it is important that preemption be made consistently at different nodes, in order to avoid transient instabilities. Third and possibly most important, merging of priorities needs to be carefully architected and its impact clearly understood as part of the associated policy definition.
優先順位の支援とその適正な動作に関連した多くの要件があります。まず、ルータにおけるトラフィック制御は、優先度の高い予約要求に対応するために必要な場合、それは何を決定することができ、どれを先取りするように、すなわち、それらの優先度に応じて既存の予約を分類し、優先順位を認識する必要があります。第二に、プリエンプションが一時不安定性を避けるために、異なるノードで一貫して行われることが重要です。第三に、おそらく最も重要な、優先順位のマージは慎重に設計さとその影響が明確に関連付けられたポリシー定義の一部として理解する必要があります。
Of the three above requirements, merging of priority information is the more complex and deserves additional discussions. The complexity of merging priority information arises from the fact that this merging is to be performed in addition to the merging of reservation information. When reservation (FLOWSPEC) information is identical, i.e., homogeneous reservations, merging only needs to consider priority information, and the simple rule of keeping the highest priority provides an adequate answer. However, in the case of heterogeneous reservations, the *two-dimensional nature* of the (FLOWSPEC, priority) pair makes their ordering, and therefore merging, difficult. A description of the handling of different cases of RSVP priority objects is presented in [7].
3つの上記の要件のうち、優先度情報のマージは、より複雑であり、追加の議論に値します。優先度情報をマージの複雑さは、このマージは、予約情報のマージに加えて実行されるという事実から生じます。予約（FLOWSPEC）情報が同一である場合、すなわち、均一な予約は、マージは、優先度情報を検討する必要があり、最高の優先順位を維持する単純なルールは、適切な答えを提供します。しかしながら、異種の予約の場合には、（FLOWSPEC、優先度）対の*二次元的性質*は、その順序を行い、困難、合流します。 RSVP優先オブジェクトの異なるケースの取り扱いの説明は、[7]に提示されています。
A model of increasing popularity in the telephone network is that of the pre-paid calling card. This concept could also be applied to the Internet; users purchase "tokens" which can be redeemed at a later time for access to network services. When a user makes a reservation request through, say, an RSVP RESV message, the user supplies a unique identification number of the "token", embedded in a policy object. Processing of this object at policy capable routers results in decrementing the value, or number of remaining units of service, of this token.
電話網で人気を上げるのモデルは、プリペイドコーリングカードのことです。この概念は、インターネットにも適用することができます。ユーザーがネットワークサービスへのアクセスのために後で償還することができる「トークン」を購入します。ユーザは、RSVP RESVメッセージ、たとえば、スルー予約要求を行うとき、ユーザは、ポリシーオブジェクトに埋め込まれた「トークン」の固有の識別番号を、供給する。このトークンの値、又はサービスの残り単位数をデクリメントにおけるポリシー可能なルータの結果におけるこのオブジェクトの処理。
Referring to Figure 4, suppose receiver R1 in the administrative domain AD3 wants to request a reservation for a service originating in AD1. R1 generates a policy data object of type PD(prc, CID), where "prc" denotes pre-paid card and CID is the card identification number. Along with other policy objects carried in the RESV message, this object is received by node E, which forwards it to its PEP, PEP_E, which, in turn, contacts PDP PS-3. PS-3 either maintains locally, or has remote access to, a database of pre-paid card numbers. If the amount of remaining credit in CID is sufficient, the PDP accepts the reservation and the policy object is returned to PEP_E. Two issues have to be resolved here:
図4を参照すると、仮定する受信機R1は、管理ドメイン内のAD3はAD1に由来サービスの予約を要求したいと考えています。 R1は「PRC」はプリペイドカードを示し、CIDは、カード識別番号である型PD（PRC、CID）のポリシー・データ・オブジェクトを生成します。 RESVメッセージで運ばれる他のポリシー・オブジェクトとともに、この目的は、順番に、コンタクトPDP PS-3のPEP、PEP_E、に転送し、ノードEによって受信されます。 PS-3ローカルに保持し、またはプリペイドカード番号のデータベースへのリモート・アクセスを持っているのどちらか。 CIDに信用の残量が十分である場合、PDPは、予約を受け付けると、ポリシーオブジェクトがPEP_Eに返されます。 2つの問題は、ここで解決される必要があります：
* What is the scope of these charges?
*これらの費用の範囲は何ですか？
* When are charges (in the form of decrementing the remaining credit) first applied?
*ときは（残りのクレジットをデクリメントの形で）料金が最初に適用されますか？
The answer to the first question is related to the bilateral agreement model in place. If, on the one hand, provider AD-3 has established agreements with both AD-2 and AD-1, it could charge for the cost of the complete reservation up to sender S1. In this case PS-2 removes the PD(prc,CID) object from the outgoing RESV message.
最初の質問への答えは、代わりに二国間協定のモデルに関連しています。 、一方では、プロバイダAD-3は、両方のAD-2及びAD-1、それは送信者S1までの完全予約の費用を満たすことができるとの合意を確立している場合。この場合、PS-2は、発信RESVメッセージからPD（PRC、CID）オブジェクトを削除します。
On the other hand, if AD-3 has no bilateral agreements in place, it will simply charge CID for the cost of the reservation within AD-3 and then forward PD(prc,CID) in the outgoing RESV message. Subsequent PDPs in other administrative domains will charge CID for their respective reservations. Since multiple entities are both reading (remaining credit) and writing (decrementing credit) to the same database, some coordination and concurrency control might be needed. The issues related to location, management, coordination of credit card (or similar) databases is outside the scope of this document.
AD-3が所定の位置には二国間協定を有していない一方、それは単に前方次いで、AD-3内の予約のコストおよび発信RESVメッセージ内のPD（PRC、CID）のためのCIDを充電します。他の管理ドメイン内の後続のPDPは、それぞれの予約のためのCIDを充電します。複数のエンティティは、両方の（残りのクレジット）を読み、同じデータベースに（デクリメントクレジット）を書いているので、いくつかの調整と同時実行制御が必要になることがあります。場所、管理、クレジットカード（または類似）の調整データベースに関連する問題は、この文書の範囲外です。
Another problem in this scenario is determining when the credit is exhausted. The PDPs should contact the database periodically to submit a charge against the CID; if the remaining credit reaches zero, there must be a mechanism to detect that and to cause revocation or termination of privileges granted based on the credit.
クレジットがなくなったとき、このシナリオでは別の問題が決定されます。 PDPはCIDに対する電荷を提出するために定期的にデータベースに連絡してください。残りのクレジットがゼロに達した場合、それを検出するために、信用に基づいて付与された権限の失効または終了を引き起こすメカニズムが存在しなければなりません。
Regarding the issue of when to initiate charging, ideally that should happen only after the reservation request has succeeded. In the case of local charges, that could be communicated by the router to the PDP.
充電開始する際の問題は、予約要求が成功した後にのみ起こるべき理想について。局所的な電荷の場合には、それは、PDPにルータによって通信することができます。
The ability of senders to specify restrictions on reservations, based on receiver identity, number of receivers or reservation cost might be useful in future network applications. An example could be any application in which the sender pays for service delivered to receivers. In such a case, the sender might be willing to assume the cost of a reservation, as long as it satisfies certain criteria, for example, it originates from a receiver who belongs to an access control list (ACL) and satisfies a limit on cost. (Notice that this could allow formation of "closed" multicast groups).
受信機IDに基づいて、予約の制限を指定する送信者の能力は、受信機または予約のコストの数は、将来のネットワークアプリケーションに有用であるかもしれません。例では、送信者が受信者に配信サービスのために支払っている任意のアプリケーションである可能性があります。このような場合、送信者は、それが、例えば、一定の基準を満たす限り、予約の費用を引き受けることをいとわないかもしれない、それはアクセス制御リスト（ACL）に属する受信機から発信され、コストの制限を満たします。 （これは「閉」のマルチキャストグループの形成を可能にすることができることに注意してください）。
In the policy based admission control framework such a scheme could be achieved by having the sender generate appropriate policy objects, carried in a PATH message, which install state in routers on the path to receivers. In accepting reservations, the routers would have to compare the RESV requests to the installed state.
ポリシーベースのアドミッション制御の枠組みの中で、このような方式は、送信者が受信機への経路上のルータの状態をインストールPATHメッセージで運ばれ、適切なポリシーオブジェクトを、生成することによって達成することができます。予約の受付では、ルータは、インストールされた状態にRESV要求を比較する必要があります。
A number of different solutions can be built to address this scenario; precise description of a solution is beyond the scope of this document.
さまざまなソリューションの数は、このシナリオに対処するために構築することができます。ソリューションの正確な記述は、この文書の範囲を超えています。
6. Interaction Between the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP)
ポリシー実行ポイント（PEP）とポリシー決定ポイント（PDP）の間の6の相互作用
In the case of an external PDP, the need for a communication protocol between the PEP and PDP arises. In order to allow for interoperability between different vendors networking elements and (external) policy servers, this protocol should be standardized.
外部のPDPの場合には、PEPとPDPの間の通信プロトコルの必要性が生じます。要素と（外部）ポリシーサーバのネットワーク異なるベンダー間の相互運用性を可能にするためには、このプロトコルが標準化されるべきです。
This section describes a set of general requirements for the communication protocol between the PEP and an external PDP.
このセクションでは、PEPとPDPの外部との間の通信プロトコルのための一般的な要件のセットを記述する。
* Reliability: The sensitivity of policy control information necessitates reliable operation. Undetected loss of policy queries or responses may lead to inconsistent network control operation and are clearly unacceptable for actions such as billing and accounting. One option for providing reliability is the re-use of the TCP as the transport protocol.
*信頼性：ポリシー制御情報の感度が信頼性の高い動作を必要とします。ポリシークエリーまたは応答の検出されない損失が一貫性のないネットワーク制御動作につながると明確な請求や会計などのアクションのために受け入れられないことがあります。信頼性を提供するための1つの選択肢は、トランスポートプロトコルとしてTCPの再利用です。
* Small delays: The timing requirements of policy decisions related to QoS signaling protocols are expected to be quite strict. The PEP to PDP protocol should add small amount of delay to the response delay experienced by queries placed by the PEP to the PDP.
*小さな遅延：シグナリングプロトコルのQoSに関連した政策決定のタイミング要件はかなり厳しいことが予想されます。 PDPプロトコルへのPEPは、PDPのPEPによって配置されたクエリによって経験される応答遅れに遅延の少量を追加する必要があります。
* Ability to carry opaque objects: The protocol should allow for delivery of self-identifying, opaque objects, of variable length, such as RSVP messages, RSVP policy objects and other objects that might be defined as new policies are introduced. The protocol should not have to be changed every time a new object has to be exchanged.
*不透明なオブジェクトを運ぶ能力：プロトコルは、新しいポリシーが導入されるように定義されるかもしれないようなRSVPメッセージ、RSVPポリシーオブジェクトと他のオブジェクトのような可変長の自己識別、不透明なオブジェクト、の送達を可能にするべきです。プロトコルは、新しいオブジェクトを交換する必要があるたびに変更する必要はありません。
* Support for PEP-initiated, two-way Transactions: The protocol must allow for two-way transactions (request-response exchanges) between a PEP and a PDP. In particular, PEPs must be able to initiate requests for policy decision, re-negotiation of previously made policy decision, and exchange of policy information. To some extent, this requirement is closely tied to the goal of meeting the requirements of RSVP-specific, policy-based admission control. RSVP signaling events such as arrival of RESV refresh messages, state timeout, and merging of reservations require that a PEP (such as an RSVP router) request a policy decision from PDP at any time. Similarly, PEP must be able to report monitoring information and policy state changes to PDP at any time.
* PEP-開始、双方向トランザクションのサポート：プロトコルは、PEPとPDPの間で双方向のトランザクション（要求 - 応答交換）を可能にしなければなりません。特に、PEPには、政策決定、以前に作られた政策決定の再交渉、およびポリシー情報を交換するための要求を開始できる必要があります。ある程度までは、この要件は密接にRSVP-特有の、ポリシーベースのアドミッション制御の要件を満たすことを目標に結びついています。 RSVP RESVかかるの到着などのイベントが更新シグナリングメッセージ、状態タイムアウト、および予約のマージは、（RSVPルータとして）PEPはいつでもPDPからポリシー決定を要求することを必要とします。同様に、PEPはいつでもPDPに監視情報とポリシー状態変化を報告することができなければなりません。
* Support for asynchronous notification: This is required in order to allow both the policy server and client to notify each other in the case of an asynchronous change in state, i.e., a change that is not triggered by a signaling message. For example, the server would need to notify the client if a particular reservation has to be terminated due to expiration of a user's credentials or account balance. Likewise, the client has to inform the server of a reservation rejection which is due to admission control failure.
*非同期通知のサポート：これは、ポリシーサーバとクライアントの両方が状態の非同期変化、すなわち、シグナリングメッセージによってトリガされていない変更の場合で互いに通知することを可能にするために必要とされます。例えば、サーバは特定の予約が原因ユーザーの資格情報や口座残高の有効期限までに終了しなければならない場合に、クライアントに通知する必要があります。同様に、クライアントは、アドミッションコントロールの故障が原因で、予約拒絶のサーバに通知しなければなりません。
* Handling of multicast groups: The protocol should provision for handling of policy decisions related to multicast groups.
*マルチキャストグループの取り扱い：マルチキャストグループに関連する政策決定の処理のためのプロトコルべき提供。
* QoS Specification: The protocol should allow for precise specification of level of service requirements in the PEP requests forwarded to the PDP.
* QoSの仕様：プロトコルはPDPに転送PEP要求におけるサービス要求のレベルの正確な仕様を可能にすべきです。
The communication tunnel between policy clients and policy servers should be secured by the use of an IPSEC [4] channel. It is advisable that this tunnel makes use of both the AH (Authentication Header) and ESP (Encapsulating Security Payload) protocols, in order to provide confidentiality, data origin authentication, integrity and replay prevention.
ポリシークライアントとポリシーサーバ間の通信トンネルは、IPSEC [4]のチャネルを使用することによって確保されるべきです。このトンネルは、機密性、データ発信元認証、完全性、リプレイ防止を提供するために、AH（認証ヘッダー）とESP（カプセル化セキュリティペイロード）プロトコルの両方を使用することをお勧めします。
In the case of the RSVP signaling mechanism, RSVP MD5 [2] message authentication can be used to secure communications between network elements.
機構のRSVPシグナリングの場合に、RSVP MD5 [2]メッセージ認証は、ネットワーク要素間の通信を保護するために使用することができます。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[1]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[2] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[2]ベーカー、F.、リンデル、B.及びM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[3] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[3]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[4] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[4]アトキンソン、R.、 "インターネットプロトコルのためのセキュリティー体系"、RFC 1825、1995年8月を。
[5] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[5] Rigney、C.、ルーベンス、A.、シンプソン、W.及びS. Willensを、 "リモート認証ダイヤルインユーザーサービス（RADIUS）で"、RFC 2138、1997年4月。
[6] Rajan, R., et al., "Schema for Differentiated Services and Integrated Services in Networks", Work in Progress.
[6]ラジャン、R.、ら。、「ネットワークにおける差別化サービスと統合サービスのスキーマ」、ProgressのWork。
[7] Herzog, S., "RSVP Preemption Priority Policy", Work in Progress.
[7]ヘルツォーク、S.、 "RSVPの先取り優先権方針"、進行中の作業。
[8] Herzog, S., "COPS Usage for RSVP", RFC 2749, January 2000.
[8]ヘルツォーク、S.は、RFC 2749、2000年1月 "RSVPの使用上のCOPS"。
This is a result of an ongoing discussion among many members of the RAP group including Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, Shai Herzog, Tim O'Malley, Raju Rajan, and Arun Sastry.
これはジム・ボイル、ロン・コーエン、ローラ・カニンガム、デイブ・ダーラム、シャイヘルツォーク、ティム・オマリー、ラジュラジャン、およびアルンSastryを含むRAPグループの多くのメンバーの間で継続的な議論の結果です。
Raj Yavatkar Intel Corporation 2111 N.E. 25th Avenue, Hillsboro, OR 97124 USA
ラジYavatkarインテルコーポレーション2111 N.E.第25回アベニュー、ヒルズボロ、OR 97124 USA
Phone: +1 503-264-9077 EMail: raj.yavatkar@intel.com
電話：+1 503-264-9077電子メール：raj.yavatkar@intel.com
Dimitrios Pendarakis IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights NY 10598
ディミトリオスPendarakis IBM T.J。ワトソン研究所の私書箱704ヨークタウンハイツNY 10598箱
Phone: +1 914-784-7536 EMail: dimitris@watson.ibm.com
電話：+1 914-784-7536電子メール：dimitris@watson.ibm.com
Roch Guerin University of Pennsylvania Dept. of Electrical Engineering 200 South 33rd Street Philadelphia, PA 19104
電気工学200南33丁目駅、フィラデルフィアのペンシルバニア学科のRochのゲラン大学、PA 19104
Phone: +1 215 898-9351 EMail: guerin@ee.upenn.edu
電話：+1 215 898-9351 Eメール：guerin@ee.upenn.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。