[要約] RFC 2750は、RSVP（Resource Reservation Protocol）の拡張機能であり、ポリシーコントロールを実現するためのものです。このRFCの目的は、ネットワークリソースの予約と制御を効果的に行うための仕組みを提供することです。
Network Working Group S. Herzog
Request for Comments: 2750 IPHighway
Updates: 2205 January 2000
Category: Standards Track
RSVP Extensions for Policy Control
ポリシー管理用の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.
Copyright（c）The Internet Society（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].
このドキュメントは、特定の政策制御メカニズムを提唱していません。ただし、これらの拡張機能のルーター/サーバーポリシープロトコルの説明は、[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機能仕様[RSVP]のバージョン1は、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）とローカル決定ポイント（LDP）を区別しません。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は、PDPによって制御されるPEPを表す2つの境界ノード（a、c）を持つ単純な自律ドメインを示しています。コアノード（b）は、デフォルトのポリシー処理に限定された機能を備えたRSVP対応ポリシー無知ノード（PIN）を表します（セクション4.2）。
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メッセージを処理することが許可されているが、ポリシー情報を処理するために不信感と見なされる中間ピンノード（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.
データパスに沿ったポリシー利用可能なノード間のポリシー_DATAオブジェクトの交換は、一貫したエンドツーエンドポリシーの生成をサポートします。さらに、このようなポリシーは、境界線ノードが、確立された二国間契約のセットに従ってpolicy_Dataオブジェクトを操作および翻訳する場合、複数の管理ドメインに正常に展開することができます。
The following extends section A.13 in [RSVP].
以下は、[RSVP]のセクションA.13を拡張します。
POLICY_DATA class=14
policy_data class = 14
o Type 1 POLICY_DATA object: Class=14, C-Type=1
o タイプ1 policy_dataオブジェクト：class = 14、c-type = 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.
オプションのリストとそれらの使用法は、セクション3.2で定義されています。
Policy Element List: Variable length
ポリシー要素リスト：可変長
The contents of policy elements is opaque to RSVP. See more details in Section 3.3.
ポリシー要素の内容は、RSVPに対して不透明です。セクション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オブジェクト（リスト）またはスコープオブジェクト
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有能なピン全体で、PDPによって形成された元のFlow/Policy_Data Associationを保持します。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.
最後に、[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オブジェクトは、ポリシーオブジェクトを構築したNeighbor/Peerポリシー対応ノードを識別します。ポリシーが境界ノードで施行される場合、ピアポリシーノードは互いにいくつかの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メッセージ自体に示されているRSVP_HOPによって構築されたと暗黙的に想定されます（つまり、隣接する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).
2番目のRSVP_HOPオブジェクトは、発信元のRSVP_HOPオブジェクトに従うことができます。この2番目のRSVP_HOPは、宛先ポリシーノードを識別します。これは、policy_Dataオブジェクトがターゲットを絞ったポリシーノードに配信されるようにするために使用されます。マルチキャストパスメッセージのユニキャスト配信をエミュレートするために使用できます。また、ネットワークの他の部分でポリシーオブジェクトの使用を防ぐのにも役立ちます（リプレイ攻撃）。
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
整合性オブジェクト
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）は、非セキュアピンノードを通過しながら境界ノード間にpolicy_Dataオブジェクトが送信される例を示しています。このシナリオでは、RSVPの整合性メカニズムは、中間ピンノード（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.
このオプションは、PDPの裁量で使用でき、付録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オプションが存在する場合、ポリシーリフレッシュタイマーが期限切れになる前に少なくとも1つの更新が送信される限り、ポリシーリフレッシュを差し控えることができます。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 = floor（PRT/R）として計算されたポリシーリフレッシュ乗数nに基づいています。更新およびクリーンアップルールは、[RSVP]セクション3.7から派生しています。PRTポリシーデータの更新期間がR '= n*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,...
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.
ネットワークノードが再起動すると、PRTポリシーリフレッシュ間のRSVPメッセージは、必要なpolicy_Dataオブジェクトなしで到着するため拒否される場合があります。このエラーの状況は、次の定期的なポリシーの更新または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状態が正確に期限切れになります（[RSVP]セクション3.7を参照）。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つのポリシー要素のみが、いつでもアクティブになります。したがって、同じPDP（以前または次のポリシーRSVP_HOP）から同じPタイプの別のポリシー要素が受信されると、ポリシー要素が即座に置き換えられます。特定の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.
このメモは、PATH、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から別のPEPへの輸送中にピンノードを通過する場所の例を示しています。
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.
単一の受信ポリシー_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オブジェクト内の認識されていないポリシー（サブオブジェクト）に適用されます。ただし、これはポリシー対応ノードでのみ発生する可能性があるため、RSVPではなくPDPの責任です。
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は、ローカル修理を実行することにより、ResverrまたはPatherメッセージのさらなる分布を防ぐことができます（たとえば、失敗したpolicy_dataオブジェクトを別のものに置き換える）。
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-Consididerations]で概説されているポリシーに続いて、数字0-49151はIETFコンセンサスアクションによって標準ポリシー要素として割り当てられ、範囲49152-53247の数字は、最初のサーブによってベンダー固有（1つのベンダーごと）として割り当てられます。番号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).
このメモでは、policy_Dataオブジェクトの使用がRSVPノード間でポリシー関連の情報を伝達することを説明しています。2つのセキュリティメカニズムをオプションで使用して、運ばれた情報の完全性を確保することができます。最初のメカニズムは、RSVPの完全性[MD5]に依存して、すべてのRSVPノードがポリシーが可能な場合に信頼の連鎖を提供します。2番目のメカニズムは、Policy_Dataオブジェクト内の整合性オブジェクトに依存して、非希少性RSVP PEP間の完全性を保証します（セクション2および3.2を参照）。
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。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。
[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。
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - 機能仕様」、RFC 2205、1997年9月。
[MD5] Baker, F., Lindell B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[MD5] Baker、F.、Lindell 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-Considerations] 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.
この文書には、ルーバーガー、ボブ・ブレイデン、デボラ・エストリン、ロック・ゲリン、ティモシー・オマリー、ディミトリオス・ペンダラキス、ラジュ・ラジャン、スコット・シェンカー、アンドリュー・スミス、ラジ・ヤバトカルなどからの入力が組み込まれています。
9 Author Information
9著者情報
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
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
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つはRSVPによって一般的なエラーコードが提供されるようにコンサートで使用されますが、ポリシー要素固有のエラーは返されるpolicy_dataオブジェクトにカプセル化されます（セクション4.3のように）。
ERROR_SPEC class = 6
error_spec class = 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)
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オブジェクトの整合性計算
Computation of the INTEGRITY option is based on the rules set forth in [MD5], with the following modifications:
整合性オプションの計算は、[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) 整合性オブジェクトは、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オブジェクトの長さを変更せずに、計算目的のみ）。セッションオブジェクトのフラグフィールドは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.
注：計算が完了した場合、セッションオブジェクトは無視され、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オブジェクトの処理と、[MD5]で説明されている方法でPolicy_Dataオブジェクト内のチャレンジ応答整合性オブジェクトが実行されます。この処理は、この付録の冒頭（[MD5]のセクション4.1の場合）で説明されているように、変更された計算アルゴリズムの対象となります。
Full Copyright Statement
完全な著作権声明
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エディター機能の資金は現在、インターネット協会によって提供されています。