Network Working Group S . Herzog, Ed.
Request for Comments: 2749 IPHighway
Category: Standards Track J. Boyle
Level3
R. Cohen
Cisco
D. Durham
Intel
R. Rajan
AT&T
A. Sastry
Cisco
January 2000
COPS usage for RSVP
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document describes usage directives for supporting COPS policy services in RSVP environments.
この文書では、RSVP環境でCOPSポリシーサービスをサポートするための使用方法のディレクティブについて説明します。
Table of Contents
目次
1 Introduction....................................................2
2 RSVP values for COPS objects....................................2
2.1 Common Header, client-type...................................2
2.2 Context Object (Context).....................................3
2.3 Client Specific Information (ClientSI).......................4
2.4 Decision Object (Decision)...................................4
3 Operation of COPS for RSVP PEPs.................................6
3.1 RSVP flows...................................................6
3.2 Expected Associations for RSVP Requests......................6
3.3 RSVP's Capacity Admission Control: Commit and Delete.........7
3.4 Policy Control Over PathTear and ResvTear....................7
3.5 PEP Caching COPS Decisions...................................7
3.6 Using Multiple Context Flags in a single query...............8
3.7 RSVP Error Reporting.........................................9
4 Security Considerations.........................................9
5 Illustrative Examples, Using COPS for RSVP......................9
5.1 Unicast Flow Example.........................................9
5.2 Shared Multicast Flows......................................11
6 References.....................................................14
7 Author Information and Acknowledgments.........................15
8 Full Copyright Statement.......................................17
1 Introduction
1はじめに
The Common Open Policy Service (COPS) protocol is a query response protocol used to exchange policy information between a network policy server and a set of clients [COPS]. COPS is being developed within the RSVP Admission Policy Working Group (RAP WG) of the IETF, primarily for use as a mechanism for providing policy-based admission control over requests for network resources [RAP].
共通オープンポリシーサービス（COPS）プロトコルは、ネットワークポリシーサーバとクライアントのセット[COPS]の間のポリシー情報を交換するために使用されるクエリ応答プロトコルです。 COPSは、[RAP]は、主にネットワークリソースに対する要求オーバーポリシーベースのアドミッション制御を提供するためのメカニズムとして使用するために、IETFのRSVPアドミッションポリシーワーキンググループ（WG RAP）の中で開発されています。
This document is based on and assumes prior knowledge of the RAP framework [RAP] and the basic COPS [COPS] protocol. It provides specific usage directives for using COPS in outsourcing policy control decisions by RSVP clients (PEPs) to policy servers (PDPs).
この文書は、に基づいてRAPフレームワーク[RAP]と基本COPS [COPS]プロトコルの事前知識を前提としています。これは、ポリシーサーバ（のPDP）へのRSVPクライアント（のPEP）により、アウトソーシングポリシー制御の決定にCOPSを使用するための具体的な使用のディレクティブを提供します。
Given the COPS protocol design, RSVP directives are mainly limited to RSVP applicability, interoperability and usage guidelines, as well as client specific examples.
COPSプロトコルの設計を考えると、RSVPディレクティブは、適用性、そして相互運用ガイドラインの使用と同様に、クライアントの具体例をRSVPに主に限定されています。
2 RSVP values for COPS objects
COPSオブジェクトの2つのRSVP値
The usage of several COPS objects is affected when used with the RSVP client type. This section describes these objects and their usage.
RSVPのクライアントタイプで使用する場合、いくつかのCOPSオブジェクトの使用が影響を受けています。このセクションでは、これらのオブジェクトとその使用方法について説明します。
RSVP is COPS client-type 1
RSVPはCOPSクライアントタイプ1であります
The semantics of the Context object for RSVP is as follows:
次のようにRSVPのためのContextオブジェクトの意味は次のとおりです。
R-Type (Request Type Flag)
Rタイプ（要求タイプフラグ）
Incoming-Message request
着信メッセージ要求
This context is used when the PEP receives an incoming RSVP
message. The PDP may decide to accept or reject the incoming
message and may also apply other decision objects to it. If the
incoming message is rejected, RSVP should treat it as if it
never arrived.
Resource-Allocation request
リソース割り当て要求
This context is used when the PEP is about to commit local
resources to an RSVP flow (admission control). This context
applies to Resv messages only. The decision whether to commit
local resources is made for the merge of all reservations
associated with an RSVP flow (which have arrived on a
particular interface, potentially from several RSVP Next-Hops).
Outgoing-Message request (forwarding an outgoing RSVP message)
出射メッセージ要求（発信RSVPメッセージを転送します）
This context is used when the PEP is about to forward an
outgoing RSVP message. The PDP may decide to allow or deny the
outgoing message, as well as provide an outgoing policy data
object.
M-Type (Message Type)
M-タイプ（メッセージタイプ）
The M-Type field in the Context Object identifies the applicable RSVP message type. M-Type values are identical to the values used in the "msg type" field in the RSVP header [RSVP].
ContextオブジェクトのM-Typeフィールドは、該当するRSVPメッセージタイプを識別する。 M型の値は、RSVPヘッダ[RSVP]の「MSGタイプ」フィールドに使用される値と同一です。
The following RSVP message types are supported in COPS:
次のRSVPメッセージタイプがCOPSでサポートされています。
Path Resv PathErr ResvErr
パスのResvたPathErr ResvErr
Other message types such as PathTear, ResvTear, and Resv Confirm are not supported. The list of supported message types can only be extended in later versions of RSVP and/or later version of this document.
このようPathTear、たResvTear、およびのResv確認などの他のメッセージタイプがサポートされていません。サポートされているメッセージ・タイプのリストは、RSVPおよび/またはこの文書の新しいバージョンのそれ以降のバージョンに拡張することができます。
All objects that were received in an RSVP message are encapsulated inside the Client Specific Information Object (Signaled ClientSI) sent from the PEP to the remote PDP (see Section 3.1. on multiple flows packed in a single RSVP message).
RSVPメッセージで受信されたすべてのオブジェクトは、リモートPDPにPEPから送られるクライアント固有の情報オブジェクト（ClientSI合図）の内部に封入されている（セクション3.1を参照。単一のRSVPメッセージにパック複数のフローに）。
The PEP and PDP share RSVP state, and the PDP is assumed to implement the same RSVP functional specification as the PEP. In the case where a PDP detects the absence of objects required by [RSVP] it should return an <Error> in the Decision message indicating "Mandatory client-specific info missing". If, on the other hand, the PDP detects the absence of optional RSVP objects that are needed to approve the Request against current policies, the PDP should return a negative <Decision>.
PEPとPDP共有RSVP状態、及びPDPはPEPと同じRSVP機能仕様を実装するために想定されます。 PDPは、[RSVP]で必要なオブジェクトが存在しないことを検出した場合には、「必須クライアント固有の情報が欠落している」を示す決定メッセージに<エラー>を返さなければなりません。一方、PDPは、現在のポリシーに対する要求を承認するために必要なオプションのRSVPオブジェクトの不在を検知した場合、PDPは、負の<決定>を返す必要があります。
Unlike the Incoming and Outgoing contexts, "Resource Allocation" is not always directly associated with a specific RSVP message. In a multicast session, it may represent the merging of multiple incoming reservations. Therefore, the ClientSI object should specifically contain the SESSION and STYLE objects along with the merged FLOWSPEC, FILTERSPEC list, and SCOPE object (whenever relevant).
着信および発信の状況とは異なり、「リソースの割り当ては、」常に直接、特定のRSVPメッセージに関連付けられていません。マルチキャストセッションでは、複数の受信予約のマージを表すことができます。したがって、ClientSIオブジェクトは、具体的にマージFLOWSPEC、FILTERSPECリストと共にSESSIONとスタイルオブジェクトを含むべきであり、SCOPEオブジェクト（たびに関連します）。
COPS provides the PDP with flexible controls over the PEP using RSVP's response to messages. While accepting an RSVP message, PDPs may provide preemption priority, trigger warnings, replace RSVP objects, and much more, using Decision Commands, Flags, and Objects.
COPSメッセージにRSVPの応答を用いてPEPを柔軟にコントロールとPDPを提供します。 RSVPメッセージを受け入れながら、PDPは決定コマンド、フラグ、およびオブジェクトを使用して、プリエンプションの優先順位を提供し、警告をトリガし、RSVPオブジェクトを交換し、より多くのことがあります。
DECISION COMMANDS
DECISIONコマンド
Only two commands apply to RSVP
唯一の2つのコマンドはRSVPに適用されます
Install
インストール
Positive Response: Accept/Allow/Admit an RSVP message or local resource allocation.
肯定的な反応：受け入れる/許可/ RSVPメッセージまたはローカルリソース割り当てを認めます。
Remove
削除する
Negative Response: Deny/Reject/Remove an RSVP message or local resource allocation.
負の応答：/拒否/拒否RSVPメッセージまたはローカルリソースの割り当てを削除します。
DECISION FLAGS
DECISIONのFLAGS
The only decision flag that applies to RSVP:
RSVPにのみ適用され、判定フラグ：
Trigger Error
トリガーエラー
If this flag is set, RSVP should schedule a PathErr, in response to a Path message, or a ResvErr (in response of a Resv message).
このフラグが設定されている場合、RSVPは、Pathメッセージ、または（Resvメッセージの応答で）ResvErrに応答して、のPathErrをスケジュールすべきです。
STATELESS POLICY DATA
STATELESSポリシーデータ
This object may include one or more policy elements (as specified for the RSVP Policy Data object [RSVP-EXT]) which are assumed to be well understood by the client's LPDP. The PEP should consider these as an addition to the decision already received from the PDP (it can only add, but cannot override it).
ウェルクライアントのLPDPによって理解されるものとする（RSVPポリシーデータオブジェクト[RSVP-EXT]に指定されるように）、このオブジェクトは、1つまたは複数のポリシー要素を含むことができます。 PEPはすでにPDPから受け取った意思決定に加え、これらを考慮する必要があります（それだけで追加することができますが、それをオーバーライドすることはできません）。
For example, given Policy Elements that specify a flow's preemption priority, these elements may be included in an incoming Resv message or may be provided by the PDP responding to a query.
例えば、フローの先取り優先順位を指定してポリシーの要素を考えると、これらの要素は、着信Resvメッセージに含まれてもよいし、クエリに応答PDPによって提供されてもよいです。
Stateless objects must be well understood, but not necessarily supported by all PEPs. For example, assuming a standard policy element for preemption priority, it is perfectly legitimate for some PEPs not to support such preemption and to ignore it. The PDP must be careful when using such objects. In particular, it must be prepared for these objects to be ignored by PEPs.
ステートレスオブジェクトはよく理解したが、必ずしも全てのPEPによってサポートされていないする必要があります。例えば、先取り優先順位のための標準的なポリシー要素を仮定し、そのようなプリエンプションをサポートするために、それを無視することなく、いくつかのPEPのために完全に正当なものです。このようなオブジェクトを使用する際にPDPは、注意しなければなりません。特に、のPEPによって無視されるように、これらのオブジェクトのために準備する必要があります。
Stateless Policy Data may be returned in decisions and apply individually to each of the contexts flagged in REQ messages. When applied to Incoming, it is assumed to have been received as a POLICY_DATA object in the incoming message. When applied to Resource Allocation it is assumed to have been received on all merged incoming messages. Last, when applied to outgoing messages it is assumed to have been received in all messages contributing to the outgoing message.
ステートレスポリシーデータは、意思決定に戻り、REQメッセージにフラグが付けられたコンテキストのそれぞれに個別に適用することができます。着信に適用されるとき、着信メッセージでPOLICY_DATAオブジェクトとして受信されたと仮定されます。アロケーションをリソースに適用する場合には、すべてのマージされた受信メッセージに受信されているものとします。送信メッセージに適用されたときに最後には、発信メッセージに貢献するすべてのメッセージで受信されているものとします。
REPLACEMENT DATA
置換データ
The Replacement object may contain multiple RSVP objects to be replaced (from the original RSVP request). Typical replacement is performed on the "Forward Outgoing" request (for instance, replacing outgoing Policy Data), but is not limited, and can also be performed on other contexts (such as "Resources-Allocation Request"). In other cases, replacement of the RSVP FlowSpec object may be useful for controlling resources across a trusted zone (with policy ignorant nodes (PINs). Currently, RSVP clients are only required to allow replacement of three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, but could optionally support replacement of other objects.
代替オブジェクトは、（元のRSVP要求から）交換する複数のRSVPオブジェクトを含んでいてもよいです。典型的な置換は、（発信ポリシーデータを交換する、例えば）「転送発信」の要求に対して行われるが、限定されるものではなく、（例えば、「リソース割り当て要求」など）、他のコンテキストで実行することができます。他の例では、RSVPたFlowSpecオブジェクトの交換は、政策無知ノード（ピン）と（信頼ゾーン間でリソースを制御するために有用である可能性がある現在、RSVPクライアントのみ3つのオブジェクトを交換できるようにする必要があります。、POLICY_DATA、ERROR_SPEC、およびFLOWSPECをしかし、他のオブジェクトのサポートの交換をオプションがあります。
RSVP object replacement is performed in the following manner:
RSVPオブジェクトの交換は、以下のように行われます。
If no Replacement Data decision appears in a decision message, all signaled objects are processed as if the PDP was not there. When an object of a certain C-Num appears, it replaces ALL the instances of C-Num objects in the RSVP message. If it appears empty (with a length of 4) it simply removes all instances of C-Num objects without adding anything.
無置換データの決定は、決定メッセージに表示されない場合はPDPがなかったかのように、すべての合図のオブジェクトが処理されます。特定のC-民のオブジェクトが表示されたら、それは、RSVPメッセージにC-民オブジェクトのすべてのインスタンスを置換します。それは（4の長さで）空の表示された場合には、単に何かを追加することなく、C-ヌムオブジェクトのすべてのインスタンスを削除します。
3 Operation of COPS for RSVP PEPs
RSVPののPEPのためのCOPSの3操作
Policy Control is performed per RSVP flow, which is defined by the atomic unit of an RSVP reservation (TC reservation). Reservation styles may also impact the definition of flows; a set of senders which are considered as a single flow for WF reservation are considered as a set of individual flows when FF style is used.
ポリシー制御は、RSVP予約（TC予約）の原子単位で定義されているRSVPフローごとに行われます。予約スタイルはまた、フローの定義に影響を与えてもよいです。 WFの予約のための単一の流れとして考えられている送信者の組は、FFスタイルが使用されている個々のフローの集合として考えられています。
Multiple FF flows may be packed into a single Resv message. A packed message must be unpacked where a separate request is issued for each of the packed flows as if they were individual RSVP messages. Each COPS Request should include the associated POLICY_DATA objects, which are, by default, all POLICY_DATA objects in the packed message. Sophisticated PEPs, capable of looking inside policy objects, may examine the POLICY_DATA or SCOPE object to narrow down the list of associated flows (as an optimization).
複数FFフローは、単一のResvメッセージにパックすることができます。彼らは、個々のRSVPメッセージであるかのように別々の要求が詰まっフローごとに発行された場所パックのメッセージが展開する必要があります。各COPS要求が詰まったメッセージで、デフォルトでは関連するPOLICY_DATAオブジェクト、すべてのPOLICY_DATAオブジェクトを含める必要があります。ポリシー・オブジェクト内を調べ可能な洗練のPEPは、（最適化のような）関連するフローのリストを絞り込むためPOLICY_DATAまたはSCOPEオブジェクトを調べることができます。
Please note that the rules governing Packed RSVP message apply equally to the Incoming as well as the Outgoing REQ context.
パックドRSVPメッセージを管理するルールが着信と同様に発信REQコンテキストにも同様に適用されますのでご注意ください。
When making a policy decision, the PDP may consider both Resv as well as its matching Path state (associated state). State association is straightforward in the common unicast case since the RSVP flow includes one Path state and one Resv state. In multicast cases this correspondence may be more complicated, as the match may be many-to-many. The COPS protocol assumes that the PDP is RSVP knowledgeable and capable of determining these associations based on the contents of the Client REQ message and especially the ClientSI object.
ポリシー決定を行うとき、PDPはのResvならびにそのマッチングパスの状態（関連する状態）の両方を考慮することができます。 RSVPフローは一つのパス状態と一つのResv状態を含むので、状態の関連付けは、共通ユニキャストの場合に簡単です。一致が多対多であってもよいように、マルチキャストの場合において、この対応関係は、より複雑であってもよいです。 COPSプロトコルは、PDPがRSVP知識とクライアントREQメッセージ及び特にClientSIオブジェクトの内容に基づいて、これらの関連付けを決定することが可能であることを前提としています。
For example, the PDP should be able to recognize activation and deactivation of RSVP blockade state following discrete events like the arrival of a ResvErr message (activate the blockade state) as well as the change in the outgoing Resv message.
例えば、PDPは、ResvErrメッセージ（遮断状態を活性化する）、ならびに発信Resvメッセージの変化の到着など離散イベント以下RSVP遮断状態のアクティブ化および非アクティブ化を認識することができなければなりません。
In RSVP, the admission of a new reservation requires both an administrative approval (policy control) and capacity admission control. After being approved by both, and after the reservation was successfully installed, the PEP notifies the remote PDP by sending a report message specifying the Commit type. The Commit type report message signals when billing should effectively begin and performing heavier delayed operations (e.g., debiting a credit card) is permissible by the PDP.
RSVPでは、新しい予約の入場料は、管理者の承認（ポリシー制御）と容量アドミッション制御の両方が必要です。両方によって承認された後、予約が正常にインストールされた後、PEPは、コミットのタイプを指定してレポートメッセージを送信することにより、リモートPDPに通知します。課金が有効開始し（クレジットカードの引き落とし例えば、）より重い遅延操作を実行する必要があるときタイプレポートメッセージ信号をコミットPDPによって許容されます。
If, instead, a PDP approved reservation fails admission due to lack of resources, the PEP must issue a no-commit report and fold back and send an updated request to its previous state (previously installed reservation). If no state was previously installed, the PEP should issue a delete (DRQ).
代わりに、PDP承認予約はリソース不足のため入場を失敗した場合、PEPは無コミット報告書を発行し、フォールドバックと以前の状態（以前にインストールした予約）に更新要求を送信する必要があります。何の状態が以前にインストールされなかった場合は、PEPは、削除（DRQ）を発行する必要があります。
PathTear and ResvTear messages are not controlled by this policy architecture. This relies on two assumptions: First, that MD-5 authentication verifies that the Tear is received from the same node that sent the initial reservation, and second, that it is functionally equivalent to that node holding off refreshes for this reservation. When a ResvTear or PathTear is received at the PEP, all affected states installed on the PDP should either be deleted or updated by the PEP.
PathTearとたResvTearメッセージは、このポリシーアーキテクチャによって制御されていません。これは、2つの仮定に依存している：まず、MD-5認証が涙は、それがそのノードは、この予約のリフレッシュをオフに保持すると機能的に同等であることを、同じ初期の予約を送信したノード、及び第二から受信されたことを検証します。たResvTearかPathTearがPEPで受信されると、PDPにインストールされているすべての影響を受ける状態がPEPによって削除または更新されなければならないのいずれか。
Because COPS is a stateful protocol, refreshes for RSVP Path and Resv messages need not be constantly sent to the remote PDP. Once a decision has been returned for a request, the PEP can cache that decision and apply it to future refreshes. When the PEP detects a change in the corresponding Resv or Path message, it should update the PDP with the new request-state. PEPs may continue to use the cached state until receiving the PDP response. This case is very different from initial admission of a flow; given that valid credentials and authentication have already been established, the relatively long RSVP refresh period, and the short PEP-PDP response time, the tradeoff between expedient updates and attack prevention leans toward expediency. However, this is really a PEP choice, and is irrelevant to PDPs.
COPSは、ステートフルなプロトコルであるため、RSVPのパスのために更新され、RESVメッセージは、常にリモートPDPに送る必要はありません。決定は、要求に対して返された後、PEPは、その決定をキャッシュし、将来のリフレッシュに適用することができます。 PEPは、対応のResvまたはPathメッセージの変化を検出すると、それは新しい要求状態を有するPDPを更新しなければなりません。 PEPは、PDPの応答を受信するまで、キャッシュされた状態を継続して使用することがあります。この場合は、フローの最初の入場料とは非常に異なっています。有効な資格情報と認証は、すでに確立されていることを考えると、比較的長いRSVPリフレッシュ期間、及び短いPEP-PDPの応答時間は、都合の更新と攻撃の防止との間のトレードオフは、便宜に向かって傾いています。しかし、これは本当にPEPの選択である、とのPDPとは無関係です。
If the connection is lost between the PEP and the PDP, the cached RSVP state may be retained for the RSVP timeout period to be used for previously admitted flows (but cannot be applied to new or updated state). If the connection can not be reestablished with the PDP or a backup PDP after the timeout period, the PEP is expected to purge all its cached decisions. Without applicable cached decision, the PEP must either reject the flow or resort to its LPDP (if available) for decisions.
接続は、PEPとPDPの間に失われた場合、キャッシュされたRSVP状態が以前に許可されたフローのために使用されるRSVPタイムアウト期間のために保持することができる（ただし、新規または更新された状態に適用することはできません）。接続がタイムアウト期間の後にPDPやバックアップPDPを再確立することができない場合は、PEPは、そのすべてのキャッシュされた意思決定をパージすることが期待されます。該当するキャッシュされた意思決定がなければ、PEPは、フローを拒否しなければならないのいずれかまたは意思決定のためにそのLPDP（利用可能な場合）に頼ります。
Once a connection is reestablished to a new (or the original) PDP the PDP may issue a SSQ request. In this case, the PEP must reissue requests that correspond to the current RSVP state (as if all the state has been updated recently). It should also include in its LPDPDecision the current (cached) decision regarding each such state.
接続が新しい（または元）に再確立されると、PDP PDPはSSQ要求を発行することができます。 （すべての状態が最近更新されたかのように）この場合、PEPは、現在のRSVP状態に対応して要求を再発行する必要があります。また、そのLPDPDecisionに、このような各状態に関する現在の（キャッシュ）の決定を含むべきです。
RSVP is a store-and-forward control protocol where messages are processed in three distinctive steps (input, resource allocation, and output). Each step requires a separate policy decision as indicated by context flags (see Section 2.2). In many cases, setting multiple context flags for bundling two or three operations together in one request may significantly optimize protocol operations.
RSVPメッセージは、3つの特徴的な手順（入力、リソース割り当て、および出力）で処理され、ストア・アンド・フォワード制御プロトコルです。各ステップは、コンテキスト・フラグ（セクション2.2を参照）によって示されるように別個のポリシー決定を必要とします。多くの場合、大幅プロトコル動作を最適化することができる1つの要求に2つのまたは3つの操作を束ねるための複数のコンテキスト・フラグを設定します。
The following rules apply for setting multiple Context flags:
次のルールは、複数のコンテキストフラグを設定するために適用されます。
a. Multiple context flags can be set only in two generic cases, which represent a substantial portion of expected COPS transactions, and can be guaranteed not to cause ambiguity.
A。マルチコンテキストフラグが予想されるCOPS取引のかなりの部分を占めるだけに2つの一般的な例を、設定することができ、かつ曖昧さを引き起こすことがないことを保証することができます。
Unicast FF:
ユニキャストFF：
[Incoming + Allocation + Outgoing]
[着信+割当+発信]
Multicast with only one Resv message received on the interface
唯一のResvメッセージでマルチキャストインターフェイスで受信しました
[Incoming + Allocation]
[着信+割当]
b. Context events are ordered by time since every message must first be processed as Incoming, then as Resource allocation and only then as Outgoing. When multiple context flags are set, all ClientSI objects included in the request are assumed to be processed according to the latest flag. This rule applies both to the request (REQ) context as well as to the decision (DEC) context.
B。コンテキストイベントは、すべてのメッセージが最初[リソース配分として、着信として処理だけにして発信などしなければならないので、時間によって順序付けされています。マルチコンテキスト・フラグが設定されている場合、リクエストに含まれる全てClientSIオブジェクトが最新フラグに従って処理されているものとします。このルールは、要求（REQ）のコンテキストにだけでなく、意思決定（DEC）コンテキストの両方に適用されます。
For example, when combining Incoming + Allocation for an incoming Resv message, the flowspec included in the ClientSI would be the one corresponding to the Resource-Allocation context (TC).
受信Resvメッセージの着信+割当てを組み合わせる場合、例えば、フロースペックはClientSIに含まれるリソース割り当てのコンテキスト（TC）に対応するものであろう。
c. Each decision is bound to a context object, which determines which portion of the request context it applies to. When individual decisions apply to different sub-groups of the context, the PDP should send each group of decision objects encapsulated by the context flags object with the context flags applicable to these objects set (see the examples in Section 5).
C。各決定は、それが適用される要求コンテキストの部分を判断するコンテキストオブジェクトにバインドされています。個々の決定は、コンテキストの異なるサブグループに適用すると、PDPは、フラグがセットこれらのオブジェクト（第5の例を参照）に適用可能なコンテキスト・フラグを持つオブジェクトコンテキストによってカプセル化された決定対象の各グループを送信しなければなりません。
RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to report policy errors. While the contents of the ERROR_SPEC object are defined in [RSVP,RSVP-EXT], the PDP is in the best position to provide its contents (sub-codes). This is performed in the following manner: First, the PEP (RSVP) queries the PDP before sending a PathErr or ResvErr, and then the PDP returns the constructed ERROR_SPEC in the Replacement Data Decision Object.
RSVPは、政策の誤りを報告するためのPathErrとResvErrメッセージにERROR_SPECオブジェクトを使用しています。 ERROR_SPECオブジェクトの内容は[RSVP、RSVP-EXT]で定義されているが、PDPは、その内容（サブコード）を提供するための最良の位置にあります。これは以下のように行われる：まず、PEP（RSVP）は、のPathErr又はResvErrを送信する前に、PDPを照会し、その後、PDPは、置換データ判定対象で構築ERROR_SPECを返します。
4 Security Considerations
4つのセキュリティの考慮事項
This document relies on COPS for its signaling and its security. Please refer to section "Security Considerations" in [COPS].
この文書では、そのシグナルとそのセキュリティのためのCOPSに依存しています。 [COPS]セクション「セキュリティの考慮事項」を参照してください。
Security for RSVP messages is provided by inter-router MD5 authentication [MD5], assuming a chain-of-trust model. A likely deployment scenario calls for PEPs to be deployed only at the network edge (boundary nodes) while the core of the network (backbone) consists of PIN nodes. In this scenario MD5 trust (authentication) is established between boundary (non-neighboring) PEPs. Such trust can be achieved through internal signing (integrity) of the Policy Data object itself, which is left unmodified as it passes through PIN nodes (see [RSVP-EXT]).
RSVPメッセージのセキュリティは、チェーン・オブ・信頼モデルを仮定し、ルータ間のMD5認証[MD5]で提供されます。ネットワーク（バックボーン）のコアはPINノードで構成しながらのPEPにのみ、ネットワークエッジ（境界ノード）で展開するための可能性の展開シナリオは、コール。このシナリオではMD5の信頼（認証）が境界（非隣接）のPEPとの間に確立されます。そのような信頼は、それがPINノードを通過するように修飾されていないままであるポリシーデータオブジェクト自体の内部署名（整合性）を介して達成することができる（[RSVP-EXT]を参照）。
5 Illustrative Examples, Using COPS for RSVP
RSVP用COPSを用いて5の例示的な実施例、
This section details both typical unicast and multicast scenarios.
このセクションの詳細の両方典型的なユニキャストおよびマルチキャストのシナリオ。
This section details the steps in using COPS for controlling a Unicast RSVP flow. It details the contents of the COPS messages with respect to Figure 1.
このセクションでは、ユニキャストRSVPフローを制御するためのCOPSを使用する際の手順について詳しく説明します。これは、図1に関してCOPSメッセージの内容を詳しく説明します。
PEP (router)
+-----------------+
| |
R1 ------------+if1 if2+------------ S1
| |
+-----------------+
Figure 1: Unicast Example: a single PEP view
図1：ユニキャスト例：単一PEPビュー
The PEP router has two interfaces (if1, if2). Sender S1 sends to receiver R1.
PEPルータは、二つのインタフェース（IF1、IF2）を有しています。送信者S1は、受信機R1に送信します。
A Path message arrives from S1:
PathメッセージがS1から到着します：
PEP --> PDP REQ := <Handle A> <Context: in & out, Path>
<In-Interface if2> <Out-Interface if1>
<ClientSI: all objects in Path message>
PDP --> PEP DEC := <Handle A> <Context: in & out, Path> <Decision: Command, Install>
PDP - > PEP 12月：>コマンド、インストールしてください：イン＆アウト、パス> <意思決定：= <> <コンテキストハンドル
A Resv message arrives from R1:
Resvメッセージは、R1から到着します：
PEP --> PDP REQ := <Handle B>
<Context: in & allocation & out, Resv>
<In-Interface if1> <Out-Interface if2>
<ClientSI: all objects in Resv message>
PDP --> PEP DEC := <Handle B> <Context: in, Resv> <Decision: command, Install> <Context: allocation, Resv> <Decision: command, Install> <Decision: Stateless, Priority=7> <Context: out, Resv> <Decision: command, Install> <Decision: replacement, POLICY-DATA1>
PDPは、 - > PEP 12月：=は、<B> <コンテキストハンドル：、のResv> <決定において：割当て、のResv> <決定：コマンド、インストール> <決定：ステートレス、優先度= 7> <コマンド> <コンテキストをインストールコンテキスト：アウト、のResv> <意思決定：交換、POLICY-DATA1>：コマンド、> <意思決定をインストールします。
PEP --> PDP RPT := <Handle B> <Report type: commit>
PEP - > PDP RPT：= <ハンドルB> <レポート種別：コミット>
Notice that the Decision was split because of the need to specify different decision objects for different context flags.
決定が異なるため、コンテキストフラグの異なる意思決定のオブジェクトを指定する必要の分割されたことに注意してください。
Time Passes, the PDP changes its decision:
時間が経過し、PDPは、その決定を変更します。
PDP --> PEP DEC := <Handle B>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=3>
Because the priority is too low, the PEP preempts the flow:
優先度が低すぎるので、PEPは、流れを先取り：
PEP --> PDP DRQ := <Handle B>
<Reason Code: Preempted>
Time Passes, the sender S1 ceases to send Path messages:
時間が経過し、送信者S1は、Pathメッセージを送信することなくなりました。
PEP --> PDP DRQ := <Handle A>
<Reason: Timeout>
This section details the steps in using COPS for controlling a multicast RSVP flow. It details the contents of the COPS messages with respect to Figure 2.
このセクションでは、マルチキャストRSVPフローを制御するためのCOPSを使用する際の手順について詳しく説明します。これは、図2に関してCOPSメッセージの内容を詳しく説明します。
PEP (router)
+-----------------+
| |
R1-------------+ if1 if3 +--------- S1
| |
R2----+ | |
| | |
+--------+ if2 if4 +--------- S2
| | |
R3----+ +-----------------+
Figure 2: Multicast example: a single PEP view
図2：マルチキャスト例：単一PEPビュー
Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2) and three receivers (R1, R2, R3) for the same multicast session. Interface if2 is connected to a shared media. In this example, we assume that the multicast membership is already in place. No previous RSVP messages were received, and the first to arrive is a Path message on interface if3 from sender S1:
図2は、2つの送信者（S1、S2）と同じマルチキャストセッションのための3つの受信機（R1、R2、R3）を有するRSVPのPEP（ルータ）を示します。インタフェースIF2は、共有メディアに接続されています。この例では、マルチキャストメンバーシップがすでに適所にあることを前提としています。以前のRSVPメッセージが受信されなかった、そして到着する最初は、送信者S1からインターフェイスIF3にPathメッセージです。
PEP --> PDP REQ := <Handle A> <Context: in, Path>
<In-interface if3>
<ClientSI: all objects in incoming Path>
PDP --> PEP DEC := <Handle A> <Context: in, Path> <Decision: command, Install>
PDP - > PEP 12月：= <> <コンテキストハンドル：、パス> <意思決定に：コマンド、インストールしてください>
The PEP consults its forwarding table, and finds two outgoing interface for the path (if1, if2). The exchange below is for interface if1, another exchange would likewise be completed for if2 using the new handle B2.
PEPは、その転送テーブルを調べ、パス（IF1、IF2）のための2つの出力インターフェースを見出します。以下の交換は、インターフェースIF1のために、別の交換は同様に、新たなハンドルB2を使用してIF2のために完了されるだろうさ。
PEP --> PDP REQ := <Handle B1> <Context: out, Path>
<Out-interface if1>
<clientSI: all objects in outgoing Path>
PDP --> PEP DEC := <Handle B1> <Context: out, Path> <Decision: command, Install> <Decision: Replacement, POLICY-DATA1>
PDP - > PEP 12月：= <ハンドルB1> <コンテキスト：アウト、パス> <意思決定：コマンド、インストールしてください> <意思決定：交換、POLICY-DATA1>
Here, the PDP decided to allow the forwarding of the Path message and provided the appropriate policy-data object for interface if1.
ここで、PDPは、Pathメッセージの転送を可能にすることを決めたとインターフェースIF1のための適切なポリシー・データ・オブジェクトを提供しました。
Next, a WF Resv message from receiver R2 arrives on interface if2.
次に、受信機R2からWF Resvメッセージは、インタフェースIF2上に到達します。
PEP --> PDP REQ := <Handle C> <Context: in & allocation, Resv>
<In-interface if2>
<ClientSI: all objects in Resv message
including RSpec1 >
PDP --> PEP DEC := <Handle C> <Context: in, Resv> <Decision: command, Install> <Context: allocation, Resv> <Decision: command, Install> <Decision: Stateless, priority=5>
PDP - > PEP 12月：= <C> <コンテキストハンドル：コマンド、インストール> <コンテキスト：割当て、のResv> <決定：、のResv> <決定にコマンド> <決定をインストール：ステートレス、優先度= 5>
PEP --> PDP RPT := <handle C> <Commit>
PEP - > PDP RPT：= <ハンドルC> <コミット>
Here, the PDP approves the reservation and assigned it preemption priority of 5. The PEP responded with a commit report.
ここで、PDPは予約を承認し、PEPがコミットレポートで応答し、それを5の先取優先順位を割り当てます。
The PEP needs to forward the Resv message upstream toward S1:
PEPは、S1に向かって上流のResvメッセージを転送する必要があります。
PEP --> PDP REQ := <Handle E> <Context: out, Resv>
<out-interface if3>
<Client info: all objects in outgoing Resv>
PDP --> PEP DEC := <Handle E> <Context: out, Resv> <Decision: command, Install> <Decision: replacement, POLICY-DATA2>
PDP - > PEP 12月：アウト、のResv> <意思決定：：= <E> <コンテキストハンドルのコマンドを、> <意思決定をインストールします交換、POLICY-DATA2>
Note: The Context object is part of this DEC message even though it may look redundant since the REQ specified only one context flag.
注：コンテキストオブジェクトは、REQが一つだけコンテキストフラグを指定したので、冗長に見える場合であっても、このDECメッセージの一部です。
Next, a new WF Resv message from receiver R3 arrives on interface if2 with a higher RSpec (Rspec2). Given two reservations arrived on if2, it cannot perform a request with multiple context flags, and must issue them separately.
次に、受信機R3から新しいWF Resvメッセージは、より高いRSpecの（Rspec2）とのインタフェースIF2上に到達します。 2件の予約がIF2に到着考えると、それは、マルチコンテキストフラグで要求を実行することはできませんし、それらを別々に発行する必要があります。
The PEP re-issues an updated handle C REQ with a new context object <Context: in , Resv>, and receives a DEC for handle C.
PEPの再発行新しいコンテキストオブジェクトを使用して更新されたハンドルCのREQ <コンテキスト：のResv、中>、およびハンドルC.のために12月を受け取ります
PEP --> PDP REQ := <Handle F> <Context: in , Resv>
<In-interface if2>
<ClientSI: all objects in Resv message
including RSpec2 >
PDP --> PEP DEC := <Handle F> <Context: in , Resv> <Decision: command, Install>
PDP - > PEP 12月：= <F> <コンテキストハンドル：、のResv> <意思決定に：コマンド、インストールしてください>
PEP --> PDP REQ := <Handle G> <Context: allocation, Resv> <In-interface if2> <ClientSI: all objects in merged Resv including RSpec2 >
PEP - > PDP REQ：= <G> <コンテキストハンドル：割当て、のResv> <インインタフェースIF2> <ClientSI：RSpec2含むマージのResv内のすべてのオブジェクト>
PDP --> PEP DEC := <Handle G> <Context: allocation, Resv> <Decision: command, Install> <Decision: Stateless, Priority=5>
PDP - > PEP 12月：割当て、のResv> <決定：= <G> <コンテキストハンドルコマンドを、> <決定をインストール：ステートレス、優先度= 5>
PEP --> PDP RPT := <handle G> <Commit>
PEP - > PDP RPT：= <> <コミットG>ハンドル
Given the change in incoming reservations, the PEP needs to forward a new outgoing Resv message upstream toward S1. This repeats exactly the previous interaction of Handle E, except that the ClientSI objects now reflect the merging of two reservations.
入ってくるの予約の変化を考えると、PEPはS1に向かって上流に新しい送信Resvメッセージを転送する必要があります。これはClientSIオブジェクトは現在2つの予約のマージを反映していることを除いて、正確にハンドルEの前の相互作用を繰り返します。
If an ResvErr arrives from S1, the PEP maps it to R3 only (because it has a higher flowspec: Rspec2) the following takes place:
以下は、場所取りますResvErrはS1から到着した場合、PEPは（Rspec2それが高いフロースペックを持っているので）のみR3にマップします：
PEP --> PDP REQ := <Handle H> <Context: in, ResvErr>
<In-interface if3>
<ClientSI: all objects in incoming ResvErr>
PDP --> PEP DEC := <Handle H> <Context: in, ResvErr> <Decision: command, Install>
PDP - > PEP 12月：= <H> <コンテキストハンドル：、ResvErrに> <決定：コマンド、インストール>
PEP --> PDP REQ := <Handle I> <Context: out, ResvErr> <Out-interface if2> <ClientSI: all objects in outgoing ResvErr>
PEP - > PDP REQ：アウト、ResvErr> <アウト・インターフェースIF2> <ClientSI：：送信ResvErr内のすべてのオブジェクト> = <I> <コンテキストハンドル
PDP --> PEP DEC := <Handle I> <Context: out, ResvErr> <Decision: command, Install> <Decision: Replacement, POLICY-DATA3>
PDP - > PEP 12月：= <ハンドルI> <コンテキスト：アウト、ResvErr> <意思決定：コマンド、インストールしてください> <意思決定：交換、POLICY-DATA3>
When S2 joins the session by sending a Path message, incoming and outgoing Path requests are issued for the new Path. A new outgoing Resv request would be sent to S2.
S2は、Pathメッセージを送信することにより、セッションに参加すると、着信および発信パスの要求は、新しいパスのために発行されています。新しい出たResv要求がS2に送信されます。
6 References
6つの参考文献
[RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RSVP-EXT]ヘルツォーク、S.、 "ポリシー制御のためのRSVP拡張機能"、RFC 2750、2000年1月。
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000.
[RAP] Yavatkar、R.、Pendarakis、D.とR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[COPS]ボイル、J.、コーエン、R.、ダーラム、D.、ヘルツォーク、S.、ラジャ、R.とA. Sastry、 "COPS（コモンオープンポリシーサービス）プロトコル"、RFC 2748、2000年1月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997.
[RSVP]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - 機能的な仕様"、RFC 2205、1997年9月。
7 Author Information and Acknowledgments
7著者の情報と謝辞
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan, and Raj Yavatkar, for their valuable contributions.
彼らの貴重な貢献のためのアンドリュー・スミスとティモシーオマリー私たちのWGの議長、フレッド・ベイカー、ローラ・カニンガム、ラッセルFenger、ロッホゲラン、Pingのパン、そしてラジYavatkarに感謝、。
Jim Boyle Level 3 Communications 1025 Eldorado Boulevard Broomfield, CO 80021
ジム・ボイルレベル3コミュニケーションズ1025エルドラド大通りブルームフィールド、CO 80021
Phone: 720.888.1192 EMail: jboyle@Level3.net
電話：720.888.1192 Eメール：jboyle@Level3.net
Ron Cohen CISCO Systems 4 Maskit St. Herzeliya Pituach 46766 Israel
ロン・コーエンシスコシステムズ4 MaskitセントHerzeliya Pituach 46766イスラエル
Phone: 972.9.9700064 EMail: ronc@cisco.com
電話：972.9.9700064 Eメール：ronc@cisco.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
デビッド・ダーラムインテル2111 NE 25日アベニューヒルズボロ、OR 97124
Phone: 503.264.6232 EMail: David.Durham@intel.com
電話：503.264.6232 Eメール：David.Durham@intel.com
Raju Rajan AT&T Labs Research 180 Park Ave., P.O. Box 971 Florham Park, NJ 07932
ラジュラジャンAT＆T Labsの研究180パークアベニュー、P。ボックス971フローラムパーク、NJ 07932
Phone: 973.360.7229 EMail: raju@research.att.com
電話：973.360.7229 Eメール：raju@research.att.com
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
シャイヘルツォークIPHighway社55ニューヨーク・アベニューフラミンガム、MA 01701
Phone: 508.620.1141 EMail: herzog@iphighway.com
電話：508.620.1141 Eメール：herzog@iphighway.com
Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge, Middlesex UB11 1BN UK
アルンSastryシスコシステムズ4スクエアストックリーパークアクスブリッジ、ミドルUB11 1BN英国
Phone: +44-208-756-8693 EMail: asastry@cisco.com
電話：+ 44-208-756-8693電子メール：asastry@cisco.com
8 Full Copyright Statement
8フル著作権声明
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機能のための基金は現在、インターネット協会によって提供されます。