[要約] RFC 2749は、RSVP（Resource Reservation Protocol）のためのCOPS（Common Open Policy Service）の使用方法についての要約です。このRFCの目的は、RSVPのポリシー管理を改善し、ネットワークリソースの効率的な予約を実現することです。
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
RSVPのCOPSの使用
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.
Copyright（c）The Internet Society（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は、主にネットワークリソースの要求に対するポリシーベースの入場管理を提供するためのメカニズムとして使用するために、IETFのRSVP入場ポリシーワーキンググループ（RAP 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]プロトコルの事前知識に基づいており、前提としています。RSVPクライアント（PEPS）によるポリシーサーバー（PDP）へのアウトソーシングポリシー管理の決定におけるCOPを使用するための特定の使用指令を提供します。
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.
複数のCOPSオブジェクトの使用は、RSVPクライアントタイプで使用すると影響を受けます。このセクションでは、これらのオブジェクトとその使用について説明します。
RSVP is COPS client-type 1
RSVPはCOPSクライアントタイプ1です
The semantics of the Context object for RSVP is as follows:
RSVPのコンテキストオブジェクトのセマンティクスは次のとおりです。
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.
このコンテキストは、PEPが着信RSVPメッセージを受信したときに使用されます。PDPは、着信メッセージを受け入れるか拒否することを決定する場合があり、他の決定オブジェクトを適用することもできます。着信メッセージが拒否された場合、RSVPは到着しないかのように扱う必要があります。
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).
このコンテキストは、PEPがローカルリソースをRSVPフローにコミットしようとしているときに使用されます（入場制御）。このコンテキストは、RESVメッセージのみに適用されます。ローカルリソースをコミットするかどうかの決定は、RSVPフローに関連するすべての予約のマージ（特定のインターフェイスに到着した可能性がある）のために行われます。
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.
このコンテキストは、PEPが発信RSVPメッセージを転送しようとしているときに使用されます。PDPは、発信メッセージを許可または拒否し、発信ポリシーデータオブジェクトを提供することを決定する場合があります。
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].
コンテキストオブジェクトのM型フィールドは、該当するRSVPメッセージタイプを識別します。M型値は、RSVPヘッダー[RSVP]の「MSGタイプ」フィールドで使用される値と同一です。
The following RSVP message types are supported in COPS:
次のRSVPメッセージタイプは警官でサポートされています。
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メッセージで受信されたすべてのオブジェクトは、PEPからリモートPDPに送信されたクライアント固有の情報オブジェクト（シグナル付きクライアント）内にカプセル化されます（単一のRSVPメッセージに詰められた複数のフローについてセクション3.1を参照）。
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機能仕様を実装すると想定されています。[RSVP]が必要とするオブジェクトの存在をPDPが検出する場合、「義務的なクライアント固有の情報が欠落している」を示す決定メッセージで<エラー>を返す必要があります。一方、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リスト、およびスコープオブジェクト（関連する場合）とともに、セッションおよびスタイルオブジェクトを特に含める必要があります。
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メッセージを受け入れている間、PDPSは、先制の優先順位を提供し、警告をトリガーし、RSVPオブジェクトを置き換えて、決定コマンド、フラグ、およびオブジェクトを使用して、その他多くを提供する場合があります。
DECISION COMMANDS
決定コマンド
Only two commands apply to RSVP
RSVPに適用されるコマンドは2つだけです
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
決定フラグ
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はパスメッセージまたはRESVERR（RESVメッセージの応答で）に応じてPatherrをスケジュールする必要があります。
STATELESS POLICY DATA
ステートレスポリシーデータ
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によってよく理解されていると想定される1つ以上のポリシー要素（RSVPポリシーデータオブジェクト[RSVP-Ext]に指定）が含まれる場合があります。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は注意する必要があります。特に、これらのオブジェクトがPEPSによって無視されるように準備する必要があります。
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オブジェクトの交換は、信頼できるゾーン全体のリソースを制御するのに役立つ場合があります（ポリシー無知ノード（PIN）。現在、RSVPクライアントは、Policy_Data、Error_Spec、およびFlowsPec、FlowsPecの3つのオブジェクトの交換を許可するためにのみ必要です。ただし、オプションで他のオブジェクトの交換をサポートできます。
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-Numのオブジェクトが表示されると、RSVPメッセージ内のC-Numオブジェクトのすべてのインスタンスを置き換えます。空のように見える場合（4の長さ）、何も追加せずにC-Numオブジェクトのすべてのインスタンスを削除するだけです。
3 Operation of COPS for RSVP PEPs
3 RSVP PEPSのCOPSの操作
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フローごとに実行されます。これは、RSVP予約（TC予約）の原子単位によって定義されます。予約スタイルは、フローの定義にも影響を与える可能性があります。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フローには1つのパス状態と1つのRESV状態が含まれるため、州協会は一般的なユニキャストの場合に簡単です。マルチキャストの場合、この対応はより複雑になる可能性があります。COPSプロトコルは、PDPがRSVPの知識が豊富であり、クライアントReqメッセージ、特にクライアントオブジェクトの内容に基づいてこれらの関連付けを決定できると想定しています。
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に通知します。請求が効果的に開始され、より重い遅延操作を実行する場合（クレジットカードをデビットするなど）、Commitタイプのレポートメッセージ信号は、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はdelete（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つの仮定に依存しています。1つ目は、MD-5認証は、裂傷が最初の予約を送信したのと同じノードから受信されることを確認し、次に、このノードがこの予約のリフレッシュを抑えることと機能的に同等であることを確認します。PEPでresvtearまたはPathtearを受信すると、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またはパスメッセージの変更を検出すると、新しいリクエストステートでPDPを更新する必要があります。PEPSは、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を参照）。多くの場合、2つまたは3つの操作を1つのリクエストでバンドルするための複数のコンテキストフラグを設定すると、プロトコル操作が大幅に最適化される場合があります。
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. 複数のコンテキストフラグは、2つの一般的なケースでのみ設定できます。これは、予想されるCOPSトランザクションのかなりの部分を表し、あいまいさを引き起こさないことを保証できます。
Unicast FF:
ユニキャストFF：
[Incoming + Allocation + Outgoing]
[着信割り当て発信]
Multicast with only one Resv message received on the interface
インターフェイスで受信したRESVメッセージが1つだけのマルチキャスト
[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. コンテキストイベントは、すべてのメッセージを最初に着信として処理し、次にリソース割り当てとして、次に発信としてのみ処理する必要があるため、時間によって順序付けられます。複数のコンテキストフラグが設定されている場合、リクエストに含まれるすべてのクライアントオブジェクトは、最新のフラグに従って処理されると想定されます。このルールは、リクエスト（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メッセージに組み合わせる場合、クライアントに含まれるFlowsPecは、リソースへの配分コンテキスト（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]のセクション「セキュリティ上の考慮事項」を参照してください。
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]によって提供されます。可能性のある展開シナリオでは、ネットワークのコア（バックボーン）はピンノードで構成されている間、ネットワークエッジ（境界ノード）でのみPEPを展開する必要があります。このシナリオでは、MD5 Trust（認証）が境界（非潜在）PEPの間に確立されます。このような信頼は、ポリシーデータオブジェクト自体の内部署名（整合性）を通じて達成できます。これは、ピンノードを通過する際に修正されていません（[rsvp-ext]を参照）。
5 Illustrative Examples, Using COPS for RSVP
RSVPにCOPを使用した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.
このセクションでは、Unicast RSVPフローを制御するためにCOPSを使用する手順について詳しく説明します。図1に関するCOPSメッセージの内容を詳しく説明しています。
PEP (router)
+-----------------+
| |
R1 ------------+if1 if2+------------ S1
| |
+-----------------+
Figure 1: Unicast Example: a single PEP view
図1：ユニキャストの例：単一のペップビュー
The PEP router has two interfaces (if1, if2). Sender S1 sends to receiver R1.
PEPルーターには2つのインターフェイス（IF1、IF2）があります。送信者S1はレシーバーR1に送信します。
A Path message arrives from S1:
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>
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>
PEP --> PDP RPT := <Handle B>
<Report type: commit>
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はパスメッセージを送信しなくなります。
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：マルチキャストの例：単一のペップビュー
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（Router）を示しています。インターフェイスIF2は共有メディアに接続されています。この例では、マルチキャストメンバーシップがすでに導入されていると想定しています。以前のRSVPメッセージは受信されず、最初に到着したのは、送信者S1からのインターフェイスIF3のパスメッセージです。
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>
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は転送テーブルに相談し、パスの2つの発信インターフェイスを見つけます（IF1、IF2）。以下の交換はインターフェイス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>
Here, the PDP decided to allow the forwarding of the Path message and provided the appropriate policy-data object for interface if1.
ここで、PDPはパスメッセージの転送を許可することを決定し、インターフェイス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>
PEP --> PDP RPT := <handle C> <Commit>
Here, the PDP approves the reservation and assigned it preemption priority of 5. The PEP responded with a commit report.
ここで、PDPは予約を承認し、5のプリエンプション優先度を割り当てました。PEPはコミットレポートで応答しました。
The PEP needs to forward the Resv message upstream toward S1:
PEPは、RESVメッセージを上流のS1に転送する必要があります。
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>
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が1つのコンテキストフラグのみを指定しているため、冗長に見える場合がありますが、この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に到着します。IF2に2つの予約が届いたため、複数のコンテキストフラグを使用してリクエストを実行することはできず、個別に発行する必要があります。
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を再発行します<コンテキスト：in、resv>、およびハンドルCのDECを受信します。
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>
PEP --> PDP REQ := <Handle G> <Context: allocation, Resv>
<In-interface if2>
<ClientSI: all objects in merged Resv
including RSpec2 >
PDP --> PEP DEC := <Handle G>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=5>
PEP --> PDP RPT := <handle G> <Commit>
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は新しい発信RESVメッセージをS1に上流に転送する必要があります。これは、クライアントオブジェクトが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はR3のみにマップします（FlowsPec：RSPEC2が高いため）次のことが行われます。
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>
PEP --> PDP REQ := <Handle I> <Context: out, ResvErr>
<Out-interface if2>
<ClientSI: all objects in outgoing ResvErr>
PDP --> PEP DEC := <Handle I>
<Context: out, ResvErr>
<Decision: command, Install>
<Decision: Replacement, 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がパスメッセージを送信してセッションに参加すると、新しいパスに対して着信パスリクエストと発信パス要求が発行されます。新しい発信RESV要求がS2に送信されます。
6 References
6リファレンス
[RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RSVP-Ext] Herzog、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。and R. Guerin、「政策ベースの入場管理の枠組み」、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.
[警官]ボイル、J。、コーエン、R。、ダーラム、D。、ヘルツォグ、S。、ラジャ、R。、A。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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.
Andrew SmithとTimothy O'MalleyのWGチェア、Fred Baker、Laura Cunningham、Russell Fenger、Roch Guerin、Ping Pan、およびRaj Yavatkarに感謝します。
Jim Boyle Level 3 Communications 1025 Eldorado Boulevard Broomfield, CO 80021
ジムボイルレベル3コミュニケーション1025エルドラドブルバードブルームフィールド、コロラド州80021
Phone: 720.888.1192 EMail: jboyle@Level3.net
電話：720.888.1192メール：jboyle@level3.net
Ron Cohen CISCO Systems 4 Maskit St. Herzeliya Pituach 46766 Israel
Ron Cohen Cisco Systems 4 Maskit St. Herzeliya Pituach 46766 Israel
Phone: 972.9.9700064 EMail: ronc@cisco.com
電話：972.9.9700064メール：ronc@cisco.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
David Durham Intel 2111 NE 25th Avenue Hillsboro、または97124
Phone: 503.264.6232 EMail: David.Durham@intel.com
電話：503.264.6232メール：David.durham@intel.com
Raju Rajan AT&T Labs Research 180 Park Ave., P.O. Box 971 Florham Park, NJ 07932
Raju Rajan AT＆T Labs Research 180 Park Ave.、P.O。Box 971 Florham Park、NJ 07932
Phone: 973.360.7229 EMail: raju@research.att.com Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
電話：973.360.7229メール：raju@research.att.com Shai Herzog Iphighway、Inc。55 New York Avenue Framingham、MA 01701
Phone: 508.620.1141 EMail: herzog@iphighway.com
電話：508.620.1141メール：herzog@iphighway.com
Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge, Middlesex UB11 1BN UK
Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge、Middlesex UB11 1bn UK
Phone: +44-208-756-8693
EMail: asastry@cisco.com
8 Full Copyright Statement
8完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。