RFC2753 日本語訳
2753 A Framework for Policy-based Admission Control. R. Yavatkar, D.Pendarakis, R. Guerin. January 2000. (Format: TXT=49763 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Yavatkar
Request for Comments: 2753 Intel
Category: Informational D. Pendarakis
IBM
R. Guerin
U. Of Pennsylvania
January 2000
Yavatkarがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2753年のインテルカテゴリ: ペンシルバニア2000年1月の情報のD.Pendarakis IBM R.ゲランU.
A Framework for Policy-based Admission Control
方針ベースの入場コントロールのためのフレームワーク
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
1. Introduction
1. 序論
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-
Integrated Services("int- serv"と呼ばれる)やRSVP[1]などのIETFワーキンググループは、アプリケーションかエンドユーザが現在のIPベストエフォート型サービスに加えたインターネットワークから特定のサービスの品質(または、レベル)を要求できるように、IPアーキテクチャとベストエフォート型サービスモデルに拡大を発生しました。 また、集合QoSがサービスであるとサポートするメカニズムの定義はDifferentiated Services作業部会における最近の取り組みに向けられます。 これらの新種業務のためのint-servモデルは入場とトラフィックコントロールのエンドポイントと支給からIntegrated ServicesルータでQoS(Serviceの品質)要件の明白なシグナリングを必要とします。 RSVP[RFC2205]とIntegrated Services[RFC2211、RFC2212]の提案された標準はそれぞれ新しい予約セットアッププロトコルと新しいサービス定義に関する例です。 int-servモデルの下では、あるデータフローは他の流れの上に優遇を受けます。 入場コントロールの部品はリクエスタのリソース予約の要請とQoS要求を受け入れるかどうか決定する有効な容量を考慮に入れるだけです。 しかしながら、int-servメカニズムは入場コントロールの重要な一面を含んでいません: ネットワークマネージャとサービスプロバイダーは、ユーザとアプリケーションのアイデンティティなどの評価基準から得られた方針に基づくネットワーク資源とサービスの使用をモニターして、制御して、実施できなければなりません、トラフィック/帯域幅要件、セキュリティ問題、および時間
Yavatkar, et al. Informational [Page 1] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[1ページ]のRFC2753フレームワーク
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.
日の/週。 また、同様に、デフ-servメカニズムは、顧客のアイデンティティ、イングレスポイントなどなどの様々な評価基準を伴う方針を考慮に入れる必要があります。
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.
私たちはセクション2との定義のリストで始めます。 セクション3が要件をリストアップして、メカニズムの目標は、より良いQoSへのアクセスを制御して、以前はよく実施していました。 私たちは、次に、セクション4にフレームワークの建築要素について概説して、各コンポーネントのために想定された機能性について説明します。 セクション5はそれらのシナリオに必要である例の方針、可能なシナリオ、および方針サポートについて論じます。 セクション6は、方針サーバ(PDP)とそのクライアント(PEP)とのコミュニケーションにクライアント/サーバプロトコルのための要件を指定して、このためにいくつかの既存のプロトコルの適合を評価します。
2. Terminology
2. 用語
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を求める要求を制御します。
Yavatkar, et al. Informational [Page 2] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[2ページ]のRFC2753フレームワーク
- 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.
- 方針実施ポイント(気力): 政策決定が実際に励行されるポイント。
- Policy Ignorant Node (PIN): A network element that does not
explicitly support policy control using the mechanisms defined in
this document.
- 方針の無知なノード(暗証番号): 本書では定義されたメカニズムを使用することで明らかに方針コントロールをサポートしないネットワーク要素。
- 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.
- 柔らかい州Model--軟性国家はインストールされるのからの回がPEPかPDPに述べるstatefulモデルのフォームです。 それは、コミュニケーションがあるとき状態を消す自動方法かネットワーク要素の故障です。 例えば、RSVPは、データフローの経路に沿って予約状態をネットワーク要素にインストールするのに軟性国家モデルを使用します。
- Installed State: A new and unique request made from a PEP to a PDP
that must be explicitly deleted.
- インストールされた州: PEPから明らかに削除しなければならないPDPまでされた新しくてユニークな要求。
Yavatkar, et al. Informational [Page 3] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[3ページ]のRFC2753フレームワーク
- 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決定を必要とするというわけではないという意味で信じられるノード。
3. Policy-based Admission Control: Goals and Requirements
3. 方針ベースの入場コントロール: 目標と要件
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サービス(例えば、Diff-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.
- モニターへの支給と課金情報: メカニズムは、モニターしている政策ポジションのサポート、リソース用法を含んで、アクセス情報を提供しなければなりません。 特に、会計と支払い目的に使用されるかもしれない用法とアクセス情報を提供するためにメカニズムを含まなければなりません。
Yavatkar, et al. Informational [Page 4] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[4ページ]のRFC2753フレームワーク
- 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.
- 耐障害性と回復: このフレームワークに基づいて設計されたメカニズムは耐障害性のための条項とPDPs(関連PEPsとPDPを切り離すネットワークパーティション(そして、その後の合併)を含むコミュニケーションにおける分裂)の失敗などの失敗事件からの回復を含まなければなりません。
- 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.
- スケーラビリティ: 方針コントロールのために設計されたメカニズムのための重要な要件の1つはスケーラビリティです。 メカニズムは少なくとも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.
- サービス問題のセキュリティと否定: 以下の局面に関する限り、方針規制アーキテクチャは安全であるに違いありません。 まず最初に、フレームワークの下で提案されたメカニズムはサービスの脅威の窃盗と否定を最小にしなければなりません。 2番目に、方針コントロールにかかわる実体(PEPsやPDPsなどの)が互いのアイデンティティについて確かめて、交信する前に必要な信頼を確立できるのを確実にしなければなりません。
4. Architectural Elements
4. 建築Elements
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
方針コントロールのための2つの主な建築要素が、PEP(方針Enforcement Point)とPDP(方針Decision Point)です。 図1は、簡単な構成がこれらの2つの要素を伴うのを示します。 PEPがネットワーク・ノードのコンポーネントであり、PDPがリモート実体である、それ
Yavatkar, et al. Informational [Page 5] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[5ページ]のRFC2753フレームワーク
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.
方針サーバに住むかもしれません。PEPはいつも方針の意識しているノードで動くコンポーネントを表します。 それは政策決定が実際に励行されるポイントです。 主としてPDPで政策決定をします。 PDP自身は、ユーザー認証、会計、方針情報記憶などの追加機能性を達成するのに追加メカニズムとプロトコルを利用するかもしれません。 例えば、PDPは方針情報[6]のストレージと検索にLDAPベースのディレクトリサービスを使用しそうです。 このドキュメントはこれらの追加メカニズムであって、プロトコルであってそれらがどう使用されているかに関する議論を含んでいません。
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までの方針コントロールを求める要求は政策決定要求の引き金となったオリジナルのメッセージかイベントにおける入場制御情報(要求された帯域幅のflowspecか量などの)に加えて1つ以上の方針要素(1個以上の政策目的に、要約する)を含むかもしれません。 PDPは政策決定を返して、次に、PEPは、適切に要求を受け入れるか、または否定することによって、政策決定を実施します。 また、PDPは1つ以上の方針要素を含んでいるPEPに追加情報を返すかもしれません。 この情報は入場コントロール決定に関連している必要はありません。 むしろ、エラーメッセージか送信するか転送されたメッセージを定式化するのにそれを使用できます。
________________ Policy server | | ______ | Network Node | | |-------------> | _____ | | | May use LDAP,SNMP,.. for accessing | | | | | | policy database, authentication,etc. | | PEP |<-----|------->| PDP |-------------> | |_____| | |_____| | | |________________|
________________ 方針サーバ| | ______ | ネットワーク・ノード| | |、-、-、-、-、-、-、-、-、-、-、-、--、>| _____ | | | LDAP、SNMPを使用するかもしれない、アクセス| | | | | | 方針データベース、認証など | | 気力| <、-、-、-、--、|、-、-、-、-、-、--、>| 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
PDPは任意に例えば、構成、ユーザー認証、会計学、および支払いデータベースにアクセスするための他の外部のサーバに連絡するかもしれません。 ネットワークマネージメント(SNMP)かディレクトリアクセス(LDAP)のために定義されたプロトコルはこのコミュニケーションに使用されるかもしれません。 アクセスの特定のタイプと使用されるプロトコルは異なるかもしれません。
Yavatkar, et al. Informational [Page 6] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[6ページ]のRFC2753フレームワーク
different implementations, some of these interactions will have network-wide implications and could impact the interoperability of different devices.
異なった実装であり、これらの相互作用のいくつかが、ネットワーク全体の意味を持って、異なったデバイスの相互運用性に影響を与えるかもしれません。
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によって実施された政策を指定するのに使用される「言語」です。 ネットワーク・ノードで適切な方針の数は潜在的にかなり大きいかもしれません。 同時に、これらの方針は高い複雑さを示すでしょう、決定に到達するのに使用される分野の数、および広範囲の決定で。 その上、いくつかの方針が同じ要求プロフィールに適切であるかもしれなそうです。 例えば、方針はそのグループ(例えば、会社の経営者)の特定のメンバーからの要求の処理と同様に一般的なユーザ・グループ(例えば、会社の従業員)からの要求の処理を定めるかもしれません。 この例では、「マネージャ」というユーザ・プロファイルは1つの一般的な詳細、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の向こう側に一般的です。 他方では、情報に依存する方針とどれが特定のルータと、よりダイナミックであり、あるかもしれないかへのローカルの状態はルータで、よりよく局所的に実装しました。
Yavatkar, et al. Informational [Page 7] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[7ページ]のRFC2753フレームワーク
________________ ____________________
| | | |
| Network Node | Policy Server | Network Node |
| _____ | _____ | _____ _____ |
| | | | | | | | | | | |
| | PEP |<-----|---->| PDP | | | PEP |<-->| PDP | |
| |_____| | |_____| | |_____| |_____| |
| ^ | | |
| | _____ | |____________________|
| \-->| | |
| | LPDP| |
| |_____| |
| |
|________________|
________________ ____________________ | | | | | ネットワーク・ノード| 方針サーバ| ネットワーク・ノード| | _____ | _____ | _____ _____ | | | | | | | | | | | | | | | 気力| <、-、-、-、--、|、-、-、--、>| PDP| | | 気力| <-->、| 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: 方針の他の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.
1. ローカルイベントかメッセージが政策決定のためにPEPを呼び出すとき、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
2. PEPは、局所的に評価されることになっている1セットの方針要素(セットAと呼ばれる)を特定するためにローカルの構成データベースに相談するかもしれません。 地方の構成は局所的に評価される方針要素のタイプを指定します。 PEPは要求に合格します。
Yavatkar, et al. Informational [Page 8] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[8ページ]のRFC2753フレームワーク
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) ).
セットで、Local Decisionへの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はすべての方針の要素とD(A)との要求にPDPに合格します。 PDPはすべての方針要素と要求に基づく方針を適用して、決断を下します。(それをD(Q))と呼びましょう。 次に、それは結果を結合します。部分的な結果D(A)が最終決定に達するのに組み合わせ操作を使用していて。
4. The PDP returns the final policy decision (obtained from the
combination operation) to the PEP.
4. 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 MUSTがPDPに連絡することに注意してください。 この要件は、要求が予約の要請で方針要素を省略することによって方針コントロールを迂回させることができないのを確実にするのを助けます。 しかしながら、「short-circuit」処理は受入れられます、すなわち、D(A)の結果が上の「いいえ」であるなら、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に送るかもしれないことに注意しなければなりません。
4.1. Example of a RSVP Router
4.1. RSVPルータに関する例
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]に提供します。
Yavatkar, et al. Informational [Page 9] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[9ページ]のRFC2753フレームワーク
______________________________
| |
| Router |
| ________ _____ | _____
| | | | | | | |
| | RSVP |<------->| PEP |<--|---------->| PDP |
| |________| |_____| | |_____|
| ^ |
| | Traffic control |
| | _____________ |
| \---->| _________ | |
| | |capacity | | |
| | | ADM CTL | | |
| | |_________| | |
--|----------->| ____ ____ | |
| Data | | PC | PS | | |
| | |____|____| | |
| |_____________| |
| |
|______________________________|
______________________________ | | | ルータ| | ________ _____ | _____ | | | | | | | | | | RSVP| <、-、-、-、-、-、--、>| 気力| <--、|、-、-、-、-、-、-、-、-、--、>| PDP| | |________| |_____| | |_____| | ^ | | | トラフィックコントロール| | | _____________ | | \---->| _________ | | | | |容量| | | | | | ADM CTL| | | | | |_________| | | --|、-、-、-、-、-、-、-、-、-、--、>| ____ ____ | | | データ| | 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は、政策決定を得て、RSVPモジュールにそれを伝えて戻すのに、PDP(そして、LPDP)を使用するでしょう。
4.2. Additional functionality at the PDP
4.2. PDPの追加機能性
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
通常、PDPは入場コントロール要求と関連方針要素に基づく最終的な政策決定を返します。 しかしながら、PDPが、時々方針関連のエラーメッセージを生成するようにPEP(または、PEPが住んでいるネットワーク要素の入場コントロールモジュール)に頼むのは、可能であるべきです。 例えば、RSVPの場合では、同時に「10minsなどであなたの要求を取りこわさなければならないかもしれないことなど」の状態を警告するために川下のノード(NHOP)に警告/エラーメッセージを生成することを願うかもしれないのを除いて、PDPは申し込みに応じて、予約のインストールと推進を前のホップに許すかもしれません。 基本的に、方針関連の誤り、そして/または、警告を作成して、固有のQoSシグナリングプロトコル(RSVPなどの)を使用することでそれらを伝播する能力が必要です。 また、PDPによって返されたそのような方針誤りは指定できなければなりません。
Yavatkar, et al. Informational [Page 10] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[10ページ]のRFC2753フレームワーク
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:
継続的な通常の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メッセージだけがいつものように転送されるべきでないと指定します。
4.3. Interactions between PEP, LPDP, and PDP at a RSVP router
4.3. RSVPルータにおけるPEPと、LPDPと、PDPとの相互作用
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はどんな政策目的も受け取られていないでも(例えば、RSVPメッセージでflowspecsやセッションオブジェクトの情報に基づく決定をします)statefulで、決定をするかもしれません。 PDPは他のPDPsに相談するかもしれませんが、このドキュメントの範囲の外に相互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か関係型データベースです。 しかしながら、このドキュメントはこのためにどんな特定のメカニズムも指定しません、そして、このドキュメントの範囲の外にそのようなメカニズムの議論があります。
4.4. Placement of Policy Elements in a Network
4.4. ネットワークにおける、Policy Elementsのプレースメント
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
方針規制アーキテクチャが異なった度合いに関する洗練のルータを可能にすることによって上演された展開を許すことごとに方針サーバとコミュニケートするのが方針コントロールに関する限り。 図4が3つの異なった管理ドメイン(AD)に属すノードの例のセットについて表現する、(各ADは異なったサービスに対応できました。
Yavatkar, et al. Informational [Page 11] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[11ページ]のRFC2753フレームワーク
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.
この場合、プロバイダー) ノードA、B、およびCはそれぞれDとEが西暦2年と-西暦3年に-属しますが、PDP PS-1によって教えられた管理ドメイン西暦1年に-属します。 EはPDP PS-2とコミュニケートします。 一般に、管理ドメインあたり少なくとも1PDPがあると予想されます。
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を全く持たないで、その結果、あらゆる方針加工作業のために外部のPDPを当てにしなければならないEなどのように、自給自足に、Dなどのように、ルータで。(本質的には、Dは局所的にLPDPと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
西暦1年-西暦2年-西暦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: インターネットにおける、Policy Elementsのプレースメント
5. Example Policies, Scenarios, and Policy Support
5. 例の方針、シナリオ、および方針サポート
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.
以下では、私たちは方針コントロールフレームワークがサポートすることができるべきである方針コントロールを必要とする必要な方針とシナリオに関する例を提示します。 また、望んでいる目標を達成するためのいくつかの場合可能なアプローチ(es)は未解決の問題のリストで概説されていて、決議されます。
5.1. Admission control policies based on factors such as Time-of-Day,
User Identity, or credentials.
5.1. 入場コントロール方針は日のTime、User Identity、または資格証明書などの要素を基礎づけました。
Yavatkar, et al. Informational [Page 12] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[12ページ]のRFC2753フレームワーク
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.
方針コントロールは、時の依存に伴う規則を表して、実施できなければなりません。 例えば、ユーザー層はオフピークの時間だけあるレベルで予約をすることができるかもしれません。 また、さらに、方針コントロールは特定のサービスかリソースを要求するユーザのアイデンティティか資格証明書を考慮に入れる方針をサポートしなければなりません。 例えば、要求で供給された資格証明書かアイデンティティに基づいてRSVP予約の要請を否定するか、または受け入れるかもしれません。
5.2. Bilateral agreements between service providers
5.2. サービスプロバイダーの間の二国間条約
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が、互いからすべてのトラフィックを受け入れるのに同意するかもしれません。 しかしながら、IntegratedとDifferentiated Servicesに基づくQoSメカニズムの有用性で、トラフィック分化とサービスの質保証はインターネットに位相を合わせられています。 また、ISPが異なったサービスのグレードを彼らの顧客に販売し始めて、トラフィックのさまざまな原因で差別化できるように、彼らはトラフィック(そして、予約)のためにそれらのネットワークを通過しながら互いを請求するためにメカニズムを求めるでしょう。 そのようなメカニズムを確立することにおける1つの追加誘因が異なったプロバイダーが示す顧客ベースに関する潜在的非対称です: 法人のトラフィックを修理するのに集中している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
二国間条約は2つの広いカテゴリになるかもしれません。 地方である、またはグローバルです。 問題の複雑さのため、そんなに初めは、前者だけが配布されると予想されます。 これらでは、それらの確立する中で最も近い連絡先(隣人)とのネットワーク雲か管理ドメイン契約を管理するプロバイダーがアクセスコントロールと会計のための規則とアレンジメントを研摩しました。 これらの契約は、ほとんど地方であり、グローバルな協定に依存しません。 その結果、方針ノードは隣接しているノードだけの情報を保守します。 図4を参照して、このモデルは、西暦1年が-持っているプロバイダーが西暦2年で-アレンジメントを確立しましたが、西暦3年で-確立したというわけではないと暗示します、互いのネットワークの使用法のために。 プロバイダー西暦-2は適所に順番に西暦3年との-協定などを持っています。 西暦2年まで-予約の要請を転送するとき、したがって、プロバイダー西暦-2はAD1ネットワークを超えたすべてのリソースの使用のために西暦1年を-請求するでしょう。 (隣接する)のプロバイダーの間のあらゆる境界で二国間条約を再帰的に適用することによって、この情報を得ます、予約の要請の受取人が連絡されるまで。 方針規制アーキテクチャの下でこの体系を実装するために、境界ノードは適切な政策目的をRSVPに加えなければなりません。
Yavatkar, et al. Informational [Page 13] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[13ページ]のRFC2753フレームワーク
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.
隣接しているプロバイダーのネットワークにそれを送る前のメッセージ。 この政策目的は充電を蓄積できるそれらを生成したプロバイダーのアイデンティティや口座番号の同等物の情報を含むでしょう。 協定が隣接しているノードの中で成立するだけであるとき、RSVPメッセージが管理ドメインかプロバイダーのネットワークの限界に交差しているので、政策目的は書き直されなければなりません。
5.3. Priority based admission control policies
5.3. 優先権は入場コントロール方針を基礎づけました。
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.
基本的なフォームでは、予約に関連している優先権は直接それが要求するリソースへの予約の権利を決定します。 例えば、プライオリティが範囲の整数を通して0〜32に最優先である32で言い表されると仮定すると、いつも優先権に関する条件(たとえば、10)を受け入れるでしょう、低優先度の予約で保持されたリソースの量が要件を満たすために十分であるなら。 言い換えれば、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.
優先権のサポートに関連している多くの要件と彼らの適切な操作があります。 まず最初に、ルータにおけるトラフィックコントロールは、プライオリティを意識している必要があります、すなわち、それらの優先権に従って、既存の予約を分類してください、どれを何、と先取りしたらよいかを決定できるように、より高い優先権予約の要請に対応するのが必要であるときに。 2番目に、一時的な不安定性を避けるために異なったノードで一貫して先取りをするのは重要です。 3番目とことによると、最も重要です、プライオリティの合併は慎重にarchitectedされる必要があります、そして、影響は関連方針定義の一部として明確に分かりました。
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
要件を超えた3では、優先権情報の合併は、より複雑であり、追加議論に値します。 優先権情報を合併する複雑さはこの合併が予約の合併に加えて実行されることであるという事実から起こります。
Yavatkar, et al. Informational [Page 14] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[14ページ]のRFC2753フレームワーク
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].
情報。 条件(FLOWSPEC)情報が同じで、すなわち、均質の予約であるときに、合併は、優先権情報を考える必要があるだけです、そして、最優先を保つ簡単な規則は適切な答えを前提とします。 しかしながら、異種の予約の場合では、(FLOWSPEC、優先権)組の*二次元本質*は、それらの注文を作って、その結果合併を作ります、難しいです。 RSVP優先権オブジェクトの異なったケースの取り扱いの記述は[7]に提示されます。
5.4. Pre-paid calling card or Tokens
5.4. カードかTokensと呼びながら、あらかじめ支払います。
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を参照して、管理ドメインAD3の受信機R1がAD1で起こるサービスの予約を要求したがっていると仮定してください。 R1は、方針がタイプPD(prc、CID)のデータ・オブジェクトであると生成します。(そこでは、"prc"があらかじめ支払われたカードを指示して、CIDはカード識別番号です)。 RESVメッセージで運ばれた他の政策目的と共にノードEはこのオブジェクトを受け取ります。(それは、PEP、順番にPDP PS-3に連絡するPEP_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.
最初の質問の答えは適所で二国間条約モデルに関連します。 一方では、プロバイダー西暦-3が西暦2年と-西暦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
他方では、西暦3年が-適所に二国間条約を全く持っていないと、それは西暦3年-以内の予約の費用と次に、前進のPD(prc、CID)のために送信するRESVメッセージで単にCIDを請求するでしょう。 他の管理ドメインのその後のPDPsがCIDを請求する、それら
Yavatkar, et al. Informational [Page 15] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[15ページ]のRFC2753フレームワーク
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.
それぞれの予約。 複数の実体が読書(クレジット残高)と同じデータベースに書く(クレジットを減少させます)両方であるので、何らかのコーディネートと同時実行制御が必要であるかもしれません。 問題は位置、管理に関連して、このドキュメントの範囲の外にクレジットカードの、そして、(同様)のデータベースのコーディネートがあります。
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.
このシナリオの別の問題は、クレジットがいつ疲れ果てているかを決定しています。 PDPsは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へのルータはそれを伝えることができました。
5.5. Sender Specified Restrictions on Receiver Reservations
5.5. 送付者は受信機予約のときに制限を指定しました。
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).
送付者が受信機のアイデンティティに基づいて予約で制限を指定する能力、受信機の数か予約費用が今後のネットワーク応用で役に立つかもしれません。 例は送付者が受信機に提供されたサービスの代価を払うどんなアプリケーションであるかもしれません。 予約の費用であるとある評価基準を満たして、例えば、受信機から発する限り、だれがこのような場合にはアクセスコントロールリスト(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)
6. 方針実施ポイント(気力)と政策決定ポイントとの相互作用(PDP)
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の間の通信プロトコルの必要性は起こります。 要素と(外部)の方針サーバをネットワークでつなぎながら異なったベンダーの間で相互運用性を考慮するために、このプロトコルは標準化されるべきです。
Yavatkar, et al. Informational [Page 16] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[16ページ]のRFC2753フレームワーク
6.1. PEP to PDP Protocol Requirements
6.1. PDPプロトコル要件に元気づけてください。
This section describes a set of general requirements for the communication protocol between the PEP and an external PDP.
このセクションはPEPと外部のPDPの間の通信プロトコルのための1セットの一般的な要件について説明します。
* 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.
* 信頼性: 方針制御情報の感度は信頼できる操作を必要とします。 方針質問のUndetected損失か応答が、無節操なネットワーク制御機能に通じるかもしれなくて、支払いや会計などの動作には、明確に容認できません。 信頼性を提供するための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はPEPによってPDPに置かれた質問で経験された応答遅れに少量の遅れを加えるはずです。
* 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によって開始されて、両用のTransactionsのサポート: プロトコルはPEPとPDPの間の両用トランザクション(要求応答交換)を考慮しなければなりません。 特に、PEPsは政策決定、以前に人工の政策決定、および方針情報の交換の再交渉を求める要求を開始できなければなりません。 ある程度、この要件は密接にRSVP特有の、そして、方針に基づいている入場コントロールに関する必要条件を満たすという目標に結ばれます。 RESVの到着などのRSVPシグナル伝達事象はメッセージをリフレッシュします、州のタイムアウト、そして、予約を合併するのがPEP(RSVPルータなどの)がいつでも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.
* 非同期な通知のサポート: これが、状態(すなわち、シグナリングメッセージによって引き起こされない変化)で非同期な変化の場合で互いに通知するために方針サーバとクライアントを両方に許容するのに必要です。 例えば、特定の予約がユーザの資格証明書か勘定残高の満了のため終えられなければならないなら、サーバは、クライアントに通知する必要があるでしょう。 同様に、クライアントは、どれが入場コントロール失敗のためであるかを予約拒絶のサーバに知らせなければなりません。
Yavatkar, et al. Informational [Page 17] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[17ページ]のRFC2753フレームワーク
* 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要求における、サービス要件のレベルの正確な仕様を考慮するべきです。
7. Security Considerations
7. セキュリティ問題
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(認証Header)と超能力(Securityが有効搭載量であるとカプセル化する)プロトコルを利用するのは、賢明です、秘密性、データ発生源認証、保全、および再生防止を提供するために。
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]通報認証を使用できます。
8. References
8. 参照
[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の機能的な仕様」、RFC2205、1997年9月。
[2] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[2] ベイカーとF.とリンデルとB.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[3] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[3] ハーツォグ、S.、「方針コントロールのためのRSVP拡張子」、RFC2750、2000年1月。
[4] Atkinson, R., "Security Architecture for the Internet Protocol",
RFC 1825, August 1995.
[4] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、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.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[6] Rajan, R., et al., "Schema for Differentiated Services and
Integrated Services in Networks", Work in Progress.
[6]Rajan、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.、「RSVPのための巡査用法」、RFC2749、2000年1月。
Yavatkar, et al. Informational [Page 18] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[18ページ]のRFC2753フレームワーク
9. Acknowledgements
9. 承認
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.
これはRAPグループの多くのメンバーの中の現在行われている議論がジム・ボイル、ロンコーエン、ローラカニンハム、デーヴ・ダラム、Shaiハーツォグ、ティム・オマリー、ラジュRajan、およびアルンSastryを含んでいるという結果です。
10. Authors' Addresses
10. 作者のアドレス
Raj Yavatkar Intel Corporation 2111 N.E. 25th Avenue, Hillsboro, OR 97124 USA
主権Yavatkar諜報社2111のアベニュー、ヒースボロー、または25番目の97124の東北米国
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ヨークタウンHeightsニューヨーク 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南PA 19104人のRochゲランペンシルバニア大学部
Phone: +1 215 898-9351 EMail: guerin@ee.upenn.edu
以下に電話をしてください。 +1 215 898-9351 メールしてください: guerin@ee.upenn.edu
Yavatkar, et al. Informational [Page 19] RFC 2753 Framework for Policy-based Admission Control January 2000
Yavatkar、他 方針ベースの入場コントロール2000年1月のための情報[19ページ]のRFC2753フレームワーク
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Yavatkar, et al. Informational [Page 20]
Yavatkar、他 情報[20ページ]
一覧
スポンサーリンク
