Network Working Group S. Herzog
Request for Comments: 2750 IPHighway
Updates: 2205 January 2000
Category: Standards Track
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.
版权所有（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_数据对象的标准格式，以及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.......................................................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_数据对象的形式为策略支持留下了一个占位符。
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展示了一个具有两个边界节点（a，C）的简单自治域，它们表示由PDP控制的PEP。核心节点（B）表示支持RSVP的策略节点（PIN），其功能仅限于默认策略处理（第4.2节）。
PDP1 PDP2
| |
| |
+---+ +---+ +---+
| A +---------+ B +---------+ C |
+---+ +---+ +---+
PEP2 PIN PEP2
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.
在这里，跨域传输的策略对象遍历一个中间PIN节点（B），该节点被允许处理RSVP消息，但在处理策略信息时被认为是不可信的。
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.
策略_数据对象由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.
在支持策略的节点之间沿数据路径交换策略数据对象，支持生成一致的端到端策略。此外，当边界节点根据已建立的双边协议集操作和转换策略数据对象时，可以跨多个管理域成功部署此类策略。
The following extends section A.13 in [RSVP].
以下扩展了[RSVP]中的A.13节。
POLICY_DATA class=14
策略_数据类=14
o Type 1 POLICY_DATA object: Class=14, C-Type=1
o 类型1策略_数据对象：类=14，C类型=1
+-------------+-------------+-------------+-------------+
| Length | POLICY_DATA | 1 |
+---------------------------+-------------+-------------+
| Data Offset | 0 (reserved) |
+---------------------------+-------------+-------------+
| |
// Option List //
| |
+-------------------------------------------------------+
| |
// Policy Element List //
| |
+-------------------------------------------------------+
+-------------+-------------+-------------+-------------+
| 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_数据对象中的一组选项。所有策略选项都显示为RSVP对象，但当用作策略数据选项时，其语义会被修改。
FILTER_SPEC object (list) or SCOPE object
过滤器规格对象（列表）或范围对象
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.
这些对象描述与策略数据对象关联的发送者集。如果没有提供，则假定策略信息与会话的所有流相关联。这两种类型的对象是互斥的，不能混合使用。
In Packed FF Resv messages, this FILTER_SPEC option provides association between a reserved flow and its POLICY_DATA objects.
在打包的FF Resv消息中，此过滤器规格选项提供保留流与其策略数据对象之间的关联。
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样式中，此选项保留PDP形成的原始流/策略_数据关联，即使跨支持RSVP的管脚。这种保留是必需的，因为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_数据对象的缩放和大小产生重大影响。
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_跳是允许它们相互识别并安全直接通信的机制的基础。
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).
第二个RSVP_-HOP对象可以跟随原始RSVP_-HOP对象。第二个RSVP_跃点标识目标策略节点。这用于确保策略_数据对象被传递到目标策略节点。它可用于模拟多播路径消息中的单播传递。它还可以帮助防止在网络的其他部分使用策略对象（重播攻击）。
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跃点的任何策略数据。
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_数据对象，同时遍历非安全PIN节点。在这种情况下，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 object中的INTEGRITY object选项在不涉及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)
策略刷新时间\u值（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).
策略刷新时间_值（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）。刷新和清理规则源自[RSVP]第3.7节，假设PRT策略数据的刷新周期R'计算为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,...
刷新乘数仅适用于无更改定期刷新（而不是更新）。例如，在时间T、T+N、T+2N、，。。。可能会遇到在T+X检测到的路由更改。在这种情况下，事件将强制立即更新策略，并将srfresh时间重置为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消息可能会被拒绝，因为它们到达时没有必要的策略数据对象。此错误情况将在下一次定期策略刷新或由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.
这种方法可以减少策略数据处理的开销。强证书的传输频率可能会降低，而弱证书则包含在每次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) //
| |
+-------------------------------------------------------+
+-------------+-------------+-------------+-------------+
| 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 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类型的策略元素只能处于活动状态。因此，当从同一PDP（上一个或下一个策略RSVP_跃点）接收到相同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不需要策略控制。首先，完整性验证[MD5]保证从发送已安装保留的同一节点接收到撕裂，其次，它在功能上等同于该节点延迟此保留的刷新。
Figure 1 illustrates an example of where policy data objects traverse PIN nodes in transit from one PEP to another.
图1展示了一个示例，其中策略数据对象在从一个PEP到另一个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节点来转发相应传出消息中接收到的策略_数据对象：
o POLICY_DATA objects are to be forwarded as is, without any modifications.
o 策略_数据对象将按原样转发，无需任何修改。
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.
当多个策略_数据对象从下游到达时，RSVP节点应连接所有这些对象（作为原始策略_数据对象的列表），并将它们与传出（上游）消息一起转发。
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.
当单个传入策略_数据对象从上游到达时，应将其转发（复制）到多播树的所有下游分支。
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_数据对象中无法识别的策略（子对象）。但是，由于这只能发生在具有策略能力的节点中，因此这是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).
策略错误由ResvErr或PathErr消息报告，错误规范对象中包含策略失败错误代码。策略错误消息必须包含策略\u数据对象；该对象以P-type特定格式包含错误类型和原因的详细信息（见第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或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共识行动分配为标准政策要素，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节点之间传输策略相关信息。可以选择使用两种安全机制来确保所携带信息的完整性。第一种机制依赖于RSVP完整性[MD5]，在所有RSVP节点都支持策略时提供信任链。第二种机制依赖于POLICY_数据对象中的INTEGRITY对象来保证非相邻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.和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.
[COPS]Boyle，J.，Cohen，R.，Durham，D.，Herzog，S.，Raja，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]Boyle，J.，Cohen，R.，Durham，D.，Herzog，S.，Raja，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]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）-功能规范”，RFC 22052997年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注意事项]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.
本文件包含了Lou Berger、Bob Braden、Deborah Estrin、Roch Guerin、Timothy O'Malley、Dimitrios Pendarakis、Raju Rajan、Scott Shenker、Andrew Smith、Raj Yavatkar和许多其他人的输入。
9 Author Information
9作者信息
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
Shai Herzog IPHighway，Inc.马萨诸塞州弗雷明翰纽约大道55号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（使用此机制）进行报告。但是，此机制为报告通用策略错误提供了一种简单、不太安全的机制。最有可能的情况是，这两种错误会同时使用，因此RSVP会提供一个通用错误代码，而特定于策略元素的错误则封装在返回策略_数据对象中（如第4.3节所示）。
ERROR_SPEC class = 6
错误\规格等级=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 : 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：策略数据对象的完整性计算
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消息的摘要，而是按以下方式计算策略_数据对象的摘要：
(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_数据对象中的适当位置，并记住其在消息中的位置以供以后使用。
(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对象的末尾（仅用于计算目的，不更改策略_数据对象的长度）。会话对象的标志字段设置为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.
注意：计算完成后，会话对象将被忽略，并且不是策略_数据对象的一部分。
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]).
以[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编辑功能的资金目前由互联网协会提供。