Network Working Group D. Durham, Ed.
Request for Comments: 2748 Intel
Category: Standards Track J. Boyle
Level 3
R. Cohen
Cisco
S. Herzog
IPHighway
R. Rajan
AT&T
A. Sastry
Cisco
January 2000
Network Working Group D. Durham, Ed.
Request for Comments: 2748 Intel
Category: Standards Track J. Boyle
Level 3
R. Cohen
Cisco
S. Herzog
IPHighway
R. Rajan
AT&T
A. Sastry
Cisco
January 2000
The COPS (Common Open Policy Service) Protocol
COPS（公共开放政策服务）协议
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Conventions used in this document
本文件中使用的公约
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
Abstract
摘要
This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.
本文档描述了一个简单的客户机/服务器模型，用于支持对QoS信令协议的策略控制。该模型不对策略服务器的方法进行任何假设，而是基于服务器将决策返回给策略请求。该模型设计为可扩展的，以便将来可能支持其他类型的策略客户端。但是，本文件并未声称这是实施未来类型政策的唯一或首选方法。
Table Of Contents
目录
1. Introduction....................................................3
1.1 Basic Model....................................................4
2. The Protocol....................................................6
2.1 Common Header..................................................6
2.2 COPS Specific Object Formats...................................8
2.2.1 Handle Object (Handle).......................................9
2.2.2 Context Object (Context).....................................9
2.2.3 In-Interface Object (IN-Int)................................10
2.2.4 Out-Interface Object (OUT-Int)..............................11
2.2.5 Reason Object (Reason)......................................12
2.2.6 Decision Object (Decision)..................................12
2.2.7 LPDP Decision Object (LPDPDecision).........................14
2.2.8 Error Object (Error)........................................14
2.2.9 Client Specific Information Object (ClientSI)...............15
2.2.10 Keep-Alive Timer Object (KATimer)..........................15
2.2.11 PEP Identification Object (PEPID)..........................16
2.2.12 Report-Type Object (Report-Type)...........................16
2.2.13 PDP Redirect Address (PDPRedirAddr)........................16
2.2.14 Last PDP Address (LastPDPAddr).............................17
2.2.15 Accounting Timer Object (AcctTimer)........................17
2.2.16 Message Integrity Object (Integrity).......................18
2.3 Communication.................................................19
2.4 Client Handle Usage...........................................21
2.5 Synchronization Behavior......................................21
3. Message Content................................................22
3.1 Request (REQ) PEP -> PDP.....................................22
3.2 Decision (DEC) PDP -> PEP....................................24
3.3 Report State (RPT) PEP -> PDP................................25
3.4 Delete Request State (DRQ) PEP -> PDP........................25
3.5 Synchronize State Request (SSQ) PDP -> PEP...................26
3.6 Client-Open (OPN) PEP -> PDP.................................26
3.7 Client-Accept (CAT) PDP -> PEP...............................27
3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................28
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................28
3.10 Synchronize State Complete (SSC) PEP -> PDP..................29
4. Common Operation...............................................29
4.1 Security and Sequence Number Negotiation......................29
4.2 Key Maintenance...............................................31
4.3 PEP Initialization............................................31
4.4 Outsourcing Operations........................................32
4.5 Configuration Operations......................................32
4.6 Keep-Alive Operations.........................................33
4.7 PEP/PDP Close.................................................33
5. Security Considerations........................................33
6. IANA Considerations............................................34
1. Introduction....................................................3
1.1 Basic Model....................................................4
2. The Protocol....................................................6
2.1 Common Header..................................................6
2.2 COPS Specific Object Formats...................................8
2.2.1 Handle Object (Handle).......................................9
2.2.2 Context Object (Context).....................................9
2.2.3 In-Interface Object (IN-Int)................................10
2.2.4 Out-Interface Object (OUT-Int)..............................11
2.2.5 Reason Object (Reason)......................................12
2.2.6 Decision Object (Decision)..................................12
2.2.7 LPDP Decision Object (LPDPDecision).........................14
2.2.8 Error Object (Error)........................................14
2.2.9 Client Specific Information Object (ClientSI)...............15
2.2.10 Keep-Alive Timer Object (KATimer)..........................15
2.2.11 PEP Identification Object (PEPID)..........................16
2.2.12 Report-Type Object (Report-Type)...........................16
2.2.13 PDP Redirect Address (PDPRedirAddr)........................16
2.2.14 Last PDP Address (LastPDPAddr).............................17
2.2.15 Accounting Timer Object (AcctTimer)........................17
2.2.16 Message Integrity Object (Integrity).......................18
2.3 Communication.................................................19
2.4 Client Handle Usage...........................................21
2.5 Synchronization Behavior......................................21
3. Message Content................................................22
3.1 Request (REQ) PEP -> PDP.....................................22
3.2 Decision (DEC) PDP -> PEP....................................24
3.3 Report State (RPT) PEP -> PDP................................25
3.4 Delete Request State (DRQ) PEP -> PDP........................25
3.5 Synchronize State Request (SSQ) PDP -> PEP...................26
3.6 Client-Open (OPN) PEP -> PDP.................................26
3.7 Client-Accept (CAT) PDP -> PEP...............................27
3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................28
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................28
3.10 Synchronize State Complete (SSC) PEP -> PDP..................29
4. Common Operation...............................................29
4.1 Security and Sequence Number Negotiation......................29
4.2 Key Maintenance...............................................31
4.3 PEP Initialization............................................31
4.4 Outsourcing Operations........................................32
4.5 Configuration Operations......................................32
4.6 Keep-Alive Operations.........................................33
4.7 PEP/PDP Close.................................................33
5. Security Considerations........................................33
6. IANA Considerations............................................34
7. References.....................................................35
8. Author Information and Acknowledgments.........................36
9. Full Copyright Statement.......................................38
7. References.....................................................35
8. Author Information and Acknowledgments.........................36
9. Full Copyright Statement.......................................38
This document describes a simple query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). One example of a policy client is an RSVP router that must exercise policy-based admission control over RSVP usage [RSVP]. We assume that at least one policy server exists in each controlled administrative domain. The basic model of interaction between a policy server and its clients is compatible with the framework document for policy based admission control [WRK].
本文档描述了一个简单的查询和响应协议，可用于在策略服务器（策略决策点或PDP）及其客户端（策略实施点或PEP）之间交换策略信息。策略客户端的一个示例是RSVP路由器，它必须对RSVP使用[RSVP]实施基于策略的许可控制。我们假设每个受控管理域中至少存在一个策略服务器。策略服务器及其客户端之间交互的基本模型与基于策略的许可控制框架文档[WRK]兼容。
A chief objective of this policy control protocol is to begin with a simple but extensible design. The main characteristics of the COPS protocol include:
此策略控制协议的主要目标是从一个简单但可扩展的设计开始。COPS协议的主要特点包括：
1. The protocol employs a client/server model where the PEP sends requests, updates, and deletes to the remote PDP and the PDP returns decisions back to the PEP.
1. 该协议采用客户机/服务器模型，其中PEP向远程PDP发送请求、更新和删除，PDP将决策返回给PEP。
2. The protocol uses TCP as its transport protocol for reliable exchange of messages between policy clients and a server. Therefore, no additional mechanisms are necessary for reliable communication between a server and its clients.
2. 该协议使用TCP作为其传输协议，以便在策略客户端和服务器之间可靠地交换消息。因此，服务器与其客户端之间的可靠通信不需要其他机制。
3. The protocol is extensible in that it is designed to leverage off self-identifying objects and can support diverse client specific information without requiring modifications to the COPS protocol itself. The protocol was created for the general administration, configuration, and enforcement of policies.
3. 该协议是可扩展的，因为它旨在利用自识别对象，并且可以支持各种特定于客户端的信息，而无需修改COPS协议本身。该协议是为策略的一般管理、配置和实施而创建的。
4. COPS provides message level security for authentication, replay protection, and message integrity. COPS can also reuse existing protocols for security such as IPSEC [IPSEC] or TLS to authenticate and secure the channel between the PEP and the PDP.
4. COPS为身份验证、重播保护和消息完整性提供消息级安全性。COP还可以重用现有的安全协议，如IPSEC[IPSEC]或TLS，以验证和保护PEP和PDP之间的通道。
5. The protocol is stateful in two main aspects: (1) Request/Decision state is shared between client and server and (2) State from various events (Request/Decision pairs) may be inter-associated. By (1) we mean that requests from the client PEP are installed or remembered by the remote PDP until they are explicitly deleted by the PEP. At the same time, Decisions from the remote PDP can be generated asynchronously at any time
5. 该协议在两个主要方面是有状态的：（1）请求/决策状态在客户端和服务器之间共享；（2）来自各种事件（请求/决策对）的状态可能是相互关联的。（1）我们的意思是，来自客户端PEP的请求由远程PDP安装或记忆，直到PEP明确删除它们为止。同时，可以随时异步生成来自远程PDP的决策
for a currently installed request state. By (2) we mean that the server may respond to new queries differently because of previously installed Request/Decision state(s) that are related.
对于当前安装的请求状态。（2）我们的意思是，由于以前安装的请求/决策状态相关，服务器可能会以不同的方式响应新查询。
6. Additionally, the protocol is stateful in that it allows the server to push configuration information to the client, and then allows the server to remove such state from the client when it is no longer applicable.
6. 此外，该协议是有状态的，因为它允许服务器将配置信息推送到客户端，然后允许服务器在不再适用时从客户端删除此类状态。
+----------------+
| |
| Network Node | Policy Server
| |
| +-----+ | COPS +-----+
| | PEP |<-----|-------------->| PDP |
| +-----+ | +-----+
| ^ |
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
+----------------+
| |
| Network Node | Policy Server
| |
| +-----+ | COPS +-----+
| | PEP |<-----|-------------->| PDP |
| +-----+ | +-----+
| ^ |
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
Figure 1: A COPS illustration.
图1:COPS示例。
Figure 1 Illustrates the layout of various policy components in a typical COPS example (taken from [WRK]). Here, COPS is used to communicate policy information between a Policy Enforcement Point (PEP) and a remote Policy Decision Point (PDP) within the context of a particular type of client. The optional Local Policy Decision Point (LPDP) can be used by the device to make local policy decisions in the absence of a PDP.
图1展示了典型COPS示例（取自[WRK]）中各种策略组件的布局。这里，COPS用于在特定类型的客户端上下文中，在策略实施点（PEP）和远程策略决策点（PDP）之间传递策略信息。在没有PDP的情况下，设备可以使用可选的本地策略决策点（LPDP）来做出本地策略决策。
It is assumed that each participating policy client is functionally consistent with a PEP [WRK]. The PEP may communicate with a policy server (herein referred to as a remote PDP [WRK]) to obtain policy decisions or directives.
假设每个参与的保单客户机在功能上与政治公众人物[WRK]一致。PEP可与策略服务器（在此称为远程PDP[WRK]）通信以获得策略决策或指令。
The PEP is responsible for initiating a persistent TCP connection to a PDP. The PEP uses this TCP connection to send requests to and receive decisions from the remote PDP. Communication between the PEP and remote PDP is mainly in the form of a stateful request/decision exchange, though the remote PDP may occasionally send unsolicited
PEP负责启动到PDP的持久TCP连接。PEP使用此TCP连接向远程PDP发送请求并从远程PDP接收决策。PEP和远程PDP之间的通信主要以有状态请求/决策交换的形式进行，尽管远程PDP偶尔会发送未经请求的请求
decisions to the PEP to force changes in previously approved request states. The PEP also has the capacity to report to the remote PDP that it has successfully completed performing the PDP's decision locally, useful for accounting and monitoring purposes. The PEP is responsible for notifying the PDP when a request state has changed on the PEP. Finally, the PEP is responsible for the deletion of any state that is no longer applicable due to events at the client or decisions issued by the server.
向政治公众人物作出的强制改变先前批准的请求状态的决定。政治公众人物还能够向远程PDP报告其已成功完成在本地执行PDP决策，这对于会计和监控目的非常有用。PEP负责在PEP上的请求状态发生变化时通知PDP。最后，PEP负责删除由于客户端事件或服务器发出的决定而不再适用的任何状态。
When the PEP sends a configuration request, it expects the PDP to continuously send named units of configuration data to the PEP via decision messages as applicable for the configuration request. When a unit of named configuration data is successfully installed on the PEP, the PEP should send a report message to the PDP confirming the installation. The server may then update or remove the named configuration information via a new decision message. When the PDP sends a decision to remove named configuration data from the PEP, the PEP will delete the specified configuration and send a report message to the PDP as confirmation.
当PEP发送配置请求时，它期望PDP通过适用于配置请求的决策消息持续向PEP发送配置数据的命名单元。当PEP上成功安装了一组命名配置数据时，PEP应向PDP发送报告消息，确认安装。然后，服务器可以通过新的决策消息更新或删除命名的配置信息。当PDP发送从PEP中删除命名配置数据的决定时，PEP将删除指定的配置并向PDP发送报告消息作为确认。
The policy protocol is designed to communicate self-identifying objects which contain the data necessary for identifying request states, establishing the context for a request, identifying the type of request, referencing previously installed requests, relaying policy decisions, reporting errors, providing message integrity, and transferring client specific/namespace information.
策略协议设计用于通信自识别对象，这些对象包含识别请求状态、建立请求上下文、识别请求类型、引用以前安装的请求、中继策略决策、报告错误、提供消息完整性所需的数据，以及传输特定于客户端/命名空间的信息。
To distinguish between different kinds of clients, the type of client is identified in each message. Different types of clients may have different client specific data and may require different kinds of policy decisions. It is expected that each new client-type will have a corresponding usage draft specifying the specifics of its interaction with this policy protocol.
为了区分不同类型的客户机，在每条消息中标识客户机的类型。不同类型的客户端可能具有不同的特定于客户端的数据，并且可能需要不同类型的策略决策。预计每种新的客户端类型都将有一个相应的使用草案，指定其与此策略协议交互的细节。
The context of each request corresponds to the type of event that triggered it. The COPS Context object identifies the type of request and message (if applicable) that triggered a policy event via its message type and request type fields. COPS identifies three types of outsourcing events: (1) the arrival of an incoming message (2) allocation of local resources, and (3) the forwarding of an outgoing message. Each of these events may require different decisions to be made. The content of a COPS request/decision message depends on the context. A fourth type of request is useful for types of clients that wish to receive configuration information from the PDP. This allows a PEP to issue a configuration request for a specific named device or module that requires configuration information to be installed.
每个请求的上下文对应于触发它的事件类型。COPS上下文对象通过其消息类型和请求类型字段标识触发策略事件的请求和消息类型（如果适用）。COPS识别三种类型的外包事件：（1）传入消息的到达（2）本地资源的分配，以及（3）传出消息的转发。这些事件中的每一个都可能需要做出不同的决定。COPS请求/决策消息的内容取决于上下文。第四种类型的请求对于希望从PDP接收配置信息的客户端类型很有用。这允许PEP针对需要安装配置信息的特定命名设备或模块发出配置请求。
The PEP may also have the capability to make a local policy decision via its Local Policy Decision Point (LPDP) [WRK], however, the PDP remains the authoritative decision point at all times. This means that the relevant local decision information must be relayed to the PDP. That is, the PDP must be granted access to all relevant information to make a final policy decision. To facilitate this functionality, the PEP must send its local decision information to the remote PDP via an LPDP decision object. The PEP must then abide by the PDP's decision as it is absolute.
政治公众人物还可以通过其本地政策决策点（LPDP）[WRK]做出本地政策决策，但是，PDP始终是权威决策点。这意味着必须将相关的本地决策信息转发给PDP。也就是说，必须授予PDP访问所有相关信息的权限，以做出最终决策。为了促进此功能，PEP必须通过LPDP决策对象将其本地决策信息发送给远程PDP。政治公众人物必须遵守PDP的决定，因为这是绝对的。
Finally, fault tolerance is a required capability for this protocol, particularly due to the fact it is associated with the security and service management of distributed network devices. Fault tolerance can be achieved by having both the PEP and remote PDP constantly verify their connection to each other via keep-alive messages. When a failure is detected, the PEP must try to reconnect to the remote PDP or attempt to connect to a backup/alternative PDP. While disconnected, the PEP should revert to making local decisions. Once a connection is reestablished, the PEP is expected to notify the PDP of any deleted state or new events that passed local admission control after the connection was lost. Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued). After failure and before the new connection is fully functional, disruption of service can be minimized if the PEP caches previously communicated decisions and continues to use them for some limited amount of time. Sections 2.3 and 2.5 detail COPS mechanisms for achieving reliability.
最后，容错是该协议所需的能力，特别是因为它与分布式网络设备的安全和服务管理相关。通过让PEP和远程PDP通过保持活动消息不断验证彼此的连接，可以实现容错。当检测到故障时，PEP必须尝试重新连接到远程PDP或尝试连接到备份/备用PDP。在断开连接的情况下，政治公众人物应重新做出本地决策。一旦重新建立连接，PEP将在连接丢失后通知PDP任何已删除状态或通过本地准入控制的新事件。此外，远程PDP可请求重新同步所有PEP的内部状态（重新发出所有先前安装的请求）。在故障发生后和新连接完全正常运行之前，如果PEP缓存先前传达的决定并在有限的时间内继续使用这些决定，则可以将服务中断降至最低。第2.3节和第2.5节详细介绍了实现可靠性的COPS机制。
This section describes the message formats and objects exchanged between the PEP and remote PDP.
本节描述PEP和远程PDP之间交换的消息格式和对象。
Each COPS message consists of the COPS header followed by a number of typed objects.
每个COPS消息由COPS头和许多类型化对象组成。
0 1 2 3
+--------------+--------------+--------------+--------------+
|Version| Flags| Op Code | Client-type |
+--------------+--------------+--------------+--------------+
| Message Length |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
|Version| Flags| Op Code | Client-type |
+--------------+--------------+--------------+--------------+
| Message Length |
+--------------+--------------+--------------+--------------+
Global note: //// implies field is reserved, set to 0.
全局注释：///表示字段为保留字段，设置为0。
The fields in the header are: Version: 4 bits COPS version number. Current version is 1.
标题中的字段为：版本：4位COPS版本号。当前版本为1。
Flags: 4 bits Defined flag values (all other flags MUST be set to 0): 0x1 Solicited Message Flag Bit This flag is set when the message is solicited by another COPS message. This flag is NOT to be set (value=0) unless otherwise specified in section 3.
标志：4位定义的标志值（所有其他标志必须设置为0）：0x1请求的消息标志位当消息被另一条COPS消息请求时设置此标志。除非第3节另有规定，否则不得设置该标志（值=0）。
Op Code: 8 bits The COPS operations: 1 = Request (REQ) 2 = Decision (DEC) 3 = Report State (RPT) 4 = Delete Request State (DRQ) 5 = Synchronize State Req (SSQ) 6 = Client-Open (OPN) 7 = Client-Accept (CAT) 8 = Client-Close (CC) 9 = Keep-Alive (KA) 10= Synchronize Complete (SSC)
操作代码：8位COPS操作：1=请求（REQ）2=决策（DEC）3=报告状态（RPT）4=删除请求状态（DRQ）5=同步状态请求（SSQ）6=客户端打开（OPN）7=客户端接受（CAT）8=客户端关闭（CC）9=保持活动（KA）10=同步完成（SSC）
Client-type: 16 bits
客户端类型：16位
The Client-type identifies the policy client. Interpretation of all encapsulated objects is relative to the client-type. Client-types that set the most significant bit in the client-type field are enterprise specific (these are client-types 0x8000 - 0xFFFF). (See the specific client usage documents for particular client-type IDs). For KA Messages, the client-type in the header MUST always be set to 0 as the KA is used for connection verification (not per client session verification).
客户端类型标识策略客户端。所有封装对象的解释都与客户端类型相关。在客户机类型字段中设置最高有效位的客户机类型是特定于企业的（这些是客户机类型0x8000-0xFFFF）。（有关特定客户端类型ID，请参阅特定客户端使用文档）。对于KA消息，标头中的客户端类型必须始终设置为0，因为KA用于连接验证（而不是每个客户端会话验证）。
Message Length: 32 bits Size of message in octets, which includes the standard COPS header and all encapsulated objects. Messages MUST be aligned on 4 octet intervals.
消息长度：以八位字节表示的32位消息大小，包括标准COPS头和所有封装对象。消息必须按4个八位字节间隔对齐。
All the objects follow the same object format; each object consists of one or more 32-bit words with a four-octet header, using the following format:
所有对象遵循相同的对象格式；每个对象由一个或多个32位字组成，并带有四个八位字节头，格式如下：
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
The length is a two-octet value that describes the number of octets (including the header) that compose the object. If the length in octets does not fall on a 32-bit word boundary, padding MUST be added to the end of the object so that it is aligned to the next 32-bit boundary before the object can be sent on the wire. On the receiving side, a subsequent object boundary can be found by simply rounding up the previous stated object length to the next 32-bit boundary.
长度是两个八位字节的值，用于描述组成对象的八位字节数（包括标头）。如果以八位字节为单位的长度不在32位字边界上，则必须将填充添加到对象的末尾，以便在将对象发送到线上之前将其与下一个32位边界对齐。在接收端，只需将先前规定的对象长度四舍五入到下一个32位边界即可找到后续对象边界。
Typically, C-Num identifies the class of information contained in the object, and the C-Type identifies the subtype or version of the information contained in the object.
通常，C-Num标识对象中包含的信息类别，C-Type标识对象中包含的信息的子类型或版本。
C-num: 8 bits 1 = Handle 2 = Context 3 = In Interface 4 = Out Interface 5 = Reason code 6 = Decision 7 = LPDP Decision 8 = Error 9 = Client Specific Info 10 = Keep-Alive Timer 11 = PEP Identification 12 = Report Type 13 = PDP Redirect Address 14 = Last PDP Address 15 = Accounting Timer 16 = Message Integrity
C-num:8位1=句柄2=上下文3=接口4=接口5=原因码6=决策7=LPDP决策8=错误9=客户端特定信息10=保持活动计时器11=PEP标识12=报告类型13=PDP重定向地址14=最后一个PDP地址15=记帐计时器16=消息完整性
C-type: 8 bits Values defined per C-num.
C-type：每个C-num定义8位值。
The Handle Object encapsulates a unique value that identifies an installed state. This identification is used by most COPS operations. A state corresponding to a handle MUST be explicitly deleted when it is no longer applicable. See Section 2.4 for details.
句柄对象封装了一个唯一的值，该值标识安装状态。大多数警察行动都使用此标识。当句柄不再适用时，必须显式删除该句柄对应的状态。详见第2.4节。
C-Num = 1
C-Num = 1
C-Type = 1, Client Handle.
C-Type=1，客户端句柄。
Variable-length field, no implied format other than it is unique from other client handles from the same PEP (a.k.a. COPS TCP connection) for a particular client-type. It is always initially chosen by the PEP and then deleted by the PEP when no longer applicable. The client handle is used to refer to a request state initiated by a particular PEP and installed at the PDP for a client-type. A PEP will specify a client handle in its Request messages, Report messages and Delete messages sent to the PDP. In all cases, the client handle is used to uniquely identify a particular PEP's request for a client-type.
可变长度字段，没有隐含格式，但对于特定的客户端类型，它与来自同一PEP（也称为COPS TCP连接）的其他客户端句柄是唯一的。政治公众人物最初总是选择它，当不再适用时，政治公众人物会删除它。客户机句柄用于引用由特定PEP启动并安装在PDP上的客户机类型的请求状态。PEP将在其发送至PDP的请求消息、报告消息和删除消息中指定客户端句柄。在所有情况下，客户端句柄都用于唯一标识特定PEP对客户端类型的请求。
The client handle value is set by the PEP and is opaque to the PDP. The PDP simply performs a byte-wise comparison on the value in this object with respect to the handle object values of other currently installed requests.
客户端句柄值由PEP设置，对PDP不透明。PDP只需将此对象中的值与当前安装的其他请求的句柄对象值进行字节比较。
Specifies the type of event(s) that triggered the query. Required for request messages. Admission control, resource allocation, and forwarding requests are all amenable to client-types that outsource their decision making facility to the PDP. For applicable client-types a PEP can also make a request to receive named configuration information from the PDP. This named configuration data may be in a form useful for setting system attributes on a PEP, or it may be in the form of policy rules that are to be directly verified by the PEP.
指定触发查询的事件的类型。请求消息需要。接纳控制、资源分配和转发请求都适用于将其决策工具外包给PDP的客户类型。对于适用的客户端类型，PEP还可以请求从PDP接收命名配置信息。该命名配置数据的形式可能有助于在PEP上设置系统属性，也可能是由PEP直接验证的策略规则形式。
Multiple flags can be set for the same request. This is only allowed, however, if the set of client specific information in the combined request is identical to the client specific information that would be specified if individual requests were made for each specified flag.
可以为同一请求设置多个标志。但是，仅当组合请求中的特定于客户端的信息集与针对每个指定标志进行单独请求时指定的特定于客户端的信息集相同时，才允许这样做。
C-num = 2, C-Type = 1
C-num=2，C-Type=1
0 1 2 3
+--------------+--------------+--------------+--------------+
| R-Type | M-Type |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
| R-Type | M-Type |
+--------------+--------------+--------------+--------------+
R-Type (Request Type Flag)
R-Type（请求类型标志）
0x01 = Incoming-Message/Admission Control request 0x02 = Resource-Allocation request 0x04 = Outgoing-Message request 0x08 = Configuration request
0x01=传入消息/准入控制请求0x02=资源分配请求0x04=传出消息请求0x08=配置请求
M-Type (Message Type)
M-Type（消息类型）
Client Specific 16 bit values of protocol message types
协议消息类型的客户端特定16位值
The In-Interface Object is used to identify the incoming interface on which a particular request applies and the address where the received message originated. For flows or messages generated from the PEP's local host, the loop back address and ifindex are used.
In Interface对象用于标识应用特定请求的传入接口以及接收消息的来源地址。对于从PEP的本地主机生成的流或消息，将使用环回地址和ifindex。
This Interface object is also used to identify the incoming (receiving) interface via its ifindex. The ifindex may be used to differentiate between sub-interfaces and unnumbered interfaces (see RSVP's LIH for an example). When SNMP is supported by the PEP, this ifindex integer MUST correspond to the same integer value for the interface in the SNMP MIB-II interface index table.
此接口对象还用于通过其ifindex标识传入（接收）接口。ifindex可用于区分子接口和未编号接口（参见RSVP的LIH示例）。当PEP支持SNMP时，此ifindex整数必须对应于SNMP MIB-II接口索引表中接口的相同整数值。
Note: The ifindex specified in the In-Interface is typically relative to the flow of the underlying protocol messages. The ifindex is the interface on which the protocol message was received.
注意：in接口中指定的ifindex通常与底层协议消息流相关。ifindex是接收协议消息的接口。
C-Num = 3
C-Num = 3
C-Type = 1, IPv4 Address + Interface
C-Type=1，IPv4地址+接口
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv4 address specifies the IP address that the incoming message came from.
对于这种类型的接口对象，IPv4地址指定传入消息来自的IP地址。
C-Type = 2, IPv6 Address + Interface
C-Type=2，IPv6地址+接口
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv6 address specifies the IP address that the incoming message came from. The ifindex is used to refer to the MIB-II defined local incoming interface on the PEP as described above.
对于这种类型的接口对象，IPv6地址指定传入消息来自的IP地址。ifindex用于引用上述PEP上MIB-II定义的本地传入接口。
The Out-Interface is used to identify the outgoing interface to which a specific request applies and the address for where the forwarded message is to be sent. For flows or messages destined to the PEP's local host, the loop back address and ifindex are used. The Out-Interface has the same formats as the In-Interface Object.
Out接口用于标识应用特定请求的传出接口以及转发消息的发送地址。对于发送到PEP本地主机的流或消息，使用环回地址和ifindex。Out接口的格式与In接口对象的格式相同。
This Interface object is also used to identify the outgoing (forwarding) interface via its ifindex. The ifindex may be used to differentiate between sub-interfaces and unnumbered interfaces (see RSVP's LIH for an example). When SNMP is supported by the PEP, this ifindex integer MUST correspond to the same integer value for the interface in the SNMP MIB-II interface index table.
此接口对象还用于通过其ifindex标识传出（转发）接口。ifindex可用于区分子接口和未编号接口（参见RSVP的LIH示例）。当PEP支持SNMP时，此ifindex整数必须对应于SNMP MIB-II接口索引表中接口的相同整数值。
Note: The ifindex specified in the Out-Interface is typically relative to the flow of the underlying protocol messages. The ifindex is the one on which a protocol message is about to be forwarded.
注意：Out接口中指定的ifindex通常与底层协议消息流相关。ifindex是一个协议消息即将在其上转发的索引。
C-Num = 4
C-Num = 4
C-Type = 1, IPv4 Address + Interface
C-Type=1，IPv4地址+接口
Same C-Type format as the In-Interface object. The IPv4 address specifies the IP address to which the outgoing message is going. The ifindex is used to refer to the MIB-II defined local outgoing interface on the PEP.
与接口内对象相同的C类型格式。IPv4地址指定传出消息要发送到的IP地址。ifindex用于引用PEP上MIB-II定义的本地传出接口。
C-Type = 2, IPv6 Address + Interface
C-Type=2，IPv6地址+接口
Same C-Type format as the In-Interface object. For this type of the interface object, the IPv6 address specifies the IP address to which the outgoing message is going. The ifindex is used to refer to the MIB-II defined local outgoing interface on the PEP.
与接口内对象相同的C类型格式。对于这种类型的接口对象，IPv6地址指定传出消息要发送到的IP地址。ifindex用于引用PEP上MIB-II定义的本地传出接口。
This object specifies the reason why the request state was deleted. It appears in the delete request (DRQ) message. The Reason Sub-code field is reserved for more detailed client-specific reason codes defined in the corresponding documents.
此对象指定删除请求状态的原因。它出现在删除请求（DRQ）消息中。原因子代码字段保留用于在相应文档中定义的更详细的客户特定原因代码。
C-Num = 5, C-Type = 1
C-Num=5，C-Type=1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Reason-Code | Reason Sub-code |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
| Reason-Code | Reason Sub-code |
+--------------+--------------+--------------+--------------+
Reason Code: 1 = Unspecified 2 = Management 3 = Preempted (Another request state takes precedence) 4 = Tear (Used to communicate a signaled state removal) 5 = Timeout (Local state has timed-out) 6 = Route Change (Change invalidates request state) 7 = Insufficient Resources (No local resource available) 8 = PDP's Directive (PDP decision caused the delete) 9 = Unsupported decision (PDP decision not supported) 10= Synchronize Handle Unknown 11= Transient Handle (stateless event) 12= Malformed Decision (could not recover) 13= Unknown COPS Object from PDP: Sub-code (octet 2) contains unknown object's C-Num and (octet 3) contains unknown object's C-Type.
原因代码：1=未指定2=管理3=抢占（另一个请求状态优先）4=撕裂（用于传达信号状态删除）5=超时（本地状态已超时）6=路由更改（更改使请求状态无效）7=资源不足（没有可用的本地资源）8=PDP指令（PDP决策导致删除）9=不支持的决策（PDP决策不受支持）10=同步句柄未知11=瞬态句柄（无状态事件）12=格式错误的决策（无法恢复）13=来自PDP的未知COPS对象：子代码（八位组2）包含未知对象的C-Num，（八位组3）包含未知对象的C-Type。
Decision made by the PDP. Appears in replies. The specific non-mandatory decision objects required in a decision to a particular request depend on the type of client.
PDP作出的决定。出现在回复中。针对特定请求的决策中所需的特定非强制性决策对象取决于客户端的类型。
C-Num = 6 C-Type = 1, Decision Flags (Mandatory)
C-Num=6 C-Type=1，决策标志（必需）
0 1 2 3
+--------------+--------------+--------------+--------------+
| Command-Code | Flags |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
| Command-Code | Flags |
+--------------+--------------+--------------+--------------+
Commands:
0 = NULL Decision (No configuration data available)
1 = Install (Admit request/Install configuration)
2 = Remove (Remove request/Remove configuration)
Commands:
0 = NULL Decision (No configuration data available)
1 = Install (Admit request/Install configuration)
2 = Remove (Remove request/Remove configuration)
Flags: 0x01 = Trigger Error (Trigger error message if set) Note: Trigger Error is applicable to client-types that are capable of sending error notifications for signaled messages.
标志：0x01=触发器错误（如果设置了触发器错误消息）注意：触发器错误适用于能够为信号消息发送错误通知的客户端类型。
Flag values not applicable to a given context's R-Type or client-type MUST be ignored by the PEP.
PEP必须忽略不适用于给定上下文的R类型或客户端类型的标志值。
C-Type = 2, Stateless Data
C-Type=2，无状态数据
This type of decision object carries additional stateless information that can be applied by the PEP locally. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. This object is optional in Decision messages and is interpreted relative to a given context.
这种类型的决策对象携带附加的无状态信息，PEP可以在本地应用这些信息。它是一个可变长度对象，其内部格式应在给定客户端类型的相关COPS扩展文档中指定。此对象在决策消息中是可选的，并相对于给定上下文进行解释。
It is expected that even outsourcing PEPs will be able to make some simple stateless policy decisions locally in their LPDP. As this set is well known and implemented ubiquitously, PDPs are aware of it as well (either universally, through configuration, or using the Client-Open message). The PDP may also include this information in its decision, and the PEP MUST apply it to the resource allocation event that generated the request.
预计即使外包政治公众人物也能在其LPDP中本地做出一些简单的无状态政策决策。由于这个集合是众所周知的，并且是普遍实现的，所以PDP也知道它（通过配置或使用客户机打开消息）。PDP还可以在其决策中包括该信息，PEP必须将其应用于生成请求的资源分配事件。
C-Type = 3, Replacement Data
C型=3，更换数据
This type of decision object carries replacement data that is to replace existing data in a signaled message. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to a given context.
这种类型的决策对象携带替换数据，用于替换信号消息中的现有数据。它是一个可变长度对象，其内部格式应在给定客户端类型的相关COPS扩展文档中指定。它在决策消息中是可选的，并相对于给定上下文进行解释。
C-Type = 4, Client Specific Decision Data
C-Type=4，客户特定决策数据
Additional decision types can be introduced using the Client Specific Decision Data Object. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to a given context.
可以使用特定于客户端的决策数据对象引入其他决策类型。它是一个可变长度对象，其内部格式应在给定客户端类型的相关COPS扩展文档中指定。它在决策消息中是可选的，并相对于给定上下文进行解释。
C-Type = 5, Named Decision Data
C-Type=5，命名决策数据
Named configuration information is encapsulated in this version of the decision object in response to configuration requests. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to both a given context and decision flags.
命名的配置信息封装在此版本的决策对象中，以响应配置请求。它是一个可变长度对象，其内部格式应在给定客户端类型的相关COPS扩展文档中指定。它在决策消息中是可选的，并且相对于给定的上下文和决策标志进行解释。
Decision made by the PEP's local policy decision point (LPDP). May appear in requests. These objects correspond to and are formatted the same as the client specific decision objects defined above.
政治公众人物的地方政策决策点（LPDP）做出的决策。可能出现在请求中。这些对象对应于上面定义的特定于客户机的决策对象，并且其格式与之相同。
C-Num = 7
C-Num = 7
C-Type = (same C-Type as for Decision objects)
C-Type = (same C-Type as for Decision objects)
This object is used to identify a particular COPS protocol error. The error sub-code field contains additional detailed client specific error codes. The appropriate Error Sub-codes for a particular client-type SHOULD be specified in the relevant COPS extensions document.
此对象用于标识特定的COPS协议错误。错误子代码字段包含其他详细的特定于客户端的错误代码。应在相关COPS扩展文档中指定特定客户端类型的相应错误子代码。
C-Num = 8, C-Type = 1
C-Num=8，C-Type=1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+
Error-Code:
错误代码：
1 = Bad handle 2 = Invalid handle reference 3 = Bad message format (Malformed Message) 4 = Unable to process (server gives up on query)
1=错误句柄2=无效句柄引用3=错误消息格式（错误消息）4=无法处理（服务器在查询时放弃）
5 = Mandatory client-specific info missing 6 = Unsupported client-type 7 = Mandatory COPS object missing 8 = Client Failure 9 = Communication Failure 10= Unspecified 11= Shutting down 12= Redirect to Preferred Server 13= Unknown COPS Object: Sub-code (octet 2) contains unknown object's C-Num and (octet 3) contains unknown object's C-Type. 14= Authentication Failure 15= Authentication Required
5=强制客户端特定信息缺失6=不支持的客户端类型7=强制COPS对象缺失8=客户端故障9=通信故障10=未指定11=关闭12=重定向到首选服务器13=未知COPS对象：子代码（八位字节2）包含未知对象的C-Num，（八位字节3）包含未知对象的C-type。14=身份验证失败15=需要身份验证
The various types of this object are required for requests, and used in reports and opens when required. It contains client-type specific information.
请求需要各种类型的此对象，并在需要时用于报告和打开。它包含特定于客户端类型的信息。
C-Num = 9,
C-Num=9，
C-Type = 1, Signaled ClientSI.
C-Type=1，信号客户端i。
Variable-length field. All objects/attributes specific to a client's signaling protocol or internal state are encapsulated within one or more signaled Client Specific Information Objects. The format of the data encapsulated in the ClientSI object is determined by the client-type.
可变长度字段。特定于客户端的信令协议或内部状态的所有对象/属性都封装在一个或多个特定于客户端的信令信息对象中。封装在ClientSI对象中的数据的格式由客户端类型决定。
C-Type = 2, Named ClientSI.
C-Type=2，命名为ClientSI。
Variable-length field. Contains named configuration information useful for relaying specific information about the PEP, a request, or configured state to the PDP server.
可变长度字段。包含用于将有关PEP、请求或配置状态的特定信息中继到PDP服务器的命名配置信息。
Times are encoded as 2 octet integer values and are in units of seconds. The timer value is treated as a delta.
时间编码为2个八位整数，以秒为单位。计时器值被视为增量。
C-Num = 10,
C-Num=10，
C-Type = 1, Keep-alive timer value
C-Type=1，保持活动计时器值
Timer object used to specify the maximum time interval over which a COPS message MUST be sent or received. The range of finite timeouts is 1 to 65535 seconds represented as an unsigned two-octet integer. The value of zero implies infinity.
Timer对象，用于指定必须发送或接收COPS消息的最大时间间隔。有限超时的范围为1到65535秒，表示为无符号两个八位整数。零的值意味着无穷大。
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+
The PEP Identification Object is used to identify the PEP client to the remote PDP. It is required for Client-Open messages.
PEP标识对象用于向远程PDP标识PEP客户端。对于客户端打开的消息，它是必需的。
C-Num = 11, C-Type = 1
C-Num=11，C-Type=1
Variable-length field. It is a NULL terminated ASCII string that is also zero padded to a 32-bit word boundary (so the object length is a multiple of 4 octets). The PEPID MUST contain an ASCII string that uniquely identifies the PEP within the policy domain in a manner that is persistent across PEP reboots. For example, it may be the PEP's statically assigned IP address or DNS name. This identifier may safely be used by a PDP as a handle for identifying the PEP in its policy rules.
可变长度字段。它是一个以NULL结尾的ASCII字符串，也被零填充到32位字边界（因此对象长度是4个八位字节的倍数）。PEPID必须包含一个ASCII字符串，该字符串以在PEP重新启动期间保持的方式唯一标识策略域中的PEP。例如，它可能是PEP静态分配的IP地址或DNS名称。PDP可以安全地将该标识符用作在其策略规则中标识政治公众人物的句柄。
The Type of Report on the request state associated with a handle:
与句柄关联的请求状态的报告类型：
C-Num = 12, C-Type = 1
C-Num=12，C-Type=1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
| Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+
Report-Type:
1 = Success : Decision was successful at the PEP
2 = Failure : Decision could not be completed by PEP
3 = Accounting: Accounting update for an installed state
Report-Type:
1 = Success : Decision was successful at the PEP
2 = Failure : Decision could not be completed by PEP
3 = Accounting: Accounting update for an installed state
A PDP when closing a PEP session for a particular client-type may optionally use this object to redirect the PEP to the specified PDP server address and TCP port number:
PDP在关闭特定客户端类型的PEP会话时，可以选择使用此对象将PEP重定向到指定的PDP服务器地址和TCP端口号：
C-Num = 13,
C-Num=13，
C-Type = 1, IPv4 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
C-Type = 1, IPv4 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
C-Type = 2, IPv6 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
C-Type = 2, IPv6 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
When a PEP sends a Client-Open message for a particular client-type the PEP SHOULD specify the last PDP it has successfully opened (meaning it received a Client-Accept) since the PEP last rebooted. If no PDP was used since the last reboot, the PEP will simply not include this object in the Client-Open message.
当PEP发送特定客户机类型的客户机打开消息时，PEP应指定自PEP上次重新启动以来其成功打开的最后一个PDP（意味着收到客户机接受）。如果上次重新启动后未使用PDP，则PEP将不会在客户端打开消息中包含此对象。
C-Num = 14,
C-Num=14，
C-Type = 1, IPv4 Address (Same format as PDPRedirAddr)
C-Type=1，IPv4地址（与PDDR格式相同）
C-Type = 2, IPv6 Address (Same format as PDPRedirAddr)
C-Type=2，IPv6地址（与PDDR格式相同）
Times are encoded as 2 octet integer values and are in units of seconds. The timer value is treated as a delta.
时间编码为2个八位整数，以秒为单位。计时器值被视为增量。
C-Num = 15,
C-Num=15，
C-Type = 1, Accounting timer value
C-Type=1，记帐计时器值
Optional timer value used to determine the minimum interval between periodic accounting type reports. It is used by the PDP to describe to the PEP an acceptable interval between unsolicited accounting updates via Report messages where applicable. It provides a method for the PDP to control the amount of accounting traffic seen by the network. The range of finite time values is 1 to 65535 seconds represented as an unsigned two-octet integer. A value of zero means there SHOULD be no unsolicited accounting updates.
可选计时器值，用于确定定期会计类型报告之间的最小间隔。PDP使用它向政治公众人物描述通过报告消息（如适用）进行未经请求的会计更新之间的可接受间隔。它为PDP提供了一种方法，用于控制网络看到的计费流量。有限时间值的范围为1到65535秒，表示为无符号两个八位整数。值为零意味着不应有未经请求的会计更新。
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+
The integrity object includes a sequence number and a message digest useful for authenticating and validating the integrity of a COPS message. When used, integrity is provided at the end of a COPS message as the last COPS object. The digest is then computed over all of a particular COPS message up to but not including the digest value itself. The sender of a COPS message will compute and fill in the digest portion of the Integrity object. The receiver of a COPS message will then compute a digest over the received message and verify it matches the digest in the received Integrity object.
完整性对象包括序列号和消息摘要，用于验证和验证COPS消息的完整性。使用时，完整性在COPS消息末尾作为最后一个COPS对象提供。然后对所有特定COPS消息计算摘要，直到但不包括摘要值本身。COPS消息的发送者将计算并填写完整性对象的摘要部分。然后，COPS消息的接收者将计算接收到的消息的摘要，并验证它与接收到的完整性对象中的摘要相匹配。
C-Num = 16,
C-Num=16，
C-Type = 1, HMAC digest
C-Type=1，HMAC摘要
The HMAC integrity object employs HMAC (Keyed-Hashing for Message Authentication) [HMAC] to calculate the message digest based on a key shared between the PEP and its PDP.
HMAC integrity对象使用HMAC（消息认证的密钥散列）[HMAC]根据PEP与其PDP之间共享的密钥计算消息摘要。
This Integrity object specifies a 32-bit Key ID used to identify a specific key shared between a particular PEP and its PDP and the cryptographic algorithm to be used. The Key ID allows for multiple simultaneous keys to exist on the PEP with corresponding keys on the PDP for the given PEPID. The key identified by the Key ID was used to compute the message digest in the Integrity object. All implementations, at a minimum, MUST support HMAC-MD5-96, which is HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to 96-bits to calculate the message digest.
此完整性对象指定一个32位密钥ID，用于标识特定PEP及其PDP之间共享的特定密钥以及要使用的加密算法。密钥ID允许PEP上同时存在多个密钥，且PDP上存在给定PEPID的相应密钥。由密钥ID标识的密钥用于计算Integrity对象中的消息摘要。所有实现至少必须支持HMAC-MD5-96，即HMAC使用MD5消息摘要算法[MD5]截断为96位以计算消息摘要。
This object also includes a sequence number that is a 32-bit unsigned integer used to avoid replay attacks. The sequence number is initiated during an initial Client-Open Client-Accept message exchange and is then incremented by one each time a new message is
此对象还包括一个序列号，该序列号是一个32位无符号整数，用于避免重播攻击。序列号在初始客户端开放客户端接受消息交换期间启动，然后在每次发送新消息时递增一
sent over the TCP connection in the same direction. If the sequence number reaches the value of 0xFFFFFFFF, the next increment will simply rollover to a value of zero.
通过TCP连接以相同的方向发送。如果序列号达到0xFFFFFF的值，则下一个增量将简单地滚动到零值。
The variable length digest is calculated over a COPS message starting with the COPS Header up to the Integrity Object (which MUST be the last object in a COPS message) INCLUDING the Integrity object's header, Key ID, and Sequence Number. The Keyed Message Digest field is not included as part of the digest calculation. In the case of HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that is then to be truncated to 96-bits before being stored in or verified against the Keyed Message Digest field as specified in [HMAC]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is used.
可变长度摘要在COPS消息上计算，从COPS头开始，直到完整性对象（必须是COPS消息中的最后一个对象），包括完整性对象的头、密钥ID和序列号。键入的消息摘要字段不包括在摘要计算中。在HMAC-MD5-96的情况下，HMAC-MD5将生成128位摘要，然后将其截断为96位，然后存储在[HMAC]中指定的密钥消息摘要字段中或根据该字段进行验证。使用HMAC-MD5-96时，键控消息摘要必须为96位。
0 1 2 3
+-------------+-------------+-------------+-------------+
| Key ID |
+-------------+-------------+-------------+-------------+
| Sequence Number |
+-------------+-------------+-------------+-------------+
| |
+ +
| ...Keyed Message Digest... |
+ +
| |
+-------------+-------------+-------------+-------------+
0 1 2 3
+-------------+-------------+-------------+-------------+
| Key ID |
+-------------+-------------+-------------+-------------+
| Sequence Number |
+-------------+-------------+-------------+-------------+
| |
+ +
| ...Keyed Message Digest... |
+ +
| |
+-------------+-------------+-------------+-------------+
The COPS protocol uses a single persistent TCP connection between the PEP and a remote PDP. One PDP implementation per server MUST listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP is responsible for initiating the TCP connection to a PDP. The location of the remote PDP can either be configured, or obtained via a service location mechanism [SRVLOC]. Service discovery is outside the scope of this protocol, however.
COPS协议在PEP和远程PDP之间使用单个持久TCP连接。每台服务器的一个PDP实现必须侦听已知的TCP端口号（COPS=3288[IANA]）。PEP负责启动与PDP的TCP连接。远程PDP的位置可以配置，也可以通过服务位置机制[SRVLOC]获得。但是，服务发现不在此协议的范围内。
If a single PEP can support multiple client-types, it may send multiple Client-Open messages, each specifying a particular client-type to a PDP over one or more TCP connections. Likewise, a PDP residing at a given address and port number may support one or more client-types. Given the client-types it supports, a PDP has the ability to either accept or reject each client-type independently. If a client-type is rejected, the PDP can redirect the PEP to an alternative PDP address and TCP port for a given client-type via COPS. Different TCP port numbers can be used to redirect the PEP to another PDP implementation running on the same server. Additional provisions for supporting multiple client-types (perhaps from
如果单个PEP可以支持多个客户端类型，则它可以发送多个客户端打开消息，每个消息通过一个或多个TCP连接向PDP指定特定的客户端类型。同样，驻留在给定地址和端口号处的PDP可支持一种或多种客户端类型。给定其支持的客户机类型，PDP能够独立地接受或拒绝每个客户机类型。如果客户机类型被拒绝，PDP可以通过COP将PEP重定向到给定客户机类型的备用PDP地址和TCP端口。可以使用不同的TCP端口号将PEP重定向到同一服务器上运行的另一个PDP实现。支持多种客户端类型的附加规定（可能来自
independent PDP vendors) on a single remote PDP server are not provided by the COPS protocol, but, rather, are left to the software architecture of the given server platform.
COPS协议不提供单个远程PDP服务器上的独立PDP供应商，而是由给定服务器平台的软件体系结构提供。
It is possible a single PEP may have open connections to multiple PDPs. This is the case when there are physically different PDPs supporting different client-types as shown in figure 2.
单个PEP可能与多个PDP有开放连接。当物理上不同的PDP支持不同的客户端类型时，就会出现这种情况，如图2所示。
+----------------+
| |
| Network Node | Policy Servers
| |
| +-----+ | COPS Client Type 1 +-----+
| | |<-----|-------------------->| PDP1|
| + PEP + | COPS Client Type 2 +-----+
| | |<-----|---------\ +-----+
| +-----+ | \----------| PDP2|
| ^ | +-----+
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
+----------------+
| |
| Network Node | Policy Servers
| |
| +-----+ | COPS Client Type 1 +-----+
| | |<-----|-------------------->| PDP1|
| + PEP + | COPS Client Type 2 +-----+
| | |<-----|---------\ +-----+
| +-----+ | \----------| PDP2|
| ^ | +-----+
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
Figure 2: Multiple PDPs illustration.
图2：多个PDP图示。
When a TCP connection is torn down or is lost, the PDP is expected to eventually clean up any outstanding request state related to request/decision exchanges with the PEP. When the PEP detects a lost connection due to a timeout condition it SHOULD explicitly send a Client-Close message for each opened client-type containing an <Error> object indicating the "Communication Failure" Error-Code. Additionally, the PEP SHOULD continuously attempt to contact the primary PDP or, if unsuccessful, any known backup PDPs. Specifically the PEP SHOULD keep trying all relevant PDPs with which it has been configured until it can establish a connection. If a PEP is in communication with a backup PDP and the primary PDP becomes available, the backup PDP is responsible for redirecting the PEP back to the primary PDP (via a <Client-Close> message containing a <PDPRedirAddr> object identifying the primary PDP to use for each affected client-type). Section 2.5 details synchronization behavior between PEPs and PDPs.
当TCP连接中断或丢失时，PDP有望最终清除与PEP的请求/决策交换相关的任何未完成请求状态。当PEP检测到由于超时条件导致的连接丢失时，它应该为每个打开的客户端类型显式发送一条客户端关闭消息，其中包含一个<Error>对象，指示“通信失败”错误代码。此外，政治公众人物应持续尝试联系主PDP，如果不成功，则联系任何已知的备用PDP。具体而言，PEP应继续尝试所有已配置的相关PDP，直到能够建立连接。如果PEP与备份PDP通信且主PDP可用，则备份PDP负责将PEP重定向回主PDP（通过<Client Close>消息，该消息包含一个<PDPRedirAddr>对象，该对象标识用于每个受影响的客户端类型的主PDP）。第2.5节详细介绍了PEP和PDP之间的同步行为。
The client handle is used to identify a unique request state for a single PEP per client-type. Client handles are chosen by the PEP and are opaque to the PDP. The PDP simply uses the request handle to uniquely identify the request state for a particular Client-Type over a particular TCP connection and generically tie its decisions to a corresponding request. Client handles are initiated in request messages and are then used by subsequent request, decision, and report messages to reference the same request state. When the PEP is ready to remove a local request state, it will issue a delete message to the PDP for the corresponding client handle. A handle MUST be explicitly deleted by the PEP before it can be used by the PEP to identify a new request state. Handles referring to different request states MUST be unique within the context of a particular TCP connection and client-type.
客户端句柄用于为每个客户端类型的单个PEP标识唯一的请求状态。客户机句柄由政治公众人物选择，对PDP不透明。PDP仅使用请求句柄通过特定TCP连接唯一标识特定客户机类型的请求状态，并将其决策与相应的请求联系起来。客户端句柄在请求消息中启动，然后由后续的请求、决策和报告消息使用，以引用相同的请求状态。当PEP准备删除本地请求状态时，它将向PDP发出一条删除消息，以获取相应的客户端句柄。在PEP可以使用句柄标识新的请求状态之前，PEP必须显式删除句柄。在特定TCP连接和客户端类型的上下文中，引用不同请求状态的句柄必须是唯一的。
When disconnected from a PDP, the PEP SHOULD revert to making local decisions. Once a connection is reestablished, the PEP is expected to notify the PDP of any events that have passed local admission control. Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued) by sending a Synchronize State message.
当与PDP断开连接时，政治公众人物应恢复作出本地决策。一旦重新建立连接，PEP应将通过本地准入控制的任何事件通知PDP。此外，远程PDP可通过发送同步状态消息来请求重新同步所有PEP的内部状态（重新发出所有先前安装的请求）。
After a failure and before a new connection is fully functional, disruption of service can be minimized if the PEP caches previously communicated decisions and continues to use them for some appropriate length of time. Specific rules for such behavior are to be defined in the appropriate COPS client-type extension specifications.
在故障发生后和新连接完全正常运行之前，如果PEP缓存先前传达的决策并在适当的时间内继续使用这些决策，则可以将服务中断降至最低。此类行为的具体规则将在相应的COPS客户端类型扩展规范中定义。
A PEP that caches state from a previous exchange with a disconnected PDP MUST communicate this fact to any PDP with which it is able to later reconnect. This is accomplished by including the address and TCP port of the last PDP for which the PEP is still caching state in the Client-Open message. The <LastPDPAddr> object will only be included for the last PDP with which the PEP was completely in sync. If the service interruption was temporary and the PDP still contains the complete state for the PEP, the PDP may choose not to synchronize all states. It is still the responsibility of the PEP to update the PDP of all state changes that occurred during the disruption of service including any states communicated to the previous PDP that had been deleted after the connection was lost. These MUST be explicitly deleted after a connection is reestablished. If the PDP issues a synchronize request the PEP MUST pass all current states to the PDP followed by a Synchronize State Complete message (thus
缓存先前与断开连接的PDP交换的状态的PEP必须将此事实传达给以后能够重新连接的任何PDP。这是通过在客户机打开消息中包含最后一个PDP的地址和TCP端口来实现的，PEP仍在缓存该PDP的状态。<LastPDPAddr>对象将仅包含在与PEP完全同步的最后一个PDP中。如果服务中断是暂时的，并且PDP仍然包含PEP的完整状态，PDP可以选择不同步所有状态。PEP仍有责任向PDP更新服务中断期间发生的所有状态变化，包括在连接断开后已被删除的与先前PDP通信的任何状态。在重新建立连接后，必须显式删除这些内容。如果PDP发出同步请求，PEP必须将所有当前状态传递给PDP，然后发送同步状态完成消息（因此
completing the synchronization process). If the PEP crashes and loses all cached state for a client-type, it will simply not include a <LastPDPAddr> in its Client-Open message.
完成同步过程）。如果PEP崩溃并丢失某个客户端类型的所有缓存状态，它将不会在其客户端打开消息中包含<LastPDPAddr>。
This section describes the basic messages exchanged between a PEP and a remote PDP as well as their contents. As a convention, object ordering is expected as shown in the BNF for each COPS message unless otherwise noted. The Integrity object, if included, MUST always be the last object in a message. If security is required and a message was received without a valid Integrity object, the receiver MUST send a Client-Close message for Client-Type=0 specifying the appropriate error code.
本节描述PEP和远程PDP之间交换的基本消息及其内容。作为惯例，除非另有说明，否则每个COPS消息的对象顺序应如BNF中所示。完整性对象（如果包含）必须始终是消息中的最后一个对象。如果需要安全性，并且收到的消息没有有效的完整性对象，则接收方必须发送客户端类型为0的客户端关闭消息，并指定相应的错误代码。
The PEP establishes a request state client handle for which the remote PDP may maintain state. The remote PDP then uses this handle to refer to the exchanged information and decisions communicated over the TCP connection to a particular PEP for a given client-type.
PEP建立一个请求状态客户端句柄，远程PDP可以维护该句柄的状态。然后，远程PDP使用该句柄来引用通过TCP连接与特定PEP就给定客户机类型进行通信的交换信息和决策。
Once a stateful handle is established for a new request, any subsequent modifications of the request can be made using the REQ message specifying the previously installed handle. The PEP is responsible for notifying the PDP whenever its local state changes so the PDP's state will be able to accurately mirror the PEP's state.
为新请求建立有状态句柄后，可以使用指定先前安装的句柄的REQ消息对请求进行任何后续修改。政治公众人物负责在其本地状态发生变化时通知PDP，以便PDP的状态能够准确反映政治公众人物的状态。
The format of the Request message is as follows:
请求信息的格式如下：
<Request Message> ::= <Common Header>
<Client Handle>
<Context>
[<IN-Int>]
[<OUT-Int>]
[<ClientSI(s)>]
[<LPDPDecision(s)>]
[<Integrity>]
<Request Message> ::= <Common Header>
<Client Handle>
<Context>
[<IN-Int>]
[<OUT-Int>]
[<ClientSI(s)>]
[<LPDPDecision(s)>]
[<Integrity>]
<ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
<ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
<LPDPDecision(s)> ::= <LPDPDecision> |
<LPDPDecision(s)> <LPDPDecision>
<LPDPDecision(s)> ::= <LPDPDecision> |
<LPDPDecision(s)> <LPDPDecision>
<LPDPDecision> ::= [<Context>]
<LPDPDecision: Flags>
[<LPDPDecision: Stateless Data>]
[<LPDPDecision: Replacement Data>]
[<LPDPDecision: ClientSI Data>]
[<LPDPDecision: Named Data>]
<LPDPDecision> ::= [<Context>]
<LPDPDecision: Flags>
[<LPDPDecision: Stateless Data>]
[<LPDPDecision: Replacement Data>]
[<LPDPDecision: ClientSI Data>]
[<LPDPDecision: Named Data>]
The context object is used to determine the context within which all the other objects are to be interpreted. It also is used to determine the kind of decision to be returned from the policy server. This decision might be related to admission control, resource allocation, object forwarding and substitution, or configuration.
上下文对象用于确定要在其中解释所有其他对象的上下文。它还用于确定要从策略服务器返回的决策类型。此决策可能与准入控制、资源分配、对象转发和替换或配置有关。
The interface objects are used to determine the corresponding interface on which a signaling protocol message was received or is about to be sent. They are typically used if the client is participating along the path of a signaling protocol or if the client is requesting configuration data for a particular interface.
接口对象用于确定接收或即将发送信令协议消息的对应接口。如果客户机沿着信令协议的路径参与，或者如果客户机请求特定接口的配置数据，则通常使用它们。
ClientSI, the client specific information object, holds the client-type specific data for which a policy decision needs to be made. In the case of configuration, the Named ClientSI may include named information about the module, interface, or functionality to be configured. The ordering of multiple ClientSIs is not important.
ClientSI是特定于客户端的信息对象，它保存特定于客户端类型的数据，需要为这些数据做出策略决策。在配置的情况下，命名客户端si可以包括关于要配置的模块、接口或功能的命名信息。多个客户的排序并不重要。
Finally, LPDPDecision object holds information regarding the local decision made by the LPDP.
最后，LPDPDecision对象保存关于LPDP做出的本地决策的信息。
Malformed Request messages MUST result in the PDP specifying a Decision message with the appropriate error code.
格式错误的请求消息必须导致PDP指定带有适当错误代码的决策消息。
The PDP responds to the REQ with a DEC message that includes the associated client handle and one or more decision objects grouped relative to a Context object and Decision Flags object type pair. If there was a protocol error an error object is returned instead.
PDP使用DEC消息响应REQ，DEC消息包括关联的客户端句柄和一个或多个相对于上下文对象和决策标志对象类型对分组的决策对象。如果存在协议错误，则返回错误对象。
It is required that the first decision message for a new/updated request will have the solicited message flag set (value = 1) in the COPS header. This avoids the issue of keeping track of which updated request (that is, a request reissued for the same handle) a particular decision corresponds. It is important that, for a given handle, there be at most one outstanding solicited decision per request. This essentially means that the PEP SHOULD NOT issue more than one REQ (for a given handle) before it receives a corresponding DEC with the solicited message flag set. The PDP MUST always issue decisions for requests on a particular handle in the order they arrive and all requests MUST have a corresponding decision.
新请求/更新请求的第一条决策消息必须在COPS头中设置请求消息标志（值=1）。这避免了跟踪特定决策对应的更新请求（即，为相同句柄重新发出的请求）的问题。重要的是，对于给定句柄，每个请求最多有一个未完成的请求决策。这本质上意味着PEP在收到带有请求消息标志集的相应DEC之前，不应发出多个REQ（针对给定句柄）。PDP必须始终按照请求到达的顺序对特定句柄上的请求发出决策，并且所有请求必须具有相应的决策。
To avoid deadlock, the PEP can always timeout after issuing a request that does not receive a decision. It MUST then delete the timed-out handle, and may try again using a new handle.
为了避免死锁，PEP总是可以在发出未收到决策的请求后超时。然后它必须删除超时句柄，并可以使用新句柄重试。
The format of the Decision message is as follows:
决定信息的格式如下：
<Decision Message> ::= <Common Header>
<Client Handle>
<Decision(s)> | <Error>
[<Integrity>]
<Decision Message> ::= <Common Header>
<Client Handle>
<Decision(s)> | <Error>
[<Integrity>]
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
<Decision> ::= <Context>
<Decision: Flags>
[<Decision: Stateless Data>]
[<Decision: Replacement Data>]
[<Decision: ClientSI Data>]
[<Decision: Named Data>]
<Decision> ::= <Context>
<Decision: Flags>
[<Decision: Stateless Data>]
[<Decision: Replacement Data>]
[<Decision: ClientSI Data>]
[<Decision: Named Data>]
The Decision message may include either an Error object or one or more context plus associated decision objects. COPS protocol problems are reported in the Error object (e.g. an error with the format of the original request including malformed request messages, unknown COPS objects in the Request, etc.). The applicable Decision object(s) depend on the context and the type of client. The only ordering requirement for decision objects is that the required Decision Flags object type MUST precede the other Decision object types per context binding.
决策消息可以包括错误对象或一个或多个上下文加上关联的决策对象。错误对象中会报告COPS协议问题（例如，原始请求格式错误，包括格式错误的请求消息、请求中未知的COPS对象等）。适用的决策对象取决于上下文和客户端类型。决策对象的唯一排序要求是，每个上下文绑定所需的决策标志对象类型必须先于其他决策对象类型。
The RPT message is used by the PEP to communicate to the PDP its success or failure in carrying out the PDP's decision, or to report an accounting related change in state. The Report-Type specifies the kind of report and the optional ClientSI can carry additional information per Client-Type.
政治公众人物使用RPT消息向PDP传达其执行PDP决策的成功或失败，或报告与会计相关的状态变化。报告类型指定报告的类型，可选的客户端i可以为每种客户端类型提供附加信息。
For every DEC message containing a configuration context that is received by a PEP, the PEP MUST generate a corresponding Report State message with the Solicited Message flag set describing its success or failure in applying the configuration decision. In addition, outsourcing decisions from the PDP MAY result in a corresponding solicited Report State from the PEP depending on the context and the type of client. RPT messages solicited by decisions for a given Client Handle MUST set the Solicited Message flag and MUST be sent in the same order as their corresponding Decision messages were received. There MUST never be more than one Report State message generated with the Solicited Message flag set per Decision.
对于PEP接收到的包含配置上下文的每个DEC消息，PEP必须生成相应的报告状态消息，其中请求消息标志集描述其应用配置决策的成功或失败。此外，PDP的外包决策可能导致政治公众人物根据上下文和客户类型发出相应的征求报告状态。由给定客户端句柄的决策请求的RPT消息必须设置请求消息标志，并且必须按照接收相应决策消息的相同顺序发送。对于每个决策，生成的报告状态消息不得超过一条，并且必须设置请求消息标志。
The Report State may also be used to provide periodic updates of client specific information for accounting and state monitoring purposes depending on the type of the client. In such cases the accounting report type should be specified utilizing the appropriate client specific information object.
根据客户的类型，报告状态还可用于提供客户特定信息的定期更新，以进行会计和状态监控。在这种情况下，应使用适当的客户特定信息对象指定会计报告类型。
<Report State> ::== <Common Header>
<Client Handle>
<Report-Type>
[<ClientSI>]
[<Integrity>]
<Report State> ::== <Common Header>
<Client Handle>
<Report-Type>
[<ClientSI>]
[<Integrity>]
When sent from the PEP this message indicates to the remote PDP that the state identified by the client handle is no longer available/relevant. This information will then be used by the remote PDP to initiate the appropriate housekeeping actions. The reason code object is interpreted with respect to the client-type and signifies the reason for the removal.
从PEP发送时，此消息向远程PDP指示客户端句柄标识的状态不再可用/相关。然后，远程PDP将使用该信息启动适当的内务管理操作。原因码对象根据客户端类型进行解释，并表示删除的原因。
The format of the Delete Request State message is as follows:
删除请求状态消息的格式如下：
<Delete Request> ::= <Common Header>
<Client Handle>
<Reason>
[<Integrity>]
<Delete Request> ::= <Common Header>
<Client Handle>
<Reason>
[<Integrity>]
Given the stateful nature of COPS, it is important that when a request state is finally removed from the PEP, a DRQ message for this request state is sent to the PDP so the corresponding state may likewise be removed on the PDP. Request states not explicitly deleted by the PEP will be maintained by the PDP until either the client session is closed or the connection is terminated.
鉴于COP的状态性质，当请求状态最终从PEP中移除时，将该请求状态的DRQ消息发送给PDP，以便在PDP上移除相应的状态，这一点很重要。未被PEP明确删除的请求状态将由PDP维护，直到客户端会话关闭或连接终止。
Malformed Decision messages MUST trigger a DRQ specifying the appropriate erroneous reason code (Bad Message Format) and any associated state on the PEP SHOULD either be removed or re-requested. If a Decision contained an unknown COPS Decision Object, the PEP MUST delete its request specifying the Unknown COPS Object reason code because the PEP will be unable to comply with the information contained in the unknown object. In any case, after issuing a DRQ, the PEP may retry the corresponding Request again.
格式错误的决策消息必须触发DRQ，指定适当的错误原因代码（错误消息格式），并且应删除或重新请求PEP上的任何关联状态。如果决策包含未知的COPS决策对象，政治公众人物必须删除其指定未知COPS对象原因代码的请求，因为政治公众人物将无法遵守未知对象中包含的信息。在任何情况下，在发出DRQ后，PEP可以再次重试相应的请求。
The format of the Synchronize State Query message is as follows:
同步状态查询消息的格式如下：
<Synchronize State> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
<Synchronize State> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
This message indicates that the remote PDP wishes the client (which appears in the common header) to re-send its state. If the optional Client Handle is present, only the state associated with this handle is synchronized. If the PEP does not recognize the requested handle, it MUST immediately send a DRQ message to the PDP for the handle that was specified in the SSQ message. If no handle is specified in the SSQ message, all the active client state MUST be synchronized with the PDP.
此消息表示远程PDP希望客户端（出现在公共标头中）重新发送其状态。如果存在可选的客户端句柄，则仅同步与此句柄关联的状态。如果PEP无法识别请求的句柄，则必须立即向PDP发送SSQ消息中指定句柄的DRQ消息。如果SSQ消息中未指定句柄，则所有活动客户端状态必须与PDP同步。
The client performs state synchronization by re-issuing request queries of the specified client-type for the existing state in the PEP. When synchronization is complete, the PEP MUST issue a synchronize state complete message to the PDP.
客户端通过为PEP中的现有状态重新发出指定客户端类型的请求查询来执行状态同步。同步完成后，PEP必须向PDP发出同步状态完成消息。
The Client-Open message can be used by the PEP to specify to the PDP the client-types the PEP can support, the last PDP to which the PEP connected for the given client-type, and/or client specific feature negotiation. A Client-Open message can be sent to the PDP at any time and multiple Client-Open messages for the same client-type are allowed (in case of global state changes).
PEP可使用客户端打开消息向PDP指定PEP可支持的客户端类型、PEP为给定客户端类型连接的最后一个PDP和/或特定于客户端的功能协商。可以随时向PDP发送客户端打开消息，并且允许同一客户端类型的多个客户端打开消息（在全局状态更改的情况下）。
<Client-Open> ::= <Common Header>
<PEPID>
[<ClientSI>]
[<LastPDPAddr>]
[<Integrity>]
<Client-Open> ::= <Common Header>
<PEPID>
[<ClientSI>]
[<LastPDPAddr>]
[<Integrity>]
The PEPID is a symbolic, variable length name that uniquely identifies the specific client to the PDP (see Section 2.2.11).
PEPID是一个符号化、可变长度的名称，用于唯一标识PDP的特定客户机（见第2.2.11节）。
A named ClientSI object can be included for relaying additional global information about the PEP to the PDP when required (as specified in the appropriate extensions document for the client-type).
可以包括一个命名的ClientSI对象，用于在需要时将有关PEP的其他全局信息转发给PDP（如客户机类型的相应扩展文档中所指定）。
The PEP may also provide a Last PDP Address object in its Client-Open message specifying the last PDP (for the given client-type) for which it is still caching decisions since its last reboot. A PDP can use this information to determine the appropriate synchronization behavior (See section 2.5).
PEP还可以在其客户机打开消息中提供最后一个PDP地址对象，指定自上次重新启动以来它仍在缓存决策的最后一个PDP（对于给定的客户机类型）。PDP可使用该信息确定适当的同步行为（见第2.5节）。
If the PDP receives a malformed Client-Open message it MUST generate a Client-Close message specifying the appropriate error code.
如果PDP接收到格式错误的客户端打开消息，则必须生成客户端关闭消息，指定适当的错误代码。
The Client-Accept message is used to positively respond to the Client-Open message. This message will return to the PEP a timer object indicating the maximum time interval between keep-alive messages. Optionally, a timer specifying the minimum allowed interval between accounting report messages may be included when applicable.
客户端接受消息用于积极响应客户端打开消息。此消息将向PEP返回一个计时器对象，指示保持活动消息之间的最大时间间隔。或者，如果适用，可以包括指定会计报告消息之间允许的最小间隔的计时器。
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity>]
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity>]
If the PDP refuses the client, it will instead issue a Client-Close message.
如果PDP拒绝客户端，它将发出客户端关闭消息。
The KA Timer corresponds to maximum acceptable intermediate time between the generation of messages by the PDP and PEP. The timer value is determined by the PDP and is specified in seconds. A timer value of 0 implies no secondary connection verification is necessary.
KA定时器对应于PDP和PEP生成消息之间的最大可接受中间时间。计时器值由PDP确定，并以秒为单位指定。计时器值为0表示无需进行辅助连接验证。
The optional ACCT Timer allows the PDP to indicate to the PEP that periodic accounting reports SHOULD NOT exceed the specified timer interval per client handle. This allows the PDP to control the rate at which accounting reports are sent by the PEP (when applicable).
可选的ACCT定时器允许PDP向PEP指示定期会计报告不应超过每个客户端句柄指定的定时器间隔。这允许PDP控制政治公众人物发送会计报告的速率（如适用）。
In general, accounting type Report messages are sent to the PDP when determined appropriate by the PEP. The accounting timer merely is used by the PDP to keep the rate of such updates in check (i.e. Preventing the PEP from blasting the PDP with accounting reports). Not including this object implies there are no PDP restrictions on the rate at which accounting updates are generated.
通常，当政治公众人物确定适当时，会计类型报告消息会发送至PDP。PDP仅使用记帐计时器来检查此类更新的速率（即防止政治公众人物向PDP发送记帐报告）。不包括此对象意味着对生成记帐更新的速率没有PDP限制。
If the PEP receives a malformed Client-Accept message it MUST generate a Client-Close message specifying the appropriate error code.
如果PEP收到格式错误的客户端接受消息，则必须生成客户端关闭消息，并指定相应的错误代码。
The Client-Close message can be issued by either the PDP or PEP to notify the other that a particular type of client is no longer being supported.
PDP或PEP均可发出客户机关闭消息，通知另一方不再支持特定类型的客户机。
<Client-Close> ::= <Common Header>
<Error>
[<PDPRedirAddr>]
[<Integrity>]
<Client-Close> ::= <Common Header>
<Error>
[<PDPRedirAddr>]
[<Integrity>]
The Error object is included to describe the reason for the close (e.g. the requested client-type is not supported by the remote PDP or client failure).
错误对象用于描述关闭的原因（例如，远程PDP不支持请求的客户端类型或客户端故障）。
A PDP MAY optionally include a PDP Redirect Address object in order to inform the PEP of the alternate PDP it SHOULD use for the client-type specified in the common header.
PDP可选择性地包括PDP重定向地址对象，以便通知PEP其应用于公共报头中指定的客户端类型的备用PDP。
The keep-alive message MUST be transmitted by the PEP within the period defined by the minimum of all KA Timer values specified in all received CAT messages for the connection. A KA message MUST be generated randomly between 1/4 and 3/4 of this minimum KA timer interval. When the PDP receives a keep-alive message from a PEP, it MUST echo a keep-alive back to the PEP. This message provides validation for each side that the connection is still functioning even when there is no other messaging.
PEP必须在所有接收到的CAT连接消息中指定的所有KA定时器值的最小值所定义的时间内发送保持活动消息。必须在此最小KA定时器间隔的1/4和3/4之间随机生成KA消息。当PDP从PEP接收到保持活动消息时，必须将保持活动消息回显给PEP。此消息为每一方验证连接是否仍在运行，即使没有其他消息。
Note: The client-type in the header MUST always be set to 0 as the KA is used for connection verification (not per client session verification).
注意：标头中的客户端类型必须始终设置为0，因为KA用于连接验证（而不是每个客户端会话验证）。
<Keep-Alive> ::= <Common Header>
[<Integrity>]
<Keep-Alive> ::= <Common Header>
[<Integrity>]
Both client and server MAY assume the TCP connection is insufficient for the client-type with the minimum time value (specified in the CAT message) if no communication activity is detected for a period exceeding the timer period. For the PEP, such detection implies the remote PDP or connection is down and the PEP SHOULD now attempt to use an alternative/backup PDP.
如果在超过计时器周期的时间段内未检测到任何通信活动，则客户端和服务器都可能认为TCP连接不足以满足具有最小时间值（在CAT消息中指定）的客户端类型。对于政治公众人物，此类检测意味着远程PDP或连接已关闭，政治公众人物现在应尝试使用备用/备用PDP。
The Synchronize State Complete is sent by the PEP to the PDP after the PDP sends a synchronize state request to the PEP and the PEP has finished synchronization. It is useful so that the PDP will know when all the old client state has been successfully re-requested and, thus, the PEP and PDP are completely synchronized. The Client Handle object only needs to be included if the corresponding Synchronize State Message originally referenced a specific handle.
在PDP向PEP发送同步状态请求且PEP已完成同步后，PEP将同步状态完成发送给PDP。它非常有用，这样PDP将知道何时成功地重新请求了所有旧客户端状态，从而使PEP和PDP完全同步。仅当相应的同步状态消息最初引用了特定句柄时，才需要包含客户端句柄对象。
<Synchronize State Complete> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
<Synchronize State Complete> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
This section describes the typical exchanges between remote PDP servers and PEP clients.
本节介绍远程PDP服务器和PEP客户端之间的典型交换。
COPS message security is negotiated once per connection and covers all communication over a particular connection. If COPS level security is required, it MUST be negotiated during the initial Client-Open/Client-Accept message exchange specifying a Client-Type of zero (which is reserved for connection level security negotiation and connection verification).
COPS消息安全性在每个连接上协商一次，并覆盖特定连接上的所有通信。如果需要COPS级别的安全性，则必须在初始客户端打开/客户端接受消息交换期间协商，指定客户端类型为零（保留用于连接级别安全协商和连接验证）。
If a PEP is not configured to use COPS security with a PDP it will simply send the PDP Client-Open messages for the supported Client-Types as specified in section 4.3 and will not include the Integrity object in any COPS messages.
如果PEP未配置为对PDP使用COPS安全性，则其将仅发送第4.3节中规定的受支持客户端类型的PDP客户端打开消息，并且不会在任何COPS消息中包含完整性对象。
Otherwise, security can be initiated by the PEP if it sends the PDP a Client-Open message with Client-Type=0 before opening any other Client-Type. If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. This first Client-Open message MUST specify a Client-Type of zero and MUST provide the PEPID and a COPS Integrity object. This Integrity object will contain the initial sequence number the PEP requires the
否则，如果PEP在打开任何其他客户机类型之前向PDP发送客户机类型为0的客户机打开消息，则可以启动安全性。如果PDP在另一个客户机类型成功打开后接收到客户机类型为0的客户机打开，则必须向该PEP返回客户机关闭消息（对于客户机类型为0）。此第一条客户端打开消息必须指定零客户端类型，并且必须提供PEPID和COPS完整性对象。此完整性对象将包含PEP需要的初始序列号
PDP to increment during subsequent communication after the initial Client-Open/Client-Accept exchange and the Key ID identifying the algorithm and key used to compute the digest.
PDP在初始客户端打开/客户端接受交换和密钥ID（标识用于计算摘要的算法和密钥）之后的后续通信期间递增。
Similarly, if the PDP accepts the PEP's security key and algorithm by validating the message digest using the identified key, the PDP MUST send a Client-Accept message with a Client-Type of zero to the PEP carrying an Integrity object. This Integrity object will contain the initial sequence number the PDP requires the PEP to increment during all subsequent communication with the PDP and the Key ID identifying the key and algorithm used to compute the digest.
类似地，如果PDP通过使用标识的密钥验证消息摘要来接受PEP的安全密钥和算法，则PDP必须向携带完整性对象的PEP发送客户端类型为零的客户端接受消息。该完整性对象将包含PDP要求PEP在与PDP的所有后续通信期间增加的初始序列号，以及标识密钥的密钥ID和用于计算摘要的算法。
If the PEP, from the perspective of a PDP that requires security, fails or never performs the security negotiation by not sending an initial Client-Open message with a Client-Type=0 including a valid Integrity object, the PDP MUST send to the PEP a Client-Close message with a Client-Type=0 specifying the appropriate error code. Similarly, if the PDP, from the perspective of a PEP that requires security, fails the security negotiation by not sending back a Client-Accept message with a Client-Type=0 including a valid Integrity object, the PEP MUST send to the PDP a Client-Close message with a Client-Type=0 specifying the appropriate error code. Such a Client-Close message need not carry an integrity object (as the security negotiation did not yet complete).
如果从需要安全性的PDP的角度来看，政治公众人物未能或从未通过不发送包含有效完整性对象的客户端类型为0的初始客户端打开消息来执行安全协商，则政治公众人物必须向政治公众人物发送客户端关闭消息，客户端类型为0，并指定相应的错误代码。类似地，如果从需要安全性的PEP的角度来看，PDP未发送回包含有效完整性对象的客户端类型为0的客户端接受消息，导致安全协商失败，则PEP必须向PDP发送客户端类型为0的客户端关闭消息，并指定适当的错误代码。这样的客户端关闭消息不需要携带完整性对象（因为安全协商尚未完成）。
The security initialization can fail for one of several reasons: 1. The side receiving the message requires COPS level security but an Integrity object was not provided (Authentication Required error code). 2. A COPS Integrity object was provided, but with an unknown/unacceptable C-Type (Unknown COPS Object error code specifying the unsupported C-Num and C-Type). 3. The message digest or Key ID in the provided Integrity object was incorrect and therefore the message could not be authenticated using the identified key (Authentication Failure error code).
安全初始化可能由于以下原因之一而失败：1。接收消息的一方需要COPS级别的安全性，但未提供完整性对象（需要身份验证的错误代码）。2.提供了一个COPS完整性对象，但C类型未知/不可接受（未知COPS对象错误代码指定了不支持的C-Num和C-Type）。3.提供的完整性对象中的消息摘要或密钥ID不正确，因此无法使用标识的密钥对消息进行身份验证（身份验证失败错误代码）。
Once the initial security negotiation is complete, the PEP will know what sequence numbers the PDP expects and the PDP will know what sequence numbers the PEP expects. ALL COPS messages must then include the negotiated Integrity object specifying the correct sequence number with the appropriate message digest (including the Client-Open/Client-Accept messages for specific Client-Types). ALL subsequent messages from the PDP to the PEP MUST result in an increment of the sequence number provided by the PEP in the Integrity object of the initial Client-Open message. Likewise, ALL subsequent messages from the PEP to the PDP MUST result in an increment of the sequence number provided by the PDP in the Integrity object of the initial Client-Accept message. Sequence numbers are incremented by one starting with the corresponding initial sequence number. For
一旦初始安全协商完成，政治公众人物将知道PDP期望的序列号，PDP将知道政治公众人物期望的序列号。然后，所有COPS消息必须包含协商完整性对象，指定正确的序列号和适当的消息摘要（包括特定客户端类型的客户端打开/客户端接受消息）。从PDP到PEP的所有后续消息必须导致PEP在初始客户端打开消息的完整性对象中提供的序列号增加。同样，从PEP到PDP的所有后续消息必须导致PDP在初始客户端接受消息的完整性对象中提供的序列号增加。序列号从相应的初始序列号开始递增一。对于
example, if the sequence number specified to the PEP by the PDP in the initial Client-Accept was 10, the next message the PEP sends to the PDP will provide an Integrity object with a sequence number of 11... Then the next message the PEP sends to the PDP will have a sequence number of 12 and so on. If any subsequent received message contains the wrong sequence number, an unknown Key ID, an invalid message digest, or is missing an Integrity object after integrity was negotiated, then a Client-Close message MUST be generated for the Client-Type zero containing a valid Integrity object and specifying the appropriate error code. The connection should then be dropped.
例如，如果PDP在初始客户端接受中指定给PEP的序列号为10，则PEP发送给PDP的下一条消息将提供序列号为11的完整性对象。。。然后，PEP发送给PDP的下一条消息的序列号为12，依此类推。如果任何后续接收到的消息包含错误的序列号、未知的密钥ID、无效的消息摘要，或者在协商完整性后缺少完整性对象，则必须为客户端类型0生成客户端关闭消息，其中包含有效的完整性对象并指定适当的错误代码。然后应断开连接。
Key maintenance is outside the scope of this document, but COPS implementations MUST at least provide the ability to manually configure keys and their parameters locally. The key used to produce the Integrity object's message digest is identified by the Key ID field. Thus, a Key ID parameter is used to identify one of potentially multiple simultaneous keys shared by the PEP and PDP. A Key ID is relative to a particular PEPID on the PDP or to a particular PDP on the PEP. Each key must also be configured with lifetime parameters for the time period within which it is valid as well as an associated cryptographic algorithm parameter specifying the algorithm to be used with the key. At a minimum, all COPS implementations MUST support the HMAC-MD5-96 [HMAC][MD5] cryptographic algorithm for computing a message digest for inclusion in the Keyed Message Digest of the Integrity object which is appended to the message.
密钥维护不在本文档的范围内，但COPS实现必须至少提供在本地手动配置密钥及其参数的能力。用于生成完整性对象的消息摘要的密钥由密钥ID字段标识。因此，密钥ID参数用于识别由PEP和PDP共享的潜在多个同时密钥中的一个。密钥ID相对于PDP上的特定PEPID或PEP上的特定PDP。每个密钥还必须配置有效时间段的生存期参数，以及指定要与密钥一起使用的算法的相关加密算法参数。至少，所有COPS实现必须支持HMAC-MD5-96[HMAC][MD5]加密算法，用于计算消息摘要，以包含在附加到消息的完整性对象的密钥消息摘要中。
It is good practice to regularly change keys. Keys MUST be configurable such that their lifetimes overlap allowing smooth transitions between keys. At the midpoint of the lifetime overlap between two keys, senders should transition from using the current key to the next/longer-lived key. Meanwhile, receivers simply accept any identified key received within its configured lifetime and reject those that are not.
定期更换钥匙是一种很好的做法。关键点必须是可配置的，以便它们的生命周期重叠，从而允许关键点之间的平滑过渡。在两个密钥的生命周期重叠的中点，发送者应该从使用当前密钥过渡到下一个/寿命更长的密钥。同时，接收器只接受在其配置的生命周期内接收到的任何已识别密钥，并拒绝未识别的密钥。
Sometime after a connection is established between the PEP and a remote PDP and after security is negotiated (if required), the PEP will send one or more Client-Open messages to the remote PDP, one for each client-type supported by the PEP. The Client-Open message MUST contain the address of the last PDP with which the PEP is still caching a complete set of decisions. If no decisions are being cached from the previous PDP the LastPDPAddr object MUST NOT be included in the Client-Open message (see Section 2.5). Each Client-Open message MUST at least contain the common header noting one client-type
在PEP和远程PDP之间建立连接并协商安全性（如果需要）后，PEP将向远程PDP发送一个或多个客户端打开消息，PEP支持的每种客户端类型一个。客户端打开消息必须包含上一个PDP的地址，PEP仍在使用该地址缓存一整套决策。如果未缓存来自上一个PDP的任何决策，则客户端打开消息中不得包含LastPDPAddr对象（参见第2.5节）。每个客户端打开消息必须至少包含一个公共头，并注明一种客户端类型
supported by the PEP. The remote PDP will then respond with separate Client-Accept messages for each of the client-types requested by the PEP that the PDP can also support.
得到政治公众人物的支持。然后，远程PDP将针对PDP也可以支持的PEP请求的每种客户端类型，使用单独的客户端接受消息进行响应。
If a specific client-type is not supported by the PDP, the PDP will instead respond with a Client-Close specifying the client-type is not supported and will possibly suggest an alternate PDP address and port. Otherwise, the PDP will send a Client-Accept specifying the timer interval between keep-alive messages and the PEP may begin issuing requests to the PDP.
如果PDP不支持特定的客户机类型，PDP将改为响应客户机关闭，指定不支持的客户机类型，并可能建议备用PDP地址和端口。否则，PDP将发送一个客户端接受，指定保持活动消息之间的计时器间隔，PEP可开始向PDP发出请求。
In the outsourcing scenario, when the PEP receives an event that requires a new policy decision it sends a request message to the remote PDP. What specifically qualifies as an event for a particular client-type SHOULD be specified in the specific document for that client-type. The remote PDP then makes a decision and sends a decision message back to the PEP. Since the request is stateful, the request will be remembered, or installed, on the remote PDP. The unique handle (unique per TCP connection and client-type), specified in both the request and its corresponding decision identifies this request state. The PEP is responsible for deleting this request state once the request is no longer applicable.
在外包场景中，当PEP接收到需要新策略决策的事件时，它会向远程PDP发送请求消息。对于特定的客户机类型，应在该客户机类型的特定文档中指定具体限定为事件的内容。然后，远程PDP做出决策并将决策消息发送回PEP。由于请求是有状态的，因此将在远程PDP上记住或安装该请求。在请求及其相应决策中指定的唯一句柄（每个TCP连接和客户端类型都是唯一的）标识此请求状态。一旦请求不再适用，政治公众人物负责删除该请求状态。
The PEP can update a previously installed request state by reissuing a request for the previously installed handle. The remote PDP is then expected to make new decisions and send a decision message back to the PEP. Likewise, the server MAY change a previously issued decision on any currently installed request state at any time by issuing an unsolicited decision message. At all times the PEP module is expected to abide by the PDP's decisions and notify the PDP of any state changes.
PEP可以通过重新发出对先前安装的句柄的请求来更新先前安装的请求状态。然后，远程PDP将做出新的决策，并将决策消息发送回PEP。类似地，服务器可以随时通过发出未经请求的决定消息来更改先前发布的关于任何当前安装的请求状态的决定。PEP模块应始终遵守PDP的决定，并将任何状态变化通知PDP。
In the configuration scenario, as in the outsourcing scenario, the PEP will make a configuration request to the PDP for a particular interface, module, or functionality that may be specified in the named client specific information object. The PDP will then send potentially several decisions containing named units of configuration data to the PEP. The PEP is expected to install and use the configuration locally. A particular named configuration can be updated by simply sending additional decision messages for the same named configuration. When the PDP no longer wishes the PEP to use a piece of configuration information, it will send a decision message specifying the named configuration and a decision flags object with
在配置场景中，与外包场景中一样，PEP将向PDP发出特定接口、模块或功能的配置请求，这些接口、模块或功能可能在指定的客户特定信息对象中指定。然后，PDP将可能向PEP发送包含命名配置数据单元的多个决策。PEP应在本地安装和使用该配置。只需发送相同命名配置的附加决策消息，即可更新特定命名配置。当PDP不再希望PEP使用一段配置信息时，它将发送一条决策消息，指定指定的配置和带有对象的决策标志
the remove configuration command. The PEP SHOULD then proceed to remove the corresponding configuration and send a report message to the PDP that specifies it has been deleted.
删除配置命令。然后，PEP应继续删除相应的配置，并向PDP发送一条报告消息，指定该配置已被删除。
In all cases, the PEP MAY notify the remote PDP of the local status of an installed state using the report message where appropriate. The report message is to be used to signify when billing can begin, what actions were taken, or to produce periodic updates for monitoring and accounting purposes depending on the client. This message can carry client specific information when needed.
在所有情况下，PEP可在适当情况下使用报告消息通知远程PDP安装状态的本地状态。报告消息用于表示何时可以开始计费、采取了哪些措施，或根据客户的情况定期更新以进行监控和核算。此消息可在需要时携带特定于客户端的信息。
The Keep-Alive message is used to validate the connection between the client and server is still functioning even when there is no other messaging from the PEP to PDP. The PEP MUST generate a COPS KA message randomly within one-fourth to three-fourths the minimum KA Timer interval specified by the PDP in the Client-Accept message. On receiving a Keep-Alive message from the PEP, the PDP MUST then respond to this Keep-Alive message by echoing a Keep-Alive message back to the PEP. If either side does not receive a Keep-Alive or any other COPS message within the minimum KA Timer interval from the other, the connection SHOULD be considered lost.
Keep Alive消息用于验证客户端和服务器之间的连接是否仍在运行，即使PEP与PDP之间没有其他消息。PEP必须在PDP在客户端接受消息中指定的最小KA定时器间隔的四分之一到四分之三内随机生成COPS KA消息。收到PEP发出的保持活动消息后，PDP必须通过将保持活动消息回显给PEP来响应该保持活动消息。如果任何一方在最小KA定时器间隔内未从另一方接收到保持活动或任何其他COPS消息，则应认为连接已断开。
Finally, Client-Close messages are used to negate the effects of the corresponding Client-Open messages, notifying the other side that the specified client-type is no longer supported/active. When the PEP detects a lost connection due to a keep-alive timeout condition it SHOULD explicitly send a Client-Close message for each opened client-type specifying a communications failure error code. Then the PEP MAY proceed to terminate the connection to the PDP and attempt to reconnect again or try a backup/alternative PDP. When the PDP is shutting down, it SHOULD also explicitly send a Client-Close to all connected PEPs for each client-type, perhaps specifying an alternative PDP to use instead.
最后，客户端关闭消息用于消除相应客户端打开消息的影响，通知另一方指定的客户端类型不再受支持/活动。当PEP检测到由于保持活动超时条件导致的连接丢失时，它应该为每个打开的客户端类型显式发送一条客户端关闭消息，指定通信故障错误代码。然后，PEP可继续终止与PDP的连接，并尝试再次重新连接或尝试备份/备用PDP。当PDP关闭时，它还应该显式地向每个客户端类型的所有连接的PEP发送一个客户端，可能指定一个替代PDP来代替。
The COPS protocol provides an Integrity object that can achieve authentication, message integrity, and replay prevention. All COPS implementations MUST support the COPS Integrity object and its mechanisms as described in this document. To ensure the client (PEP) is communicating with the correct policy server (PDP) requires authentication of the PEP and PDP using a shared secret, and consistent proof that the connection remains valid. The shared secret minimally requires manual configuration of keys (identified by a Key
COPS协议提供了一个完整性对象，可以实现身份验证、消息完整性和重播预防。所有COPS实现必须支持本文档中描述的COPS完整性对象及其机制。为确保客户端（PEP）与正确的策略服务器（PDP）通信，需要使用共享密钥对PEP和PDP进行身份验证，并一致证明连接仍然有效。共享秘密最少需要手动配置密钥（由密钥标识）
ID) shared between the PEP and its PDP. The key is used in conjunction with the contents of a COPS message to calculate a message digest that is part of the Integrity object. The Integrity object is then used to validate all COPS messages sent over the TCP connection between a PEP and PDP.
ID）在政治公众人物及其PDP之间共享。密钥与COPS消息的内容结合使用，以计算作为Integrity对象一部分的消息摘要。然后，Integrity对象用于验证通过PEP和PDP之间的TCP连接发送的所有COPS消息。
Key maintenance is outside the scope of this document beyond the specific requirements discussed in section 4.2. In general, it is good practice to regularly change keys to maintain security. Furthermore, it is good practice to use localized keys specific to a particular PEP such that a stolen PEP will not compromise the security of an entire administrative domain.
关键维护超出了本文件的范围，超出了第4.2节讨论的具体要求。一般来说，定期更换密钥以维护安全性是一种良好的做法。此外，使用特定PEP的本地化密钥是一种良好做法，这样被盗的PEP就不会危及整个管理域的安全。
The COPS Integrity object also provides sequence numbers to avoid replay attacks. The PDP chooses the initial sequence number for the PEP and the PEP chooses the initial sequence number for the PDP. These initial numbers are then incremented with each successive message sent over the connection in the corresponding direction. The initial sequence numbers SHOULD be chosen such that they are monotonically increasing and never repeat for a particular key.
COPS Integrity对象还提供序列号以避免重播攻击。PDP为PEP选择初始序列号，PEP为PDP选择初始序列号。然后，这些初始数字随着通过连接在相应方向上发送的每个连续消息而递增。初始序列号的选择应确保它们是单调递增的，并且对于特定的键不会重复。
Security between the client (PEP) and server (PDP) MAY be provided by IP Security [IPSEC]. In this case, the IPSEC Authentication Header (AH) SHOULD be used for the validation of the connection; additionally IPSEC Encapsulation Security Payload (ESP) MAY be used to provide both validation and secrecy.
客户端（PEP）和服务器（PDP）之间的安全性可由IP安全[IPSEC]提供。在这种情况下，应该使用IPSEC身份验证头（AH）来验证连接；此外，IPSEC封装安全负载（ESP）可用于提供验证和保密性。
Transport Layer Security [TLS] MAY be used for both connection-level validation and privacy.
传输层安全[TLS]可用于连接级别验证和隐私。
The Client-type identifies the policy client application to which a message refers. Client-type values within the range 0x0001-0x3FFF are reserved Specification Required status as defined in [IANA-CONSIDERATIONS]. These values MUST be registered with IANA and their behavior and applicability MUST be described in a COPS extension document.
客户端类型标识消息引用的策略客户端应用程序。0x0001-0x3FFF范围内的客户机类型值是[IANA-注意事项]中定义的保留规范要求状态。这些值必须向IANA注册，其行为和适用性必须在COPS扩展文档中描述。
Client-type values in the range 0x4000 - 0x7FFF are reserved for Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types are not tracked by IANA and are not to be used in standards or general-release products, as their uniqueness cannot be assured.
0x4000-0x7FFF范围内的客户机类型值保留供私人使用，如[IANA-注意事项]中所定义。IANA不跟踪这些客户机类型，也不在标准或通用发布产品中使用，因为无法确保其唯一性。
Client-type values in the range 0x8000 - 0xFFFF are First Come First Served as defined in [IANA-CONSIDERATIONS]. These Client-types are tracked by IANA but do not require published documents describing their use. IANA merely assures their uniqueness.
0x8000-0xFFFF范围内的客户机类型值按照[IANA-注意事项]中的定义先到先得。这些客户端类型由IANA跟踪，但不要求发布描述其使用的文档。IANA仅仅保证了它们的独特性。
Objects in the COPS Protocol are identified by their C-Num and C-Type values. IETF Consensus as identified in [IANA-CONSIDERATIONS] is required to introduce new values for these numbers and, therefore, new objects into the base COPS protocol.
COPS协议中的对象由其C-Num和C-Type值标识。需要[IANA-注意事项]中确定的IETF共识，为这些数字引入新值，从而将新对象引入基本COPS协议。
Additional Context Object R-Types, Reason-Codes, Report-Types, Decision Object Command-Codes/Flags, and Error-Codes MAY be defined for use with future Client-types, but such additions require IETF Consensus as defined in [IANA-CONSIDERATIONS].
可以定义其他上下文对象R类型、原因代码、报告类型、决策对象命令代码/标志和错误代码，以用于未来的客户机类型，但此类添加需要符合[IANA-注意事项]中定义的IETF共识。
Context Object M-Types, Reason Sub-Codes, and Error Sub-codes MAY be defined relative to a particular Client-type following the same IANA considerations as their respective Client-type.
上下文对象M类型、原因子代码和错误子代码可以相对于特定的客户机类型进行定义，遵循与各自客户机类型相同的IANA注意事项。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）第1版-功能规范”，RFC 22052997年9月。
[WRK] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC 2753, January 2000.
[WRK]Yavatkar，R.，Pendarakis，D.和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[SRVLOC] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol , Version 2", RFC 2608, June 1999.
[SRVLOC]Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[INSCH] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
[INSCH]Shenker，S.和J.Wroclawski，“综合业务网元的一般特征参数”，RFC 2215，1997年9月。
[IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, August 1995.
[IPSEC]Atkinson，R.，“互联网协议的安全架构”，RFC 2401，1995年8月。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[RSVPPR] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC 2209, September 1997.
[RSVPPR]Braden，R.和L.Zhang，“资源预留协议（RSVP）-第1版消息处理规则”，RFC 2209，1997年9月。
[TLS] Dierks T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[IANA] http://www.isi.edu/in-
notes/iana/assignments/port-numbers
[IANA] http://www.isi.edu/in-
notes/iana/assignments/port-numbers
[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月。
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable contributions.
特别感谢Andrew Smith和Timothy O'Malley我们的工作组主席Raj Yavatkar、Russell Fenger、Fred Baker、Laura Cunningham、Roch Guerin、Ping Pan和Dimitrios Pendarakis的宝贵贡献。
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
Phone: +972.9.9700064
EMail: 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 Shannon Laboratory 180 Park Avenue P.O. Box 971 Florham Park, NJ 07932-0971
Raju Rajan AT&T香农实验室新泽西州弗洛勒姆公园公园公园大道180号邮政信箱971号07932-0971
EMail: rajan@research.att.com
EMail: rajan@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
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编辑功能的资金目前由互联网协会提供。