Network Working Group S. Herzog
Request for Comments: 2750 IPHighway
Updates: 2205 January 2000
Category: Standards Track
RSVP Extensions for Policy Control
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 memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional specifications [RSVP]
このメモはRSVPに、一般的なポリシーベースのアドミッション制御をサポートするための拡張セットを提供します。これは、RSVP機能仕様[RSVP]の拡張として認識されるべきです
These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events.
これらの拡張機能は、POLICY_DATAオブジェクトの標準フォーマット、およびポリシーイベントのRSVPの取り扱いについての説明が含まれています。
This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in [RAP, COPS, COPS-RSVP].
この文書では、特定のポリシー制御メカニズムを提唱しません。しかし、これらの拡張のためのルーター/ Serverポリシープロトコルの記述は[RAP、COPS、COPS-RSVP]で見つけることができます。
Table of Contents
目次
1 Introduction.......................................................2
2 A Simple Scenario..................................................3
3 Policy Data Objects................................................3
3.1 Base Format.....................................................4
3.2 Options.........................................................4
3.3 Policy Elements.................................................7
3.4 Purging Policy State............................................7
4 Processing Rules...................................................8
4.1 Basic Signaling.................................................8
4.2 Default Handling for PIN nodes..................................8
4.3 Error Signaling.................................................9
5 IANA Considerations................................................9
6 Security Considerations............................................9
7 References........................................................10
8 Acknowledgments...................................................10
9 Author Information................................................10
Appendix A: Policy Error Codes......................................11
Appendix B: INTEGRITY computation for POLICY_DATA objects...........12
Full Copyright Statement ...........................................13
1 Introduction
1はじめに
RSVP, by definition, discriminates between users, by providing some users with better service at the expense of others. Therefore, it is reasonable to expect that RSVP be accompanied by mechanisms for controlling and enforcing access and usage policies. Version 1 of the RSVP Functional Specifications [RSVP] left a placeholder for policy support in the form of POLICY_DATA object.
RSVPは、定義によって、他人を犠牲にしてより良いサービスを一部のユーザーに提供することで、ユーザーを区別する。したがって、そのRSVPを制御し、アクセスと利用ポリシーを強制するためのメカニズムを伴うことが予想するのが妥当です。 RSVP機能仕様のバージョン1 [RSVP]はPOLICY_DATAオブジェクトの形でポリシーをサポートするためのプレースホルダを残しました。
The current RSVP Functional Specification describes the interface to admission (traffic) control that is based "only" on resource availability. In this document we describe a set of extensions to RSVP for supporting policy based admission control as well. The scope of this document is limited to these extensions and does not advocate specific architectures for policy based controls.
現在のRSVP機能仕様は、リソースの可用性に「のみ」ベースであることを承認する（トラフィック）コントロールへのインタフェースを記述します。この文書では我々としても、ポリシーベースのアドミッション制御をサポートするためのRSVPへの拡張機能のセットを記述します。この文書の範囲は、これらの拡張機能に制限され、ポリシーベースのコントロールのための具体的なアーキテクチャを提唱しません。
For the purpose of this document we do not differentiate between Policy Decision Point (PDP) and Local Decision Point (LDPs) as described in [RAP]. The term PDP should be assumed to include LDP as well.
[RAP]で説明したように、このドキュメントの目的のために、私たちは、ポリシー決定ポイント（PDP）およびローカル決定ポイント（LDPs）を区別しません。用語PDPもLDPを含むものとすべきです。
2 A Simple Scenario
2単純なシナリオ
It is generally assumed that policy enforcement (at least in its initial stages) is likely to concentrate on border nodes between autonomous systems.
一般的に（少なくともその初期段階での）ポリシーの施行が自律システム間の境界ノードに集中する可能性があることを想定しています。
Figure 1 illustrates a simple autonomous domain with two boundary nodes (A, C) which represent PEPs controlled by PDPs. A core node (B) represents an RSVP capable policy ignorant node (PIN) with capabilities limited to default policy handling (Section 4.2).
図1は、プラズマディスプレイパネルにより制御のPEPを表す2つの境界ノード（A、C）を持つ単純な自律的なドメインを示します。コアノード（B）は（セクション4.2）を処理ポリシーをデフォルトに限ら機能を持つRSVP可能なポリシー無知ノード（PIN）を表します。
PDP1 PDP2
| |
| |
+---+ +---+ +---+
| A +---------+ B +---------+ C |
+---+ +---+ +---+
PEP2 PIN PEP2
Figure 1: Autonomous Domain scenario
図1：自律ドメインのシナリオ
Here, policy objects transmitted across the domain traverse an intermediate PIN node (B) that is allowed to process RSVP message but considered non-trusted for handling policy information.
ここで、ドメインを介して送信ポリシー・オブジェクトは、RSVPメッセージを処理させるが、非信頼ポリシー情報を処理するために考えられている中間PINノード（B）を横切ります。
This document describes processing rules for both PEP as well as PIN nodes.
この文書では、PEPならびにPINノードの両方のための処理ルールを記載しています。
3 Policy Data Objects
3つのポリシーデータオブジェクト
POLICY_DATA objects are carried by RSVP messages and contain policy information. All policy-capable nodes (at any location in the network) can generate, modify, or remove policy objects, even when senders or receivers do not provide, and may not even be aware of policy data objects.
POLICY_DATAオブジェクトは、RSVPメッセージによって運ばれ、ポリシー情報が含まれています。 （ネットワーク内の任意の場所で）すべてのポリシー可能なノードは、生成、変更、またはポリシーオブジェクトを削除し、送信者または受信機が提供しない場合であっても、さらにはポリシー・データ・オブジェクトを認識しないかもしれないことができます。
The exchange of POLICY_DATA objects between policy-capable nodes along the data path, supports the generation of consistent end-to-end policies. Furthermore, such policies can be successfully deployed across multiple administrative domains when border nodes manipulate and translate POLICY_DATA objects according to established sets of bilateral agreements.
データパスに沿った政策対応ノード間POLICY_DATAオブジェクトの交換は、一貫性のあるエンドツーエンドポリシーの生成をサポートします。さらに、そのようなポリシーは、正常ボーダーノードが操作したときに、複数の管理ドメイン全体に展開し、二国間協定の確立されたセットに係るPOLICY_DATAオブジェクトを変換することができます。
The following extends section A.13 in [RSVP].
以下は[RSVP]でセクションA.13を拡張します。
POLICY_DATA class=14
POLICY_DATAクラス= 14
o Type 1 POLICY_DATA object: Class=14, C-Type=1
O型1 POLICY_DATAオブジェクト：クラス= 14、C-タイプ= 1
+-------------+-------------+-------------+-------------+
| Length | POLICY_DATA | 1 |
+---------------------------+-------------+-------------+
| Data Offset | 0 (reserved) |
+---------------------------+-------------+-------------+
| |
// Option List //
| |
+-------------------------------------------------------+
| |
// Policy Element List //
| |
+-------------------------------------------------------+
Data Offset: 16 bits
データは、オフセット：16ビット
The offset in bytes of the data portion (from the first
byte of the object header).
Reserved: 16 bits
予約：16ビット
Always 0.
常に0。
Option List: Variable length
オプションのリスト：可変長
The list of options and their usage is defined in Section
3.2.
Policy Element List: Variable length
ポリシー要素の一覧：可変長
The contents of policy elements is opaque to RSVP. See more
details in Section 3.3.
This section describes a set of options that may appear in POLICY_DATA objects. All policy options appear as RSVP objects but their semantic is modified when used as policy data options.
このセクションでは、POLICY_DATAオブジェクトに表示される場合がありますオプションのセットを記述します。すべてのポリシーオプションは、RSVPオブジェクトとして表示されますが、ポリシーデータのオプションとして使用された場合、そのセマンティックが変更されました。
FILTER_SPEC object (list) or SCOPE object
FILTER_SPECオブジェクト（リスト）またはSCOPEオブジェクト
These objects describe the set of senders associated with the POLICY_DATA object. If none is provided, the policy information is assumed to be associated with all the flows of the session. These two types of objects are mutually exclusive, and cannot be mixed.
これらのオブジェクトはPOLICY_DATAオブジェクトに関連付けられた送信者のセットを記述する。何も提供されていない場合、ポリシー情報は、セッションのすべてのフローに関連付けされているものとします。オブジェクトのこれらの2つのタイプが相互に排他的である、と混在させることはできません。
In Packed FF Resv messages, this FILTER_SPEC option provides association between a reserved flow and its POLICY_DATA objects.
パックされたFF RESVメッセージにおいて、このFILTER_SPECオプションは、予約フローとそのPOLICY_DATAオブジェクト間の関連付けを提供します。
In WF or SE styles, this option preserves the original flow/POLICY_DATA association as formed by PDPs, even across RSVP capable PINs. Such preservation is required since PIN nodes may change the list of reserved flows on a per-hop basis, irrespective of legitimate Edge-to-Edge PDP policy considerations.
WF又はSEスタイルでは、このオプションがあってもRSVP可能なピンに、プラズマディスプレイパネルにより形成された元のフロー/ POLICY_DATAの関連付けを保存します。 PINノードにかかわらず正当エッジツーエッジPDPポリシーの考慮の、ホップごとのベースで予約フローのリストを変更することができるので、このような保存が必要です。
Last, the SCOPE object should be used to prevent "policy loops" in a manner similar to the one described in [RSVP], Section 3.4. When PIN nodes are part of a WF reservation path, the RSVP SCOPE object is unable to prevent policy loops and the separate policy SCOPE object is required.
最後に、SCOPEオブジェクトは[RSVP]に記載のもの、3.4節と同様に、「ポリシーループ」を防止するために使用されるべきです。 PINノードはWF予約パスの一部である場合、RSVPスコープオブジェクトは、ポリシーループを防止することができず、別のポリシー・スコープ・オブジェクトが必要です。
Note: using the SCOPE option may have significant impact on scaling and size of POLICY_DATA objects.
注意：SCOPEオプションを使用すると、スケーリング、POLICY_DATAオブジェクトのサイズに大きな影響を与える可能性があります。
Originating RSVP_HOP
発信RSVP_HOP
The RSVP_HOP object identifies the neighbor/peer policy-capable node that constructed the policy object. When policy is enforced at border nodes, peer policy nodes may be several RSVP hops away from each other and the originating RSVP_HOP is the basis for the mechanism that allows them to recognize each other and communicate safely and directly.
RSVP_HOPオブジェクトは、ポリシー・オブジェクトを構築ネイバー/ピアポリシー可能なノードを識別する。ポリシーが境界ノードで適用された場合、ピアポリシーノードは、いくつかのRSVPであってもよい互いに離れるホップと発信RSVP_HOPは、それらが互いを認識し、安全と直接通信することを可能にする機構の基礎です。
If no RSVP_HOP object is present, the policy data is implicitly assumed to have been constructed by the RSVP_HOP indicated in the RSVP message itself (i.e., the neighboring RSVP node is policy-capable).
何RSVP_HOPオブジェクトが存在しない場合RSVP_HOPがRSVPメッセージ自体に示されていることにより、ポリシーデータは、暗黙的に構築されているものとする（すなわち、隣接RSVPノードは、ポリシーが可能です）。
Destination RSVP_HOP
先RSVP_HOP
A second RSVP_HOP object may follow the originating RSVP_HOP object. This second RSVP_HOP identifies the destination policy node. This is used to ensure the POLICY_DATA object is delivered to targeted policy nodes. It may be used to emulate unicast delivery in multicast Path messages. It may also help prevent using a policy object in other parts of the network (replay attack).
第RSVP_HOPオブジェクトは、発信RSVP_HOPオブジェクトに従うことができます。この第二RSVP_HOP先ポリシーノードを識別する。これはtargetedポリシーノードに配信されるPOLICY_DATAオブジェクトを確実にするために使用されます。マルチキャストPathメッセージにユニキャスト配信をエミュレートするために使用することができます。また、ネットワーク（リプレイ攻撃）の他の部分でのポリシーオブジェクトを使用して予防に役立つことがあります。
On the receiving side, a policy node should ignore any POLICY_DATA that includes a destination RSVP_HOP that doesn't match its own IP address.
受信側では、ポリシーノードは、自身のIPアドレスと一致しない送信先RSVP_HOPを含む任意POLICY_DATAを無視すべきです。
INTEGRITY Object
INTEGRITYオブジェクト
Figure 1 (Section 2) provides an example where POLICY_DATA objects are transmitted between boundary nodes while traversing non-secure PIN nodes. In this scenario, the RSVP integrity mechanism becomes ineffective since it places policy trust with intermediate PIN nodes (which are trusted to perform RSVP signaling but not to perform policy decisions or manipulations).
図1（第2）非セキュアPINノードをトラバースしながらPOLICY_DATAオブジェクトが境界ノードの間で伝送される例を提供します。それは（RSVPシグナリングを実行するために信頼されているが、政策決定や操作を行わない）の中間PINノードとの政策の信頼を置くので、このシナリオでは、RSVPの整合性のメカニズムは無効になります。
The INTEGRITY object option inside POLICY_DATA object creates direct secure communications between non-neighboring PEPs (and their controlling PDPs) without involving PIN nodes.
POLICY_DATAオブジェクト内部INTEGRITYオブジェクトオプションは、PINノードを伴うことなく、非隣接のPEP（およびそれらの制御のPDP）との間の直接的な安全な通信を作成します。
This option can be used at the discretion of PDPs, and is computed in a manner described in Appendix B.
このオプションは、プラズマディスプレイパネルの裁量で使用することができ、および付録Bに記載のようにして計算されます。
Policy Refresh TIME_VALUES (PRT)
ポリシーの更新TIME_VALUES（PRT）
The Policy Refresh TIME_VALUES (PRT) option is used to slow policy refresh frequency for policies that have looser timing constraints relative to RSVP. If the PRT option is present, policy refreshes can be withheld as long as at least one refresh is sent before the policy refresh timer expires. A minimal value for PRT is R; lower values are assumed to be R (neither error nor warning should be triggered).
ポリシーの更新TIME_VALUES（PRT）オプションは、RSVPに対する緩いタイミング制約を持っているポリシーのポリシーの更新頻度を遅くするために使用されます。 PRTオプションを指定すると、ポリシーの更新は、ポリシーの更新タイマーが切れる前に限り、少なくとも一つのリフレッシュが送信される源泉徴収することができます。 PRTのための最小値はRです。低い値は、R（いずれもエラー警告がトリガされなければならない）であると仮定されます。
To simplify RSVP processing, time values are not based directly on the PRT value, but on a Policy Refresh Multiplier N computed as N=Floor(PRT/R). Refresh and cleanup rules are derived from [RSVP] Section 3.7 assuming the refresh period for PRT POLICY DATA is R' computed as R'=N*R. In effect, both the refresh and the state cleanup are slowed by a factor of N).
RSVP処理を簡略化するために、時間値は、PRTの値に直接基づいているが、ポリシーの更新乗数NにN =フロア（PRT / R）として計算されていません。リフレッシュおよびクリーンアップルールがPRTポリシー・データのリフレッシュ周期を仮定[RSVP]セクション3.7に由来することは= N * R「Rとして計算」Rです。実際には、リフレッシュ状態のクリーンアップの両方）がN倍に減速されます。
The refresh multiplier applies to no-change periodic refreshes only (rather than updates). For example, a policy being refreshed at time T, T+N, T+2N,... may encounter a route change detected at T+X. In this case, the event would force an immediate policy update and would reset srfresh times to T+X+N, T+X+2N,...
リフレッシュ乗数は（というよりも、更新）定期的なリフレッシュのみなし変更に適用されます。例えば、ポリシーは時刻T、T + N、T + 2Nでリフレッシュされ、... T + Xにおいて検出経路変更が発生する場合があります。 、この場合、イベントは即時ポリシー更新を強制すると、T + X + N、T + X + 2Nにsrfresh回リセットします...
When network nodes restart, RSVP messages between PRT policy refreshes may be rejected since they arrive without necessary POLICY_DATA objects. This error situation would clear with the next periodic policy refresh or with a policy update triggered by ResvErr or PathErr messages.
ネットワークノードが再起動したときに、彼らが必要POLICY_DATAオブジェクトなしで到着するので、PRTポリシーの更新の間のRSVPメッセージは拒否されてもよいです。このエラー状況は、次の定期的なポリシーの更新またはResvErrかのPathErrメッセージによってトリガポリシーの更新をオフにします。
This option is especially useful to combine strong (high overhead) and weak (low overhead) authentication certificates as policy data. In such schemes the weak certificate can support admitting a reservation only for a limited time, after which the strong certificate is required.
このオプションでは、ポリシーデータとして強い（高いオーバーヘッド）と弱い（低オーバーヘッド）認証証明書を組み合わせることが特に便利です。そのようなスキームに弱い証明書は、強い証明書が必要とされた後に、限られた時間の予約を入れるサポートすることができます。
This approach may reduce the overhead of POLICY_DATA processing. Strong certificates could be transmitted less frequently, while weak certificates are included in every RSVP refresh.
このアプローチは、POLICY_DATA処理のオーバーヘッドを低減することができます。弱い証明書がすべてのRSVPリフレッシュに含まれていながら、強力な証明書は、それほど頻繁に送信することができます。
The content of policy elements is opaque to RSVP; their internal format is understood by policy peers e.g. an RSVP Local Decision Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of policy element codepoints and their meaning is maintained by [IANA-CONSIDERATIONS] (also see Section 5).
ポリシー元素の含有量は、RSVPに対して不透明です。その内部形式は、ポリシーピアによって理解され、例えばRSVPローカル決定点（LDP）またはポリシー決定ポイント（PDP）[RAP]。ポリシー要素コードポイントとその意味のレジストリが[IANA-考察]によって維持されている（また、セクション5を参照）。
Policy Elements have the following format:
ポリシー要素の形式は次のとおりです。
+-------------+-------------+-------------+-------------+
| Length | P-Type |
+---------------------------+---------------------------+
| |
// Policy information (Opaque to RSVP) //
| |
+-------------------------------------------------------+
Policy state expires in the granularity of Policy Elements (POLICY_DATA objects are mere containers and do not expire as such).
ポリシーの状態がポリシーの要素（POLICY_DATAオブジェクトは単なるコンテナであり、そのように有効期限はありません）の細かさに失効します。
Policy elements expire in the exact manner and time as the RSVP state received in the same message (see [RSVP] Section 3.7). PRT controlled state expires N times slower (see Section 3.2).
ポリシーエレメントは、（[RSVP]セクション3.7を参照）は、同じメッセージで受信したRSVP状態として正確な方法と時間で期限切れ。 PRT制御状態がN倍遅く満了する（3.2節を参照してください）。
Only one policy element of a certain P-Type can be active at any given time. Therefore, policy elements are instantaneously replaced when another policy element of the same P-Type is received from the same PDP (previous or next policy RSVP_HOP). An empty policy element of a certain P-Type is used to delete (rather than a replace) all policy state of the same P-Type.
のみ特定のP型の1つのポリシー要素は、任意の時点でアクティブにできます。同一のP型の別のポリシー要素が同じPDP（前または次のポリシーRSVP_HOP）から受信したときしたがって、ポリシー要素が瞬時に置換されています。特定のP型の空のポリシー要素（置き換えるのではなく）同一のP型のすべてのポリシー状態を削除するために使用されます。
4 Processing Rules
4つの処理ルール
These sections describe the minimal required policy processing rules for RSVP.
ここでは、RSVPのための必要最小限のポリシー処理ルールを記述します。
This memo mandates enforcing policy control for Path, Resv, PathErr, and ResvErr messages only. PathTear and ResvTear are assumed not to require policy control based on two main presumptions. First, that Integrity verification [MD5] guarantee that the Tear is received from the same node that sent the installed reservation, and second, that it is functionally equivalent to that node holding-off refreshes for this reservation.
パス、のResv、のPathErrとResvErrメッセージのみのポリシー制御を実施するこのメモの義務。 PathTearとたResvTearは、主に2つの仮定に基づいてポリシー制御を必要としないと想定されています。まず、整合性検証は、[MD5]涙が、この予約のためにそのノード保持オフリフレッシュと機能的に同等であること、第二に設置予約を送信し、同じノードから受信されることを保証すること。
Figure 1 illustrates an example of where policy data objects traverse PIN nodes in transit from one PEP to another.
図1は、ポリシー・データが別のPEPから輸送中トラバースPINノードオブジェクト場合の一例を示す図です。
A PIN node is required at a minimum to forward the received POLICY_DATA objects in the appropriate outgoing messages according to the following rules:
PINノードは、次の規則に従って適切な送信メッセージで受信POLICY_DATAオブジェクトを転送するために最低限必要とされます。
o POLICY_DATA objects are to be forwarded as is, without any modifications.
O POLICY_DATAオブジェクトは変更せず、そのまま転送されます。
o Multicast merging (splitting) nodes:
Oマルチキャスト（分割）ノードをマージします。
In the upstream direction:
アップストリーム方向では：
When multiple POLICY_DATA objects arrive from downstream, the RSVP node should concatenate all of them (as a list of the original POLICY_DATA objects) and forward them with the outgoing (upstream) message.
複数POLICY_DATAオブジェクトが下流から到着すると、RSVPノードは、（元のPOLICY_DATAオブジェクトのリストとして）、それらのすべてを連結し、送信（アップストリーム）メッセージで転送しなければなりません。
On the downstream direction:
下流方向の場合：
When a single incoming POLICY_DATA object arrives from upstream, it should be forwarded (copied) to all downstream branches of the multicast tree.
単一着信POLICY_DATAオブジェクトが上流側から到着すると、それはマルチキャストツリーの全ての下流のブランチに（コピー）に転送されるべきです。
The same rules apply to unrecognized policies (sub-objects) within the POLICY_DATA object. However, since this can only occur in a policy-capable node, it is the responsibility of the PDP and not RSVP.
同じルールがPOLICY_DATAオブジェクト内の認識されていないポリシー（サブオブジェクト）に適用されます。これが唯一のポリシー対応ノードで起こり得るので、それは、PDPの責任であるとRSVPありません。
Policy errors are reported by either ResvErr or PathErr messages with a policy failure error code in the ERROR_SPEC object. Policy error message must include a POLICY_DATA object; the object contains details of the error type and reason in a P-Type specific format (See Section 3.3).
ポリシーエラーがERROR_SPECオブジェクト内の政策の失敗エラーコードのいずれかResvErrかのPathErrメッセージによって報告されています。ポリシーのエラーメッセージがPOLICY_DATAオブジェクトを含める必要があります。オブジェクトは、P型特異的フォーマットのエラータイプ及び理由の詳細を含む（セクション3.3を参照）。
If a multicast reservation fails due to policy reasons, RSVP should not attempt to discover which reservation caused the failure (as it would do for Blockade State). Instead, it should attempt to deliver the policy ResvErr to ALL downstream hops, and have the PDP (or LDP) decide where messages should be sent. This mechanism allows the PDP to limit the error distribution by deciding which "culprit" next-hops should be informed. It also allows the PDP to prevent further distribution of ResvErr or PathErr messages by performing local repair (e.g. substituting the failed POLICY_DATA object with a different one).
マルチキャスト予約が政策上の理由のために失敗した場合、RSVPは、（それが封鎖状態のために行うように）失敗の原因となった予約を発見するために試みるべきではありません。代わりに、それはすべての下流ホップにポリシーResvErrを配信しようと、メッセージが送られるべきであるPDP（またはLDP）を決めている必要があります。このメカニズムは、PDPに通知すべき「犯人」の次のホップを決定することにより、誤差分布を制限することができます。また、PDPは、（例えば、異なる一方に障害が発生したPOLICY_DATAオブジェクトを置換）ローカル修復を行うことにより、ResvErr又はのPathErrメッセージの更なる配布を防止することを可能にします。
Error codes are described in Appendix Appendix A.
エラーコードは、付録Aに記載されています
5 IANA Considerations
5つのIANAの考慮事項
RSVP Policy Elements (P-Types)
RSVPポリシーの要素（P-タイプ）
Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0-49151 are allocated as standard policy elements by IETF Consensus action, numbers in the range 49152-53247 are allocated as vendor specific (one per vendor) by First Come First Serve, and numbers 53248-65535 are reserved for private use and are not assigned by IANA.
[IANA-考察]に概説された方針以下、数字0から49151はIETF Consensus動作により、標準的なポリシー要素として割り当てられ、範囲49152から53247の数字が最初によってベンダー固有の（ベンダーごとに）として割り当てられているサーブ最初に来て、番号53248から65535は、私的使用のために予約されており、IANAによって割り当てられていません。
6 Security Considerations
6セキュリティについての考慮事項
This memo describes the use of POLICY_DATA objects to carry policy-related information between RSVP nodes. Two security mechanisms can be optionally used to ensure the integrity of the carried information. The first mechanism relies on RSVP integrity [MD5] to provide a chain of trust when all RSVP nodes are policy capable. The second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between non-neighboring RSVP PEPs (see Sections 2 and 3.2).
このメモはRSVPノード間のポリシー関連情報を搬送するPOLICY_DATAオブジェクトの使用を記載しています。 2つのセキュリティメカニズムは、必要に応じて実施し、情報の整合性を確保するために使用することができます。第1の機構は、すべてのRSVPノードがポリシーが可能である場合に、信頼の連鎖を提供するために、RSVPの整合[MD5]に依存しています。第2のメカニズムは、非隣接のRSVPのPEP（セクション2および3.2を参照）との間の整合性を保証するためにPOLICY_DATAオブジェクト内INTEGRITYオブジェクトに依存しています。
7 References
7つの参考文献
[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月。
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. Sastry, "COPS Usage for RSVP", RFC 2749, January 2000.
[COPS-RSVP]ボイル、J.、コーエン、R.、ダラム、D.、ヘルツォーク、S.、ラージャ、R.およびA. Sastry、 "RSVPの使用上のCOPS"、RFC 2749、2000年1月。
[RSVP] Braden, R., Ed., 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月。
[MD5] Baker, F., Lindell B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[MD5]ベーカー、F.、リンデルB.及びM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-考察] Alvestrand、H.、およびT. Narten氏、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
8 Acknowledgments
8つの謝辞
This document incorporates inputs from Lou Berger, Bob Braden, Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Raju Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many others.
このドキュメントは、ルー・バーガー、ボブブレーデン、デボラ・エストリン、ロッホゲラン、ティモシーオマリー、ディミトリオスPendarakis、ラジュ・ラジャン、スコット・シェンカー、アンドリュー・スミス、ラジYavatkar、および多くの他からの入力を搭載しています。
9 Author Information
9著者の情報
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
Appendix A: Policy Error Codes
付録A：ポリシーエラーコード
This Appendix extends the list of error codes described in Appendix B of [RSVP].
この付録では、[RSVP]の付録Bに記載されているエラーコードの一覧を拡張します。
Note that Policy Element specific errors are reported as described in Section 4.3 and cannot be reported through RSVP (using this mechanism). However, this mechanism provides a simple, less secure mechanism for reporting generic policy errors. Most likely the two would be used in concert such that a generic error code is provided by RSVP, while Policy Element specific errors are encapsulated in a return POLICY_DATA object (as in Section 4.3).
4.3節で説明した（このメカニズムを使用して）RSVPで報告することができないようポリシー要素の特定のエラーが報告されていることに注意してください。しかし、このメカニズムは、一般的な政策の誤りを報告するための簡単な、安全性の低いメカニズムを提供します。最も可能性の高い2は、ポリシー要素、特定のエラーが（4.3節のように）戻りPOLICY_DATAオブジェクトにカプセル化されている一方で、一般的なエラーコードは、RSVPによって提供されるようなコンサートに使用されます。
ERROR_SPEC class = 6
ERROR_SPECクラス= 6
Error Code = 02: Policy Control failure
エラーコード= 02：ポリシー制御の失敗
Error Value: 16 bit
エラー値：16ビット
0 = ERR_INFO : Information reporting 1 = ERR_WARN : Warning 2 = ERR_UNKNOWN : Reason unknown 3 = ERR_REJECT : Generic Policy Rejection 4 = ERR_EXCEED : Quota or Accounting violation 5 = ERR_PREEMPT : Flow was preempted 6 = ERR_EXPIRED : Previously installed policy expired (not refreshed) 7 = ERR_REPLACED: Previous policy data was replaced & caused rejection 8 = ERR_MERGE : Policies could not be merged (multicast) 9 = ERR_PDP : PDP down or non functioning 10= ERR_SERVER : Third Party Server (e.g., Kerberos) unavailable 11= ERR_PD_SYNTX: POLICY_DATA object has bad syntax 12= ERR_PD_INTGR: POLICY_DATA object failed Integrity Check 13= ERR_PE_BAD : POLICY_ELEMENT object has bad syntax 14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the PD object) 15= ERR_NO_RSC : PEP Out of resources to handle policies. 16= ERR_RSVP : PDP encountered bad RSVP objects or syntax 17= ERR_SERVICE : Service type was rejected 18= ERR_STYLE : Reservation Style was rejected 19= ERR_FL_SPEC : FlowSpec was rejected (too large)
0 = ERR_INFO：レポート情報1 = ERR_WARN：警告2 = ERR_UNKNOWN：理由不明3 = ERR_REJECT：一般的なポリシー拒絶4 = ERR_EXCEED：クォータや会計違反ERR_PREEMPT = 5：以前にインストールしたポリシーが（リフレッシュされない期限切れ：フローは6 = ERR_EXPIRED横取りされました）7 = ERR_REPLACED：前のポリシーデータを交換＆引き起こされた拒絶8 = ERR_MERGE：ポリシーをマージすることができませんでした（マルチキャスト）9 = ERR_PDP：PDPダウンまたは非機能10 = ERR_SERVER：使用できないサードパーティ製のサーバ（例えば、ケルベロス）11 = ERR_PD_SYNTX ：POLICY_DATAオブジェクトは悪い構文12 = ERR_PD_INTGR有する：整合性チェック失敗POLICY_DATA物を13 = ERR_PE_BAD：必須PE欠落（空のPEは、PD対象である）15 = ERR_NO_RSC：処理するためのリソースのうちPEP POLICY_ELEMENTオブジェクトが悪い構文14 = ERR_PD_MISSを有しますポリシー。 16 = ERR_RSVP：サービスタイプが18 = ERR_STYLE拒否されました：予約スタイルが拒否された19 = ERR_FL_SPEC：たFlowSpecが拒否された（大きすぎる）PDPは、17 = ERR_SERVICE悪いRSVPオブジェクトまたは構文に遭遇しました
Values between 2^15 and 2^16-1 can be used for site and/or vendor error values.
2 ^ 15と2 ^ 16-1までの値は、サイトおよび/またはベンダのエラー値のために使用することができます。
Appendix B: INTEGRITY computation for POLICY_DATA objects
付録B：POLICY_DATAオブジェクト用INTEGRITY計算
Computation of the INTEGRITY option is based on the rules set forth in [MD5], with the following modifications:
INTEGRITYオプションの計算は以下のように変更して、[MD5]に記載されたルールに基づいています。
Section 4.1:
セクション4.1：
Rather than computing digest for an RSVP message, a digest is computed for a POLICY_DATA object in the following manner:
むしろRSVPメッセージのダイジェストを計算するよりも、ダイジェストは、次のようにPOLICY_DATAオブジェクトに対して計算されます。
(1) The INTEGRITY object is inserted in the appropriate place in the POLICY_DATA object, and its location in the message is remembered for later use.
（1）INTEGRITYオブジェクトがPOLICY_DATAオブジェクト内の適切な場所に挿入され、メッセージ中のその位置は、後の使用のために記憶されています。
(2) The PDP, at its discretion, and based on destination PEP/PDP or other criteria, selects an Authentication Key and the hash algorithm to be used.
（2）PDPは、その裁量で、宛先PEP / PDP又は他の基準に基づいて、認証キーとハッシュアルゴリズムを使用することを選択します。
(3) A copy of RSVP SESSION object is temporarily appended to the end of the PD object (for the computation purposes only, without changing the length of the POLICY_DATA object). The flags field of the SESSION object is set to 0. This concatenation is considered as the message for which a digest is to be computed.
（3）RSVPセッションオブジェクトのコピーが一時的にPDオブジェクト（計算目的のためにのみ、POLICY_DATAオブジェクトの長さを変えず）の末尾に追加されます。 SESSIONオブジェクトのフラグフィールドは、この連結は、ダイジェストが計算されるべきメッセージと考えられる0に設定されます。
(4) The rest of the steps in Section 4.1 ((4)..(9)) remain unchanged when computed over the concatenated message.
連結メッセージに対して計算された場合（4）セクション4.1の手順の残りの（（4）..（9））は変わりません。
Note: When the computation is complete, the SESSION object is ignored and is not part of the POLICY_DATA object.
注意：計算が完了すると、Sessionオブジェクトは無視され、POLICY_DATAオブジェクトの一部ではありません。
Other Provisions:
その他の引当金：
The processing of a received POLICY_DATA object as well as a challenge-response INTEGRITY object inside a POLICY_DATA object is performed in the manner described in [MD5]. This processing is subject to the modified computation algorithm as described in the beginning of this appendix (for Section 4.1 of [MD5]).
受信POLICY_DATAオブジェクトの処理と同様POLICY_DATAオブジェクト内部のチャレンジ - 応答INTEGRITYオブジェクトは、[MD5]に記載のようにして行われます。 （[MD5]のセクション4.1）この付録の冒頭で説明したように、この処理は、修正計算アルゴリズムの対象です。
Full Copyright Statement
完全な著作権声明
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機能のための基金は現在、インターネット協会によって提供されます。