Network Working Group S . Herzog, Ed.
Request for Comments: 2749 IPHighway
Category: Standards Track J. Boyle
Level3
R. Cohen
Cisco
D. Durham
Intel
R. Rajan
AT&T
A. Sastry
Cisco
January 2000
Network Working Group S . Herzog, Ed.
Request for Comments: 2749 IPHighway
Category: Standards Track J. Boyle
Level3
R. Cohen
Cisco
D. Durham
Intel
R. Rajan
AT&T
A. Sastry
Cisco
January 2000
COPS usage for RSVP
警察对RSVP的使用
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes usage directives for supporting COPS policy services in RSVP environments.
本文档描述了在RSVP环境中支持COPS策略服务的使用指令。
Table of Contents
目录
1 Introduction....................................................2
2 RSVP values for COPS objects....................................2
2.1 Common Header, client-type...................................2
2.2 Context Object (Context).....................................3
2.3 Client Specific Information (ClientSI).......................4
2.4 Decision Object (Decision)...................................4
3 Operation of COPS for RSVP PEPs.................................6
3.1 RSVP flows...................................................6
3.2 Expected Associations for RSVP Requests......................6
3.3 RSVP's Capacity Admission Control: Commit and Delete.........7
3.4 Policy Control Over PathTear and ResvTear....................7
1 Introduction....................................................2
2 RSVP values for COPS objects....................................2
2.1 Common Header, client-type...................................2
2.2 Context Object (Context).....................................3
2.3 Client Specific Information (ClientSI).......................4
2.4 Decision Object (Decision)...................................4
3 Operation of COPS for RSVP PEPs.................................6
3.1 RSVP flows...................................................6
3.2 Expected Associations for RSVP Requests......................6
3.3 RSVP's Capacity Admission Control: Commit and Delete.........7
3.4 Policy Control Over PathTear and ResvTear....................7
3.5 PEP Caching COPS Decisions...................................7
3.6 Using Multiple Context Flags in a single query...............8
3.7 RSVP Error Reporting.........................................9
4 Security Considerations.........................................9
5 Illustrative Examples, Using COPS for RSVP......................9
5.1 Unicast Flow Example.........................................9
5.2 Shared Multicast Flows......................................11
6 References.....................................................14
7 Author Information and Acknowledgments.........................15
8 Full Copyright Statement.......................................17
3.5 PEP Caching COPS Decisions...................................7
3.6 Using Multiple Context Flags in a single query...............8
3.7 RSVP Error Reporting.........................................9
4 Security Considerations.........................................9
5 Illustrative Examples, Using COPS for RSVP......................9
5.1 Unicast Flow Example.........................................9
5.2 Shared Multicast Flows......................................11
6 References.....................................................14
7 Author Information and Acknowledgments.........................15
8 Full Copyright Statement.......................................17
1 Introduction
1导言
The Common Open Policy Service (COPS) protocol is a query response protocol used to exchange policy information between a network policy server and a set of clients [COPS]. COPS is being developed within the RSVP Admission Policy Working Group (RAP WG) of the IETF, primarily for use as a mechanism for providing policy-based admission control over requests for network resources [RAP].
公共开放策略服务（COPS）协议是一种查询响应协议，用于在网络策略服务器和一组客户端[COPS]之间交换策略信息。COPS正在IETF的RSVP准入政策工作组（RAP WG）内开发，主要用作对网络资源请求[RAP]提供基于策略的准入控制的机制。
This document is based on and assumes prior knowledge of the RAP framework [RAP] and the basic COPS [COPS] protocol. It provides specific usage directives for using COPS in outsourcing policy control decisions by RSVP clients (PEPs) to policy servers (PDPs).
本文件以RAP框架[RAP]和基本COPS[COPS]协议为基础，并假定对其有先验知识。它为RSVP客户端（PEP）将策略控制决策外包给策略服务器（PDP）时使用COP提供了具体的使用指令。
Given the COPS protocol design, RSVP directives are mainly limited to RSVP applicability, interoperability and usage guidelines, as well as client specific examples.
鉴于COPS协议设计，RSVP指令主要限于RSVP适用性、互操作性和使用指南，以及特定于客户端的示例。
2 RSVP values for COPS objects
COPS对象的2个RSVP值
The usage of several COPS objects is affected when used with the RSVP client type. This section describes these objects and their usage.
与RSVP客户端类型一起使用时，多个COPS对象的使用会受到影响。本节介绍这些对象及其用法。
RSVP is COPS client-type 1
RSVP是COPS客户端类型1
The semantics of the Context object for RSVP is as follows:
RSVP的上下文对象的语义如下所示：
R-Type (Request Type Flag)
R-Type（请求类型标志）
Incoming-Message request
传入消息请求
This context is used when the PEP receives an incoming RSVP message. The PDP may decide to accept or reject the incoming message and may also apply other decision objects to it. If the incoming message is rejected, RSVP should treat it as if it never arrived.
PEP接收到传入RSVP消息时使用此上下文。PDP可以决定接受或拒绝传入消息，也可以对其应用其他决策对象。如果传入消息被拒绝，RSVP应将其视为从未到达。
Resource-Allocation request
资源分配请求
This context is used when the PEP is about to commit local resources to an RSVP flow (admission control). This context applies to Resv messages only. The decision whether to commit local resources is made for the merge of all reservations associated with an RSVP flow (which have arrived on a particular interface, potentially from several RSVP Next-Hops).
当PEP将要将本地资源提交到RSVP流（许可控制）时，使用此上下文。此上下文仅适用于Resv消息。决定是否提交本地资源是为了合并与RSVP流（已到达特定接口，可能来自几个RSVP下一跳）关联的所有保留。
Outgoing-Message request (forwarding an outgoing RSVP message)
传出消息请求（转发传出RSVP消息）
This context is used when the PEP is about to forward an outgoing RSVP message. The PDP may decide to allow or deny the outgoing message, as well as provide an outgoing policy data object.
当PEP即将转发传出RSVP消息时，使用此上下文。PDP可以决定允许或拒绝传出消息，以及提供传出策略数据对象。
M-Type (Message Type)
M-Type（消息类型）
The M-Type field in the Context Object identifies the applicable RSVP message type. M-Type values are identical to the values used in the "msg type" field in the RSVP header [RSVP].
上下文对象中的M-Type字段标识适用的RSVP消息类型。M-Type值与RSVP头[RSVP]中“msg Type”字段中使用的值相同。
The following RSVP message types are supported in COPS:
COPS中支持以下RSVP消息类型：
Path Resv PathErr ResvErr
路径Resv PathErr ResvErr
Other message types such as PathTear, ResvTear, and Resv Confirm are not supported. The list of supported message types can only be extended in later versions of RSVP and/or later version of this document.
不支持其他消息类型，如PathTear、ResvTear和Resv Confirm。支持的消息类型列表只能在RSVP的更高版本和/或本文档的更高版本中扩展。
All objects that were received in an RSVP message are encapsulated inside the Client Specific Information Object (Signaled ClientSI) sent from the PEP to the remote PDP (see Section 3.1. on multiple flows packed in a single RSVP message).
RSVP消息中接收到的所有对象都封装在从PEP发送到远程PDP的特定于客户端的信息对象（有信号的ClientSI）中（关于单个RSVP消息中打包的多个流，请参见第3.1节）。
The PEP and PDP share RSVP state, and the PDP is assumed to implement the same RSVP functional specification as the PEP. In the case where a PDP detects the absence of objects required by [RSVP] it should return an <Error> in the Decision message indicating "Mandatory client-specific info missing". If, on the other hand, the PDP detects the absence of optional RSVP objects that are needed to approve the Request against current policies, the PDP should return a negative <Decision>.
PEP和PDP共享RSVP状态，并且假定PDP实现与PEP相同的RSVP功能规范。如果PDP检测到缺少[RSVP]所需的对象，则应在决策消息中返回<Error>，指示“缺少强制性客户特定信息”。另一方面，如果PDP检测到不存在根据当前策略批准请求所需的可选RSVP对象，则PDP应返回否定的<Decision>。
Unlike the Incoming and Outgoing contexts, "Resource Allocation" is not always directly associated with a specific RSVP message. In a multicast session, it may represent the merging of multiple incoming reservations. Therefore, the ClientSI object should specifically contain the SESSION and STYLE objects along with the merged FLOWSPEC, FILTERSPEC list, and SCOPE object (whenever relevant).
与传入和传出上下文不同，“资源分配”并不总是与特定的RSVP消息直接关联。在多播会话中，它可能表示多个传入保留的合并。因此，ClientSI对象应该特别包含会话和样式对象以及合并的FLOWSPEC、FILTERSPEC列表和SCOPE对象（只要相关）。
COPS provides the PDP with flexible controls over the PEP using RSVP's response to messages. While accepting an RSVP message, PDPs may provide preemption priority, trigger warnings, replace RSVP objects, and much more, using Decision Commands, Flags, and Objects.
COPS使用RSVP对消息的响应为PDP提供对PEP的灵活控制。在接受RSVP消息时，PDP可以使用决策命令、标志和对象提供抢占优先级、触发警告、替换RSVP对象等等。
DECISION COMMANDS
决策命令
Only two commands apply to RSVP
只有两个命令适用于RSVP
Install
安装
Positive Response: Accept/Allow/Admit an RSVP message or local resource allocation.
正面响应：接受/允许/承认RSVP消息或本地资源分配。
Remove
去除
Negative Response: Deny/Reject/Remove an RSVP message or local resource allocation.
否定响应：拒绝/拒绝/删除RSVP消息或本地资源分配。
DECISION FLAGS
决策标志
The only decision flag that applies to RSVP:
适用于RSVP的唯一决策标志：
Trigger Error
触发错误
If this flag is set, RSVP should schedule a PathErr, in response to a Path message, or a ResvErr (in response of a Resv message).
如果设置了此标志，RSVP应安排一个PathErr，以响应Path消息，或安排一个ResvErr（响应Resv消息）。
STATELESS POLICY DATA
无状态策略数据
This object may include one or more policy elements (as specified for the RSVP Policy Data object [RSVP-EXT]) which are assumed to be well understood by the client's LPDP. The PEP should consider these as an addition to the decision already received from the PDP (it can only add, but cannot override it).
该对象可能包括一个或多个策略元素（如为RSVP策略数据对象[RSVP-EXT]指定的），假定客户的LPDP能够很好地理解这些元素。PEP应该将这些考虑为已经从PDP接收到的决策的补充（它只能添加，但不能覆盖它）。
For example, given Policy Elements that specify a flow's preemption priority, these elements may be included in an incoming Resv message or may be provided by the PDP responding to a query.
例如，给定指定流的抢占优先级的策略元素，这些元素可以包括在传入的Resv消息中，或者可以由响应查询的PDP提供。
Stateless objects must be well understood, but not necessarily supported by all PEPs. For example, assuming a standard policy element for preemption priority, it is perfectly legitimate for some PEPs not to support such preemption and to ignore it. The PDP must be careful when using such objects. In particular, it must be prepared for these objects to be ignored by PEPs.
无状态对象必须被很好地理解，但不一定得到所有PEP的支持。例如，假设抢占优先级有一个标准的策略元素，一些政治公众人物不支持这种抢占并忽略它是完全合法的。PDP在使用此类对象时必须小心。特别是，必须为政治公众人物忽略这些对象做好准备。
Stateless Policy Data may be returned in decisions and apply individually to each of the contexts flagged in REQ messages. When applied to Incoming, it is assumed to have been received as a POLICY_DATA object in the incoming message. When applied to Resource Allocation it is assumed to have been received on all merged incoming messages. Last, when applied to outgoing messages it is assumed to have been received in all messages contributing to the outgoing message.
无状态策略数据可以在决策中返回，并分别应用于REQ消息中标记的每个上下文。当应用于传入消息时，假定它已作为传入消息中的策略_数据对象接收。当应用于资源分配时，假定已在所有合并的传入消息上接收到该消息。最后，当应用于传出消息时，假定它已在所有对传出消息有贡献的消息中收到。
REPLACEMENT DATA
替换数据
The Replacement object may contain multiple RSVP objects to be replaced (from the original RSVP request). Typical replacement is performed on the "Forward Outgoing" request (for instance, replacing outgoing Policy Data), but is not limited, and can also be performed on other contexts (such as "Resources-Allocation Request"). In other cases, replacement of the RSVP FlowSpec object may be useful for controlling resources across a trusted zone (with policy ignorant
替换对象可能包含多个要替换的RSVP对象（来自原始RSVP请求）。典型的替换是在“转发传出”请求上执行的（例如，替换传出策略数据），但不限于此，也可以在其他上下文上执行（例如“资源分配请求”）。在其他情况下，替换RSVP FlowSpec对象可能有助于跨受信任区域控制资源（策略不受影响）
nodes (PINs). Currently, RSVP clients are only required to allow replacement of three objects: POLICY_DATA, ERROR_SPEC, and FLOWSPEC, but could optionally support replacement of other objects.
节点（引脚）。目前，RSVP客户端只需要允许替换三个对象：POLICY_DATA、ERROR_SPEC和FLOWSPEC，但也可以选择支持替换其他对象。
RSVP object replacement is performed in the following manner:
RSVP对象替换按以下方式执行：
If no Replacement Data decision appears in a decision message, all signaled objects are processed as if the PDP was not there. When an object of a certain C-Num appears, it replaces ALL the instances of C-Num objects in the RSVP message. If it appears empty (with a length of 4) it simply removes all instances of C-Num objects without adding anything.
如果决策消息中未出现任何替换数据决策，则所有发信号的对象都将被处理，就像PDP不在决策消息中一样。当某个C-Num对象出现时，它将替换RSVP消息中C-Num对象的所有实例。如果它显示为空（长度为4），则只删除C-Num对象的所有实例，而不添加任何内容。
3 Operation of COPS for RSVP PEPs
3 RSVP政治公众人物的警察行动
Policy Control is performed per RSVP flow, which is defined by the atomic unit of an RSVP reservation (TC reservation). Reservation styles may also impact the definition of flows; a set of senders which are considered as a single flow for WF reservation are considered as a set of individual flows when FF style is used.
策略控制根据RSVP流执行，RSVP流由RSVP保留（TC保留）的原子单元定义。保留样式也可能影响流的定义；当使用FF样式时，被视为WF保留的单个流的一组发送器被视为一组单独的流。
Multiple FF flows may be packed into a single Resv message. A packed message must be unpacked where a separate request is issued for each of the packed flows as if they were individual RSVP messages. Each COPS Request should include the associated POLICY_DATA objects, which are, by default, all POLICY_DATA objects in the packed message. Sophisticated PEPs, capable of looking inside policy objects, may examine the POLICY_DATA or SCOPE object to narrow down the list of associated flows (as an optimization).
多个FF流可以打包到单个Resv消息中。必须对打包消息进行解包，其中对每个打包流发出单独的请求，就像它们是单独的RSVP消息一样。每个COPS请求都应该包括关联的策略数据对象，默认情况下，这些对象是打包消息中的所有策略数据对象。能够查看策略对象内部的复杂PEP可以检查策略数据或范围对象，以缩小关联流的列表（作为优化）。
Please note that the rules governing Packed RSVP message apply equally to the Incoming as well as the Outgoing REQ context.
请注意，控制压缩RSVP消息的规则同样适用于传入和传出REQ上下文。
When making a policy decision, the PDP may consider both Resv as well as its matching Path state (associated state). State association is straightforward in the common unicast case since the RSVP flow includes one Path state and one Resv state. In multicast cases this correspondence may be more complicated, as the match may be many-to-many. The COPS protocol assumes that the PDP is RSVP knowledgeable and capable of determining these associations based on the contents of the Client REQ message and especially the ClientSI object.
在进行策略决策时，PDP既可以考虑RESV，也可以考虑其匹配的路径状态（关联状态）。由于RSVP流包括一个路径状态和一个Resv状态，因此状态关联在普通单播情况下非常简单。在多播情况下，这种通信可能更复杂，因为匹配可能是多对多的。COPS协议假设PDP具有RSVP知识，能够根据客户机REQ消息的内容，特别是ClientSI对象，确定这些关联。
For example, the PDP should be able to recognize activation and deactivation of RSVP blockade state following discrete events like the arrival of a ResvErr message (activate the blockade state) as well as the change in the outgoing Resv message.
例如，PDP应能够在诸如ResvErr消息到达（激活封锁状态）以及传出Resv消息中的变化等离散事件之后识别RSVP封锁状态的激活和停用。
In RSVP, the admission of a new reservation requires both an administrative approval (policy control) and capacity admission control. After being approved by both, and after the reservation was successfully installed, the PEP notifies the remote PDP by sending a report message specifying the Commit type. The Commit type report message signals when billing should effectively begin and performing heavier delayed operations (e.g., debiting a credit card) is permissible by the PDP.
在RSVP中，新预订的接纳需要行政批准（政策控制）和容量接纳控制。经双方批准后，以及成功安装保留后，PEP通过发送指定提交类型的报告消息通知远程PDP。PDP允许提交类型报告消息在计费应有效开始时发出信号，并执行较重的延迟操作（例如，借记信用卡）。
If, instead, a PDP approved reservation fails admission due to lack of resources, the PEP must issue a no-commit report and fold back and send an updated request to its previous state (previously installed reservation). If no state was previously installed, the PEP should issue a delete (DRQ).
相反，如果PDP批准的预订由于资源不足而无法进入，则PEP必须发出“无提交”报告，并向后折叠并将更新的请求发送到其以前的状态（以前安装的预订）。如果之前未安装任何状态，政治公众人物应发布删除（DRQ）。
PathTear and ResvTear messages are not controlled by this policy architecture. This relies on two assumptions: First, that MD-5 authentication verifies that the Tear is received from the same node that sent the initial reservation, and second, that it is functionally equivalent to that node holding off refreshes for this reservation. When a ResvTear or PathTear is received at the PEP, all affected states installed on the PDP should either be deleted or updated by the PEP.
PathTear和ResvTear消息不受此策略体系结构的控制。这依赖于两个假设：首先，MD-5身份验证验证是否从发送初始保留的同一节点接收到撕裂，其次，它在功能上等同于该节点暂停此保留的刷新。当PEP收到ResvTear或PathTear时，安装在PDP上的所有受影响状态应由PEP删除或更新。
Because COPS is a stateful protocol, refreshes for RSVP Path and Resv messages need not be constantly sent to the remote PDP. Once a decision has been returned for a request, the PEP can cache that decision and apply it to future refreshes. When the PEP detects a change in the corresponding Resv or Path message, it should update the PDP with the new request-state. PEPs may continue to use the cached state until receiving the PDP response. This case is very different from initial admission of a flow; given that valid credentials and authentication have already been established, the relatively long RSVP refresh period, and the short PEP-PDP response time, the tradeoff between expedient updates and attack prevention leans toward expediency. However, this is really a PEP choice, and is irrelevant to PDPs.
因为COPS是一种有状态协议，所以RSVP路径和Resv消息的刷新无需持续发送到远程PDP。为请求返回决策后，PEP可以缓存该决策并将其应用于将来的刷新。当PEP检测到相应的Resv或Path消息发生变化时，应使用新的请求状态更新PDP。PEP可以继续使用缓存状态，直到收到PDP响应。这种情况与流的初始进入非常不同；考虑到已经建立了有效的凭证和身份验证、相对较长的RSVP刷新周期和较短的PEP-PDP响应时间，权宜更新和攻击预防之间的权衡倾向于权宜。然而，这实际上是政治公众人物的选择，与个人发展计划无关。
If the connection is lost between the PEP and the PDP, the cached RSVP state may be retained for the RSVP timeout period to be used for previously admitted flows (but cannot be applied to new or updated state). If the connection can not be reestablished with the PDP or a backup PDP after the timeout period, the PEP is expected to purge all its cached decisions. Without applicable cached decision, the PEP must either reject the flow or resort to its LPDP (if available) for decisions.
如果PEP和PDP之间的连接丢失，缓存的RSVP状态可能会保留一段RSVP超时时间，以用于先前允许的流（但不能应用于新的或更新的状态）。如果超时后无法与PDP或备份PDP重新建立连接，则PEP将清除其所有缓存的决定。如果没有适用的缓存决策，PEP必须拒绝流或求助于其LPDP（如果可用）进行决策。
Once a connection is reestablished to a new (or the original) PDP the PDP may issue a SSQ request. In this case, the PEP must reissue requests that correspond to the current RSVP state (as if all the state has been updated recently). It should also include in its LPDPDecision the current (cached) decision regarding each such state.
一旦重新建立与新（或原始）PDP的连接，PDP可发出SSQ请求。在这种情况下，PEP必须重新发出与当前RSVP状态相对应的请求（就好像所有状态都是最近更新的一样）。它还应该在其LPDPDecision中包含关于每个此类状态的当前（缓存）决策。
RSVP is a store-and-forward control protocol where messages are processed in three distinctive steps (input, resource allocation, and output). Each step requires a separate policy decision as indicated by context flags (see Section 2.2). In many cases, setting multiple context flags for bundling two or three operations together in one request may significantly optimize protocol operations.
RSVP是一种存储转发控制协议，其中消息按三个不同的步骤（输入、资源分配和输出）进行处理。每个步骤都需要一个单独的策略决策，如上下文标志所示（参见第2.2节）。在许多情况下，设置多个上下文标志以便在一个请求中将两个或三个操作捆绑在一起可能会显著优化协议操作。
The following rules apply for setting multiple Context flags:
以下规则适用于设置多个上下文标志：
a. Multiple context flags can be set only in two generic cases, which represent a substantial portion of expected COPS transactions, and can be guaranteed not to cause ambiguity.
a. 只能在两种通用情况下设置多个上下文标志，这两种情况代表了预期COPS事务的很大一部分，并且可以保证不会造成歧义。
Unicast FF:
单播FF:
[Incoming + Allocation + Outgoing]
[传入+分配+传出]
Multicast with only one Resv message received on the interface
在接口上仅接收一条Resv消息的多播
[Incoming + Allocation]
[传入+分配]
b. Context events are ordered by time since every message must first be processed as Incoming, then as Resource allocation and only then as Outgoing. When multiple context flags are set, all ClientSI objects included in the request are assumed to be processed according to the latest flag. This rule applies both to the request (REQ) context as well as to the decision (DEC) context.
b. 上下文事件是按时间排序的，因为每个消息必须首先作为传入消息处理，然后作为资源分配处理，然后才作为传出消息处理。如果设置了多个上下文标志，则假定请求中包含的所有ClientSI对象都根据最新标志进行处理。此规则既适用于请求（REQ）上下文，也适用于决策（DEC）上下文。
For example, when combining Incoming + Allocation for an incoming Resv message, the flowspec included in the ClientSI would be the one corresponding to the Resource-Allocation context (TC).
例如，当为传入的Resv消息组合传入+分配时，ClientSI中包含的flowspec将是与资源分配上下文（TC）相对应的flowspec。
c. Each decision is bound to a context object, which determines which portion of the request context it applies to. When individual decisions apply to different sub-groups of the context, the PDP should send each group of decision objects encapsulated by the context flags object with the context flags applicable to these objects set (see the examples in Section 5).
c. 每个决策都绑定到一个上下文对象，该对象确定它应用于请求上下文的哪个部分。当单个决策应用于上下文的不同子组时，PDP应发送上下文标志对象封装的每组决策对象，并设置适用于这些对象的上下文标志（参见第5节中的示例）。
RSVP uses the ERROR_SPEC object in PathErr and ResvErr messages to report policy errors. While the contents of the ERROR_SPEC object are defined in [RSVP,RSVP-EXT], the PDP is in the best position to provide its contents (sub-codes). This is performed in the following manner: First, the PEP (RSVP) queries the PDP before sending a PathErr or ResvErr, and then the PDP returns the constructed ERROR_SPEC in the Replacement Data Decision Object.
RSVP使用PathErr和ResvErr消息中的ERROR_SPEC对象报告策略错误。虽然[RSVP，RSVP-EXT]中定义了ERROR_SPEC对象的内容，但PDP处于提供其内容（子代码）的最佳位置。这以以下方式执行：首先，PEP（RSVP）在发送PathErr或ResvErr之前查询PDP，然后PDP在替换数据决策对象中返回构造的错误规范。
4 Security Considerations
4安全考虑
This document relies on COPS for its signaling and its security. Please refer to section "Security Considerations" in [COPS].
本文件的信号和安全性依赖于COPS。请参阅[COPS]中的“安全注意事项”一节。
Security for RSVP messages is provided by inter-router MD5 authentication [MD5], assuming a chain-of-trust model. A likely deployment scenario calls for PEPs to be deployed only at the network edge (boundary nodes) while the core of the network (backbone) consists of PIN nodes. In this scenario MD5 trust (authentication) is established between boundary (non-neighboring) PEPs. Such trust can be achieved through internal signing (integrity) of the Policy Data object itself, which is left unmodified as it passes through PIN nodes (see [RSVP-EXT]).
RSVP消息的安全性由路由器间MD5身份验证[MD5]提供，假设采用信任链模型。可能的部署场景要求仅在网络边缘（边界节点）部署PEP，而网络核心（主干）由PIN节点组成。在此场景中，在边界（非相邻）PEP之间建立MD5信任（身份验证）。这种信任可以通过策略数据对象本身的内部签名（完整性）来实现，该对象在通过PIN节点时保持不变（请参见[RSVP-EXT]）。
5 Illustrative Examples, Using COPS for RSVP
5个示例，将COP用于RSVP
This section details both typical unicast and multicast scenarios.
本节详细介绍了典型的单播和多播场景。
This section details the steps in using COPS for controlling a Unicast RSVP flow. It details the contents of the COPS messages with respect to Figure 1.
本节详细介绍了使用COP控制单播RSVP流的步骤。它详细说明了与图1相关的COPS消息的内容。
PEP (router)
+-----------------+
| |
R1 ------------+if1 if2+------------ S1
| |
+-----------------+
PEP (router)
+-----------------+
| |
R1 ------------+if1 if2+------------ S1
| |
+-----------------+
Figure 1: Unicast Example: a single PEP view
图1：单播示例：单个PEP视图
The PEP router has two interfaces (if1, if2). Sender S1 sends to receiver R1.
PEP路由器有两个接口（if1、if2）。发送方S1发送到接收方R1。
A Path message arrives from S1:
路径消息从S1到达：
PEP --> PDP REQ := <Handle A> <Context: in & out, Path>
<In-Interface if2> <Out-Interface if1>
<ClientSI: all objects in Path message>
PEP --> PDP REQ := <Handle A> <Context: in & out, Path>
<In-Interface if2> <Out-Interface if1>
<ClientSI: all objects in Path message>
PDP --> PEP DEC := <Handle A> <Context: in & out, Path>
<Decision: Command, Install>
PDP --> PEP DEC := <Handle A> <Context: in & out, Path>
<Decision: Command, Install>
A Resv message arrives from R1:
来自R1的Resv消息到达：
PEP --> PDP REQ := <Handle B>
<Context: in & allocation & out, Resv>
<In-Interface if1> <Out-Interface if2>
<ClientSI: all objects in Resv message>
PEP --> PDP REQ := <Handle B>
<Context: in & allocation & out, Resv>
<In-Interface if1> <Out-Interface if2>
<ClientSI: all objects in Resv message>
PDP --> PEP DEC := <Handle B>
<Context: in, Resv>
<Decision: command, Install>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=7>
<Context: out, Resv>
<Decision: command, Install>
<Decision: replacement, POLICY-DATA1>
PDP --> PEP DEC := <Handle B>
<Context: in, Resv>
<Decision: command, Install>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=7>
<Context: out, Resv>
<Decision: command, Install>
<Decision: replacement, POLICY-DATA1>
PEP --> PDP RPT := <Handle B>
<Report type: commit>
PEP --> PDP RPT := <Handle B>
<Report type: commit>
Notice that the Decision was split because of the need to specify different decision objects for different context flags.
请注意，由于需要为不同的上下文标志指定不同的决策对象，所以决策被拆分。
Time Passes, the PDP changes its decision:
随着时间的推移，PDP将更改其决策：
PDP --> PEP DEC := <Handle B>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=3>
PDP --> PEP DEC := <Handle B>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=3>
Because the priority is too low, the PEP preempts the flow:
由于优先级过低，政治公众人物会抢占流量：
PEP --> PDP DRQ := <Handle B>
<Reason Code: Preempted>
PEP --> PDP DRQ := <Handle B>
<Reason Code: Preempted>
Time Passes, the sender S1 ceases to send Path messages:
随着时间的推移，发送方S1停止发送路径消息：
PEP --> PDP DRQ := <Handle A>
<Reason: Timeout>
PEP --> PDP DRQ := <Handle A>
<Reason: Timeout>
This section details the steps in using COPS for controlling a multicast RSVP flow. It details the contents of the COPS messages with respect to Figure 2.
本节详细介绍了使用COPS控制多播RSVP流的步骤。它详细说明了与图2相关的COPS消息的内容。
PEP (router)
+-----------------+
| |
R1-------------+ if1 if3 +--------- S1
| |
R2----+ | |
| | |
+--------+ if2 if4 +--------- S2
| | |
R3----+ +-----------------+
PEP (router)
+-----------------+
| |
R1-------------+ if1 if3 +--------- S1
| |
R2----+ | |
| | |
+--------+ if2 if4 +--------- S2
| | |
R3----+ +-----------------+
Figure 2: Multicast example: a single PEP view
图2：多播示例：单个PEP视图
Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2) and three receivers (R1, R2, R3) for the same multicast session. Interface if2 is connected to a shared media. In this example, we assume that the multicast membership is already in place. No previous RSVP messages were received, and the first to arrive is a Path message on interface if3 from sender S1:
图2显示了一个RSVP PEP（路由器），它有两个发送方（S1、S2）和三个接收方（R1、R2、R3），用于同一个多播会话。接口if2连接到共享媒体。在本例中，我们假设多播成员资格已经存在。没有收到以前的RSVP消息，第一个到达的是来自发送方S1的接口if3上的路径消息：
PEP --> PDP REQ := <Handle A> <Context: in, Path>
<In-interface if3>
<ClientSI: all objects in incoming Path>
PEP --> PDP REQ := <Handle A> <Context: in, Path>
<In-interface if3>
<ClientSI: all objects in incoming Path>
PDP --> PEP DEC := <Handle A> <Context: in, Path>
<Decision: command, Install>
PDP --> PEP DEC := <Handle A> <Context: in, Path>
<Decision: command, Install>
The PEP consults its forwarding table, and finds two outgoing interface for the path (if1, if2). The exchange below is for interface if1, another exchange would likewise be completed for if2 using the new handle B2.
PEP查阅其转发表，并为路径找到两个传出接口（if1、if2）。下面的交换是针对接口if1的，另一个交换也将使用新句柄B2针对if2完成。
PEP --> PDP REQ := <Handle B1> <Context: out, Path>
<Out-interface if1>
<clientSI: all objects in outgoing Path>
PEP --> PDP REQ := <Handle B1> <Context: out, Path>
<Out-interface if1>
<clientSI: all objects in outgoing Path>
PDP --> PEP DEC := <Handle B1>
<Context: out, Path>
<Decision: command, Install>
<Decision: Replacement, POLICY-DATA1>
PDP --> PEP DEC := <Handle B1>
<Context: out, Path>
<Decision: command, Install>
<Decision: Replacement, POLICY-DATA1>
Here, the PDP decided to allow the forwarding of the Path message and provided the appropriate policy-data object for interface if1.
这里，PDP决定允许路径消息的转发，并为接口if1提供适当的策略数据对象。
Next, a WF Resv message from receiver R2 arrives on interface if2.
接下来，来自接收器R2的WF Resv消息到达接口if2。
PEP --> PDP REQ := <Handle C> <Context: in & allocation, Resv>
<In-interface if2>
<ClientSI: all objects in Resv message
including RSpec1 >
PEP --> PDP REQ := <Handle C> <Context: in & allocation, Resv>
<In-interface if2>
<ClientSI: all objects in Resv message
including RSpec1 >
PDP --> PEP DEC := <Handle C>
<Context: in, Resv>
<Decision: command, Install>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, priority=5>
PDP --> PEP DEC := <Handle C>
<Context: in, Resv>
<Decision: command, Install>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, priority=5>
PEP --> PDP RPT := <handle C> <Commit>
PEP --> PDP RPT := <handle C> <Commit>
Here, the PDP approves the reservation and assigned it preemption priority of 5. The PEP responded with a commit report.
在此，PDP批准保留并将其优先权分配为5。政治公众人物的回应是提交报告。
The PEP needs to forward the Resv message upstream toward S1:
政治公众人物需要将Resv消息向上游转发至S1：
PEP --> PDP REQ := <Handle E> <Context: out, Resv>
<out-interface if3>
<Client info: all objects in outgoing Resv>
PEP --> PDP REQ := <Handle E> <Context: out, Resv>
<out-interface if3>
<Client info: all objects in outgoing Resv>
PDP --> PEP DEC := <Handle E>
<Context: out, Resv>
<Decision: command, Install>
<Decision: replacement, POLICY-DATA2>
PDP --> PEP DEC := <Handle E>
<Context: out, Resv>
<Decision: command, Install>
<Decision: replacement, POLICY-DATA2>
Note: The Context object is part of this DEC message even though it may look redundant since the REQ specified only one context flag.
注意：上下文对象是这个DEC消息的一部分，尽管它看起来可能是多余的，因为REQ只指定了一个上下文标志。
Next, a new WF Resv message from receiver R3 arrives on interface if2 with a higher RSpec (Rspec2). Given two reservations arrived on if2, it cannot perform a request with multiple context flags, and must issue them separately.
接下来，来自接收器R3的新WF Resv消息到达具有更高RSpec（Rspec2）的接口if2。给定if2上到达的两个保留，它不能执行具有多个上下文标志的请求，必须分别发出它们。
The PEP re-issues an updated handle C REQ with a new context object <Context: in , Resv>, and receives a DEC for handle C.
PEP使用新的上下文对象<context:in，Resv>重新发出更新的句柄C请求，并接收句柄C的DEC。
PEP --> PDP REQ := <Handle F> <Context: in , Resv>
<In-interface if2>
<ClientSI: all objects in Resv message
including RSpec2 >
PEP --> PDP REQ := <Handle F> <Context: in , Resv>
<In-interface if2>
<ClientSI: all objects in Resv message
including RSpec2 >
PDP --> PEP DEC := <Handle F> <Context: in , Resv>
<Decision: command, Install>
PDP --> PEP DEC := <Handle F> <Context: in , Resv>
<Decision: command, Install>
PEP --> PDP REQ := <Handle G> <Context: allocation, Resv>
<In-interface if2>
<ClientSI: all objects in merged Resv
including RSpec2 >
PEP --> PDP REQ := <Handle G> <Context: allocation, Resv>
<In-interface if2>
<ClientSI: all objects in merged Resv
including RSpec2 >
PDP --> PEP DEC := <Handle G>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=5>
PDP --> PEP DEC := <Handle G>
<Context: allocation, Resv>
<Decision: command, Install>
<Decision: Stateless, Priority=5>
PEP --> PDP RPT := <handle G> <Commit>
PEP --> PDP RPT := <handle G> <Commit>
Given the change in incoming reservations, the PEP needs to forward a new outgoing Resv message upstream toward S1. This repeats exactly the previous interaction of Handle E, except that the ClientSI objects now reflect the merging of two reservations.
鉴于传入保留的变化，PEP需要向S1上游转发新的传出Resv消息。这完全重复了Handle E之前的交互，只是ClientSI对象现在反映了两个保留的合并。
If an ResvErr arrives from S1, the PEP maps it to R3 only (because it has a higher flowspec: Rspec2) the following takes place:
如果ResvErr从S1到达，PEP仅将其映射到R3（因为其具有更高的流程规范：Rspec2），则会发生以下情况：
PEP --> PDP REQ := <Handle H> <Context: in, ResvErr>
<In-interface if3>
<ClientSI: all objects in incoming ResvErr>
PEP --> PDP REQ := <Handle H> <Context: in, ResvErr>
<In-interface if3>
<ClientSI: all objects in incoming ResvErr>
PDP --> PEP DEC := <Handle H> <Context: in, ResvErr>
<Decision: command, Install>
PDP --> PEP DEC := <Handle H> <Context: in, ResvErr>
<Decision: command, Install>
PEP --> PDP REQ := <Handle I> <Context: out, ResvErr>
<Out-interface if2>
<ClientSI: all objects in outgoing ResvErr>
PEP --> PDP REQ := <Handle I> <Context: out, ResvErr>
<Out-interface if2>
<ClientSI: all objects in outgoing ResvErr>
PDP --> PEP DEC := <Handle I>
<Context: out, ResvErr>
<Decision: command, Install>
<Decision: Replacement, POLICY-DATA3>
PDP --> PEP DEC := <Handle I>
<Context: out, ResvErr>
<Decision: command, Install>
<Decision: Replacement, POLICY-DATA3>
When S2 joins the session by sending a Path message, incoming and outgoing Path requests are issued for the new Path. A new outgoing Resv request would be sent to S2.
当S2通过发送路径消息加入会话时，将为新路径发出传入和传出路径请求。将向S2发送一个新的传出Resv请求。
6 References
6参考文献
[RSVP-EXT] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[RSVP-EXT]Herzog，S.，“用于政策控制的RSVP扩展”，RFC 2750，2000年1月。
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy Based Admission Control", RFC 2753, January 2000.
[RAP]Yavatkar，R.，Pendarakis，D.和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月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）-功能规范”，RFC 22052997年9月。
7 Author Information and Acknowledgments
7作者信息和确认
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Fred Baker, Laura Cunningham, Russell Fenger, Roch Guerin, Ping Pan, and Raj Yavatkar, for their valuable contributions.
特别感谢我们的工作组主席安德鲁·史密斯和蒂莫西·奥马利、弗雷德·贝克、劳拉·坎宁安、罗素·芬格、罗奇·盖林、潘平和拉吉·亚瓦卡尔所作的宝贵贡献。
Jim Boyle Level 3 Communications 1025 Eldorado Boulevard Broomfield, CO 80021
美国科罗拉多州布鲁姆菲尔德埃尔多拉多大道1025号吉姆·博伊尔三级通信公司，邮编80021
Phone: 720.888.1192 EMail: jboyle@Level3.net
电话：720.888.1192电子邮件：jboyle@Level3.net
Ron Cohen CISCO Systems 4 Maskit St. Herzeliya Pituach 46766 Israel
Ron Cohen CISCO Systems 4 Maskit St.Herzeliya Pituach以色列46766
Phone: 972.9.9700064 EMail: ronc@cisco.com
电话：972.9.9700064电子邮件：ronc@cisco.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
大卫·达勒姆英特尔2111东北希尔斯伯勒25大道，或97124
Phone: 503.264.6232 EMail: David.Durham@intel.com
电话：503.264.6232电子邮件：大卫。Durham@intel.com
Raju Rajan AT&T Labs Research 180 Park Ave., P.O. Box 971 Florham Park, NJ 07932
新泽西州弗洛勒姆公园公园大道180号邮政信箱971号Raju Rajan AT&T实验室研究中心07932
Phone: 973.360.7229 EMail: raju@research.att.com
电话：973.360.7229电子邮件：raju@research.att.com
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
Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge, Middlesex UB11 1BN UK
Arun Sastry Cisco Systems 4英国米德尔塞克斯郡斯托克利公园Uxlibridge广场UB11 10亿英镑
Phone: +44-208-756-8693
EMail: asastry@cisco.com
Phone: +44-208-756-8693
EMail: asastry@cisco.com
8 Full Copyright Statement
8完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。