As per Relevance of the word decision, we have this rfc below:
Network Working Group D. Durham, Ed
Request for Comments: 2748
Category: Standards Track J.
Level 3
R.
S.
R.
AT&
A.
January 2000
The COPS (Common Open Policy Service)
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
Conventions used in this
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC-2119].
This document describes a simple client/server model for
policy control over QoS signaling protocols. The model does not
any assumptions about the methods of the policy server, but is
on the server returning decisions to policy requests. The model
designed to be extensible so that other kinds of policy clients
be supported in the future. However, this document makes no
that it is the only or the preferred approach for enforcing
types of policies
Durham, et al. Standards Track [Page 1]
RFC 2748 COPS January 2000
Table Of
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
Durham, et al. Standards Track [Page 2]
RFC 2748 COPS January 2000
7. References.....................................................35
8. Author Information and Acknowledgments.........................36
9. Full Copyright Statement.......................................38
1.
This document describes a simple query and response protocol that
be used to exchange policy information between a policy
(Policy Decision Point or PDP) and its clients (Policy
Points or PEPs). One example of a policy client is an RSVP
that must exercise policy-based admission control over RSVP
[RSVP]. We assume that at least one policy server exists in
controlled administrative domain. The basic model of
between a policy server and its clients is compatible with
framework document for policy based admission control [WRK].
A chief objective of this policy control protocol is to begin with
simple but extensible design. The main characteristics of the
protocol include
1. The protocol employs a client/server model where the PEP
requests, updates, and deletes to the remote PDP and the
returns decisions back to the PEP
2. The protocol uses TCP as its transport protocol for
exchange of messages between policy clients and a server
Therefore, no additional mechanisms are necessary for
communication between a server and its clients
3. The protocol is extensible in that it is designed to
off self-identifying objects and can support diverse
specific information without requiring modifications to
COPS protocol itself. The protocol was created for the
administration, configuration, and enforcement of policies
4. COPS provides message level security for authentication,
protection, and message integrity. COPS can also reuse
protocols for security such as IPSEC [IPSEC] or TLS
authenticate and secure the channel between the PEP and
PDP
5. The protocol is stateful in two main aspects: (1)
Request/Decision state is shared between client and server
(2) State from various events (Request/Decision pairs) may
inter-associated. By (1) we mean that requests from the
PEP are installed or remembered by the remote PDP until
are explicitly deleted by the PEP. At the same time,
from the remote PDP can be generated asynchronously at any
Durham, et al. Standards Track [Page 3]
RFC 2748 COPS January 2000
for a currently installed request state. By (2) we mean
the server may respond to new queries differently because
previously installed Request/Decision state(s) that
related
6. Additionally, the protocol is stateful in that it allows
server to push configuration information to the client,
then allows the server to remove such state from the
when it is no longer applicable
1.1 Basic
+----------------+
| |
| Network Node | Policy
| |
| +-----+ | COPS +-----+
| | PEP |<-----|-------------->| PDP |
| +-----+ | +-----+
| ^ |
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
Figure 1: A COPS illustration
Figure 1 Illustrates the layout of various policy components in
typical COPS example (taken from [WRK]). Here, COPS is used
communicate policy information between a Policy Enforcement
(PEP) and a remote Policy Decision Point (PDP) within the context
a particular type of client. The optional Local Policy Decision
(LPDP) can be used by the device to make local policy decisions
the absence of a PDP
It is assumed that each participating policy client is
consistent with a PEP [WRK]. The PEP may communicate with a
server (herein referred to as a remote PDP [WRK]) to obtain
decisions or directives
The PEP is responsible for initiating a persistent TCP connection
a PDP. The PEP uses this TCP connection to send requests to
receive decisions from the remote PDP. Communication between the
and remote PDP is mainly in the form of a stateful request/
exchange, though the remote PDP may occasionally send
Durham, et al. Standards Track [Page 4]
RFC 2748 COPS January 2000
decisions to the PEP to force changes in previously approved
states. The PEP also has the capacity to report to the remote
that it has successfully completed performing the PDP's
locally, useful for accounting and monitoring purposes. The PEP
responsible for notifying the PDP when a request state has changed
the PEP. Finally, the PEP is responsible for the deletion of
state that is no longer applicable due to events at the client
decisions issued by the server
When the PEP sends a configuration request, it expects the PDP
continuously send named units of configuration data to the PEP
decision messages as applicable for the configuration request. When
unit of named configuration data is successfully installed on
PEP, the PEP should send a report message to the PDP confirming
installation. The server may then update or remove the
configuration information via a new decision message. When the
sends a decision to remove named configuration data from the PEP,
PEP will delete the specified configuration and send a report
to the PDP as confirmation
The policy protocol is designed to communicate self-
objects which contain the data necessary for identifying
states, establishing the context for a request, identifying the
of request, referencing previously installed requests,
policy decisions, reporting errors, providing message integrity,
transferring client specific/namespace information
To distinguish between different kinds of clients, the type of
is identified in each message. Different types of clients may
different client specific data and may require different kinds
policy decisions. It is expected that each new client-type will
a corresponding usage draft specifying the specifics of
interaction with this policy protocol
The context of each request corresponds to the type of event
triggered it. The COPS Context object identifies the type of
and message (if applicable) that triggered a policy event via
message type and request type fields. COPS identifies three types
outsourcing events: (1) the arrival of an incoming message (2)
allocation of local resources, and (3) the forwarding of an
message. Each of these events may require different decisions to
made. The content of a COPS request/decision message depends on
context. A fourth type of request is useful for types of clients
wish to receive configuration information from the PDP. This allows
PEP to issue a configuration request for a specific named device
module that requires configuration information to be installed
Durham, et al. Standards Track [Page 5]
RFC 2748 COPS January 2000
The PEP may also have the capability to make a local policy
via its Local Policy Decision Point (LPDP) [WRK], however, the
remains the authoritative decision point at all times. This
that the relevant local decision information must be relayed to
PDP. That is, the PDP must be granted access to all
information to make a final policy decision. To facilitate
functionality, the PEP must send its local decision information
the remote PDP via an LPDP decision object. The PEP must then
by the PDP's decision as it is absolute
Finally, fault tolerance is a required capability for this protocol
particularly due to the fact it is associated with the security
service management of distributed network devices. Fault
can be achieved by having both the PEP and remote PDP
verify their connection to each other via keep-alive messages. When
failure is detected, the PEP must try to reconnect to the remote
or attempt to connect to a backup/alternative PDP.
disconnected, the PEP should revert to making local decisions. Once
connection is reestablished, the PEP is expected to notify the PDP
any deleted state or new events that passed local admission
after the connection was lost. Additionally, the remote PDP
request that all the PEP's internal state be resynchronized (
previously installed requests are to be reissued). After failure
before the new connection is fully functional, disruption of
can be minimized if the PEP caches previously communicated
and continues to use them for some limited amount of time.
2.3 and 2.5 detail COPS mechanisms for achieving reliability
2. The
This section describes the message formats and objects
between the PEP and remote PDP
2.1 Common
Each COPS message consists of the COPS header followed by a number
typed objects
0 1 2 3
+--------------+--------------+--------------+--------------+
|Version| Flags| Op Code | Client-type |
+--------------+--------------+--------------+--------------+
| Message Length |
+--------------+--------------+--------------+--------------+
Global note: //// implies field is reserved, set to 0.
Durham, et al. Standards Track [Page 6]
RFC 2748 COPS January 2000
The fields in the header are
Version: 4
COPS version number. Current version is 1.
Flags: 4
Defined flag values (all other flags MUST be set to 0):
0x1 Solicited Message Flag
This flag is set when the message is solicited
another COPS message. This flag is NOT to be
(value=0) unless otherwise specified in section 3.
Op Code: 8
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
Client-type: 16
The Client-type identifies the policy client. Interpretation
all encapsulated objects is relative to the client-type. Client
types that set the most significant bit in the client-type
are enterprise specific (these are client-types 0x8000 -
0xFFFF). (See the specific client usage documents for
client-type IDs). For KA Messages, the client-type in the
MUST always be set to 0 as the KA is used for
verification (not per client session verification).
Message Length: 32
Size of message in octets, which includes the standard
header and all encapsulated objects. Messages MUST be aligned
4 octet intervals
Durham, et al. Standards Track [Page 7]
RFC 2748 COPS January 2000
2.2 COPS Specific Object
All the objects follow the same object format; each object
of one or more 32-bit words with a four-octet header, using
following format
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
The length is a two-octet value that describes the number of
(including the header) that compose the object. If the length
octets does not fall on a 32-bit word boundary, padding MUST be
to the end of the object so that it is aligned to the next 32-
boundary before the object can be sent on the wire. On the
side, a subsequent object boundary can be found by simply rounding
the previous stated object length to the next 32-bit boundary
Typically, C-Num identifies the class of information contained in
object, and the C-Type identifies the subtype or version of
information contained in the object
C-num: 8
1 =
2 =
3 = In
4 = Out
5 = Reason
6 =
7 = LPDP
8 =
9 = Client Specific
10 = Keep-Alive
11 = PEP
12 = Report
13 = PDP Redirect
14 = Last PDP
15 = Accounting
16 = Message
C-type: 8
Values defined per C-num
Durham, et al. Standards Track [Page 8]
RFC 2748 COPS January 2000
2.2.1 Handle Object (Handle
The Handle Object encapsulates a unique value that identifies
installed state. This identification is used by most COPS operations
A state corresponding to a handle MUST be explicitly deleted when
is no longer applicable. See Section 2.4 for details
C-Num = 1
C-Type = 1, Client Handle
Variable-length field, no implied format other than it is unique
other client handles from the same PEP (a.k.a. COPS TCP connection
for a particular client-type. It is always initially chosen by
PEP and then deleted by the PEP when no longer applicable. The
handle is used to refer to a request state initiated by a
PEP and installed at the PDP for a client-type. A PEP will specify
client handle in its Request messages, Report messages and
messages sent to the PDP. In all cases, the client handle is used
uniquely identify a particular PEP's request for a client-type
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
object with respect to the handle object values of other
installed requests
2.2.2 Context Object (Context
Specifies the type of event(s) that triggered the query. Required
request messages. Admission control, resource allocation,
forwarding requests are all amenable to client-types that
their decision making facility to the PDP. For applicable client
types a PEP can also make a request to receive named
information from the PDP. This named configuration data may be in
form useful for setting system attributes on a PEP, or it may be
the form of policy rules that are to be directly verified by the PEP
Multiple flags can be set for the same request. This is only allowed
however, if the set of client specific information in the
request is identical to the client specific information that would
specified if individual requests were made for each specified flag
C-num = 2, C-Type = 1
Durham, et al. Standards Track [Page 9]
RFC 2748 COPS January 2000
0 1 2 3
+--------------+--------------+--------------+--------------+
| R-Type | M-Type |
+--------------+--------------+--------------+--------------+
R-Type (Request Type Flag
0x01 = Incoming-Message/Admission Control
0x02 = Resource-Allocation
0x04 = Outgoing-Message
0x08 = Configuration
M-Type (Message Type
Client Specific 16 bit values of protocol message
2.2.3 In-Interface Object (IN-Int
The In-Interface Object is used to identify the incoming interface
which a particular request applies and the address where the
message originated. For flows or messages generated from the PEP'
local host, the loop back address and ifindex are used
This Interface object is also used to identify the
(receiving) interface via its ifindex. The ifindex may be used
differentiate between sub-interfaces and unnumbered interfaces (
RSVP's LIH for an example). When SNMP is supported by the PEP,
ifindex integer MUST correspond to the same integer value for
interface in the SNMP MIB-II interface index table
Note: The ifindex specified in the In-Interface is typically
to the flow of the underlying protocol messages. The ifindex is
interface on which the protocol message was received
C-Num = 3
C-Type = 1, IPv4 Address +
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv4 address specifies
IP address that the incoming message came from
Durham, et al. Standards Track [Page 10]
RFC 2748 COPS January 2000
C-Type = 2, IPv6 Address +
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv6 address specifies
IP address that the incoming message came from. The ifindex is
to refer to the MIB-II defined local incoming interface on the PEP
described above
2.2.4 Out-Interface Object (OUT-Int
The Out-Interface is used to identify the outgoing interface to
a specific request applies and the address for where the
message is to be sent. For flows or messages destined to the PEP'
local host, the loop back address and ifindex are used. The Out
Interface has the same formats as the In-Interface Object
This Interface object is also used to identify the
(forwarding) interface via its ifindex. The ifindex may be used
differentiate between sub-interfaces and unnumbered interfaces (
RSVP's LIH for an example). When SNMP is supported by the PEP,
ifindex integer MUST correspond to the same integer value for
interface in the SNMP MIB-II interface index table
Note: The ifindex specified in the Out-Interface is
relative to the flow of the underlying protocol messages. The
is the one on which a protocol message is about to be forwarded
C-Num = 4
C-Type = 1, IPv4 Address +
Same C-Type format as the In-Interface object. The IPv4
specifies the IP address to which the outgoing message is going.
ifindex is used to refer to the MIB-II defined local
interface on the PEP
Durham, et al. Standards Track [Page 11]
RFC 2748 COPS January 2000
C-Type = 2, IPv6 Address +
Same C-Type format as the In-Interface object. For this type of
interface object, the IPv6 address specifies the IP address to
the outgoing message is going. The ifindex is used to refer to
MIB-II defined local outgoing interface on the PEP
2.2.5 Reason Object (Reason
This object specifies the reason why the request state was deleted
It appears in the delete request (DRQ) message. The Reason Sub-
field is reserved for more detailed client-specific reason
defined in the corresponding documents
C-Num = 5, C-Type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Reason-Code | Reason Sub-code |
+--------------+--------------+--------------+--------------+
Reason Code
1 =
2 =
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
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-
and (octet 3) contains unknown object's C-Type
2.2.6 Decision Object (Decision
Decision made by the PDP. Appears in replies. The specific non
mandatory decision objects required in a decision to a
request depend on the type of client
Durham, et al. Standards Track [Page 12]
RFC 2748 COPS January 2000
C-Num = 6
C-Type = 1, Decision Flags (Mandatory
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
Flags
0x01 = Trigger Error (Trigger error message if set
Note: Trigger Error is applicable to client-types
are capable of sending error notifications for
messages
Flag values not applicable to a given context's R-Type
client-type MUST be ignored by the PEP
C-Type = 2, Stateless
This type of decision object carries additional
information that can be applied by the PEP locally. It is
variable length object and its internal format SHOULD
specified in the relevant COPS extension document for the
client-type. This object is optional in Decision messages and
interpreted relative to a given context
It is expected that even outsourcing PEPs will be able to
some simple stateless policy decisions locally in their LPDP.
this set is well known and implemented ubiquitously, PDPs
aware of it as well (either universally, through configuration
or using the Client-Open message). The PDP may also include
information in its decision, and the PEP MUST apply it to
resource allocation event that generated the request
C-Type = 3, Replacement
This type of decision object carries replacement data that is
replace existing data in a signaled message. It is a
length object and its internal format SHOULD be specified in
relevant COPS extension document for the given client-type. It
optional in Decision messages and is interpreted relative to
given context
Durham, et al. Standards Track [Page 13]
RFC 2748 COPS January 2000
C-Type = 4, Client Specific Decision
Additional decision types can be introduced using the
Specific Decision Data Object. It is a variable length object
its internal format SHOULD be specified in the relevant
extension document for the given client-type. It is optional
Decision messages and is interpreted relative to a given context
C-Type = 5, Named Decision
Named configuration information is encapsulated in this
of the decision object in response to configuration requests.
is a variable length object and its internal format SHOULD
specified in the relevant COPS extension document for the
client-type. It is optional in Decision messages and
interpreted relative to both a given context and decision flags
2.2.7 LPDP Decision Object (LPDPDecision
Decision made by the PEP's local policy decision point (LPDP).
appear in requests. These objects correspond to and are formatted
same as the client specific decision objects defined above
C-Num = 7
C-Type = (same C-Type as for Decision objects
2.2.8 Error Object (Error
This object is used to identify a particular COPS protocol error
The error sub-code field contains additional detailed client
error codes. The appropriate Error Sub-codes for a
client-type SHOULD be specified in the relevant COPS
document
C-Num = 8, C-Type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+
Error-Code
1 = Bad
2 = Invalid handle
3 = Bad message format (Malformed Message
4 = Unable to process (server gives up on query
Durham, et al. Standards Track [Page 14]
RFC 2748 COPS January 2000
5 = Mandatory client-specific info
6 = Unsupported client-
7 = Mandatory COPS object
8 = Client
9 = Communication
10=
11= Shutting
12= Redirect to Preferred
13= Unknown COPS Object
Sub-code (octet 2) contains unknown object's C-
and (octet 3) contains unknown object's C-Type
14= Authentication
15= Authentication
2.2.9 Client Specific Information Object (ClientSI
The various types of this object are required for requests, and
in reports and opens when required. It contains client-type
information
C-Num = 9,
C-Type = 1, Signaled ClientSI
Variable-length field. All objects/attributes specific to a client'
signaling protocol or internal state are encapsulated within one
more signaled Client Specific Information Objects. The format of
data encapsulated in the ClientSI object is determined by
client-type
C-Type = 2, Named ClientSI
Variable-length field. Contains named configuration
useful for relaying specific information about the PEP, a request,
configured state to the PDP server
2.2.10 Keep-Alive Timer Object (KATimer
Times are encoded as 2 octet integer values and are in units
seconds. The timer value is treated as a delta
C-Num = 10,
C-Type = 1, Keep-alive timer
Durham, et al. Standards Track [Page 15]
RFC 2748 COPS January 2000
Timer object used to specify the maximum time interval over which
COPS message MUST be sent or received. The range of finite
is 1 to 65535 seconds represented as an unsigned two-octet integer
The value of zero implies infinity
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+
2.2.11 PEP Identification Object (PEPID
The PEP Identification Object is used to identify the PEP client
the remote PDP. It is required for Client-Open messages
C-Num = 11, C-Type = 1
Variable-length field. It is a NULL terminated ASCII string that
also zero padded to a 32-bit word boundary (so the object length is
multiple of 4 octets). The PEPID MUST contain an ASCII string
uniquely identifies the PEP within the policy domain in a manner
is persistent across PEP reboots. For example, it may be the PEP'
statically assigned IP address or DNS name. This identifier
safely be used by a PDP as a handle for identifying the PEP in
policy rules
2.2.12 Report-Type Object (Report-Type
The Type of Report on the request state associated with a handle
C-Num = 12, C-Type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+
Report-Type
1 = Success : Decision was successful at the
2 = Failure : Decision could not be completed by
3 = Accounting: Accounting update for an installed
2.2.13 PDP Redirect Address (PDPRedirAddr
A PDP when closing a PEP session for a particular client-type
optionally use this object to redirect the PEP to the specified
server address and TCP port number
Durham, et al. Standards Track [Page 16]
RFC 2748 COPS January 2000
C-Num = 13,
C-Type = 1, IPv4 Address + TCP
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
C-Type = 2, IPv6 Address + TCP
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
2.2.14 Last PDP Address (LastPDPAddr
When a PEP sends a Client-Open message for a particular client-
the PEP SHOULD specify the last PDP it has successfully
(meaning it received a Client-Accept) since the PEP last rebooted
If no PDP was used since the last reboot, the PEP will simply
include this object in the Client-Open message
C-Num = 14,
C-Type = 1, IPv4 Address (Same format as PDPRedirAddr
C-Type = 2, IPv6 Address (Same format as PDPRedirAddr
2.2.15 Accounting Timer Object (AcctTimer
Times are encoded as 2 octet integer values and are in units
seconds. The timer value is treated as a delta
C-Num = 15,
C-Type = 1, Accounting timer
Durham, et al. Standards Track [Page 17]
RFC 2748 COPS January 2000
Optional timer value used to determine the minimum interval
periodic accounting type reports. It is used by the PDP to
to the PEP an acceptable interval between unsolicited
updates via Report messages where applicable. It provides a
for the PDP to control the amount of accounting traffic seen by
network. The range of finite time values is 1 to 65535
represented as an unsigned two-octet integer. A value of zero
there SHOULD be no unsolicited accounting updates
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+
2.2.16 Message Integrity Object (Integrity
The integrity object includes a sequence number and a message
useful for authenticating and validating the integrity of a
message. When used, integrity is provided at the end of a
message as the last COPS object. The digest is then computed over
of a particular COPS message up to but not including the digest
itself. The sender of a COPS message will compute and fill in
digest portion of the Integrity object. The receiver of a
message will then compute a digest over the received message
verify it matches the digest in the received Integrity object
C-Num = 16,
C-Type = 1, HMAC
The HMAC integrity object employs HMAC (Keyed-Hashing for
Authentication) [HMAC] to calculate the message digest based on a
shared between the PEP and its PDP
This Integrity object specifies a 32-bit Key ID used to identify
specific key shared between a particular PEP and its PDP and
cryptographic algorithm to be used. The Key ID allows for
simultaneous keys to exist on the PEP with corresponding keys on
PDP for the given PEPID. The key identified by the Key ID was used
compute the message digest in the Integrity object.
implementations, at a minimum, MUST support HMAC-MD5-96, which
HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated
96-bits to calculate the message digest
This object also includes a sequence number that is a 32-bit
integer used to avoid replay attacks. The sequence number
initiated during an initial Client-Open Client-Accept
exchange and is then incremented by one each time a new message
Durham, et al. Standards Track [Page 18]
RFC 2748 COPS January 2000
sent over the TCP connection in the same direction. If the
number reaches the value of 0xFFFFFFFF, the next increment
simply rollover to a value of zero
The variable length digest is calculated over a COPS message
with the COPS Header up to the Integrity Object (which MUST be
last object in a COPS message) INCLUDING the Integrity object'
header, Key ID, and Sequence Number. The Keyed Message Digest
is not included as part of the digest calculation. In the case
HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that is then
be truncated to 96-bits before being stored in or verified
the Keyed Message Digest field as specified in [HMAC]. The
Message Digest MUST be 96-bits when HMAC-MD5-96 is used
0 1 2 3
+-------------+-------------+-------------+-------------+
| Key ID |
+-------------+-------------+-------------+-------------+
| Sequence Number |
+-------------+-------------+-------------+-------------+
| |
+ +
| ...Keyed Message Digest... |
+ +
| |
+-------------+-------------+-------------+-------------+
2.3
The COPS protocol uses a single persistent TCP connection between
PEP and a remote PDP. One PDP implementation per server MUST
on a well-known TCP port number (COPS=3288 [IANA]). The PEP
responsible for initiating the TCP connection to a PDP. The
of the remote PDP can either be configured, or obtained via a
location mechanism [SRVLOC]. Service discovery is outside the
of this protocol, however
If a single PEP can support multiple client-types, it may
multiple Client-Open messages, each specifying a particular client
type to a PDP over one or more TCP connections. Likewise, a
residing at a given address and port number may support one or
client-types. Given the client-types it supports, a PDP has
ability to either accept or reject each client-type independently
If a client-type is rejected, the PDP can redirect the PEP to
alternative PDP address and TCP port for a given client-type
COPS. Different TCP port numbers can be used to redirect the PEP
another PDP implementation running on the same server.
provisions for supporting multiple client-types (perhaps
Durham, et al. Standards Track [Page 19]
RFC 2748 COPS January 2000
independent PDP vendors) on a single remote PDP server are
provided by the COPS protocol, but, rather, are left to the
architecture of the given server platform
It is possible a single PEP may have open connections to
PDPs. This is the case when there are physically different
supporting different client-types as shown in figure 2.
+----------------+
| |
| Network Node | Policy
| |
| +-----+ | COPS Client Type 1 +-----+
| | |<-----|-------------------->| PDP1|
| + PEP + | COPS Client Type 2 +-----+
| | |<-----|---------\ +-----+
| +-----+ | \----------| PDP2|
| ^ | +-----+
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
Figure 2: Multiple PDPs illustration
When a TCP connection is torn down or is lost, the PDP is expected
eventually clean up any outstanding request state related
request/decision exchanges with the PEP. When the PEP detects a
connection due to a timeout condition it SHOULD explicitly send
Client-Close message for each opened client-type containing
object indicating the "Communication Failure" Error-Code
Additionally, the PEP SHOULD continuously attempt to contact
primary PDP or, if unsuccessful, any known backup PDPs.
the PEP SHOULD keep trying all relevant PDPs with which it has
configured until it can establish a connection. If a PEP is
communication with a backup PDP and the primary PDP
available, the backup PDP is responsible for redirecting the PEP
to the primary PDP (via a message containing
object identifying the primary PDP to use for
affected client-type). Section 2.5 details synchronization
between PEPs and PDPs
Durham, et al. Standards Track [Page 20]
RFC 2748 COPS January 2000
2.4 Client Handle
The client handle is used to identify a unique request state for
single PEP per client-type. Client handles are chosen by the PEP
are opaque to the PDP. The PDP simply uses the request handle
uniquely identify the request state for a particular Client-Type
a particular TCP connection and generically tie its decisions to
corresponding request. Client handles are initiated in
messages and are then used by subsequent request, decision,
report messages to reference the same request state. When the PEP
ready to remove a local request state, it will issue a delete
to the PDP for the corresponding client handle. A handle MUST
explicitly deleted by the PEP before it can be used by the PEP
identify a new request state. Handles referring to different
states MUST be unique within the context of a particular
connection and client-type
2.5 Synchronization
When disconnected from a PDP, the PEP SHOULD revert to making
decisions. Once a connection is reestablished, the PEP is expected
notify the PDP of any events that have passed local
control. Additionally, the remote PDP may request that all the PEP'
internal state be resynchronized (all previously installed
are to be reissued) by sending a Synchronize State message
After a failure and before a new connection is fully functional
disruption of service can be minimized if the PEP caches
communicated decisions and continues to use them for some
length of time. Specific rules for such behavior are to be defined
the appropriate COPS client-type extension specifications
A PEP that caches state from a previous exchange with a
PDP MUST communicate this fact to any PDP with which it is able
later reconnect. This is accomplished by including the address
TCP port of the last PDP for which the PEP is still caching state
the Client-Open message. The object will only
included for the last PDP with which the PEP was completely in sync
If the service interruption was temporary and the PDP still
the complete state for the PEP, the PDP may choose not to
all states. It is still the responsibility of the PEP to update
PDP of all state changes that occurred during the disruption
service including any states communicated to the previous PDP
had been deleted after the connection was lost. These MUST
explicitly deleted after a connection is reestablished. If the
issues a synchronize request the PEP MUST pass all current states
the PDP followed by a Synchronize State Complete message (
Durham, et al. Standards Track [Page 21]
RFC 2748 COPS January 2000
completing the synchronization process). If the PEP crashes and
all cached state for a client-type, it will simply not include
in its Client-Open message
3. Message
This section describes the basic messages exchanged between a PEP
a remote PDP as well as their contents. As a convention,
ordering is expected as shown in the BNF for each COPS message
otherwise noted. The Integrity object, if included, MUST always
the last object in a message. If security is required and a
was received without a valid Integrity object, the receiver MUST
a Client-Close message for Client-Type=0 specifying the
error code
3.1 Request (REQ) PEP ->
The PEP establishes a request state client handle for which
remote PDP may maintain state. The remote PDP then uses this
to refer to the exchanged information and decisions communicated
the TCP connection to a particular PEP for a given client-type
Once a stateful handle is established for a new request,
subsequent modifications of the request can be made using the
message specifying the previously installed handle. The PEP
responsible for notifying the PDP whenever its local state changes
the PDP's state will be able to accurately mirror the PEP's state
Durham, et al. Standards Track [Page 22]
RFC 2748 COPS January 2000
The format of the Request message is as follows
::=
[]
[]
[]
[]
[<Integrity>]
::= |
::= |
::= []
[]
[Replacement Data>]
[]
[]
The context object is used to determine the context within which
the other objects are to be interpreted. It also is used to
the kind of decision to be returned from the policy server.
decision might be related to admission control, resource allocation
object forwarding and substitution, or configuration
The interface objects are used to determine the
interface on which a signaling protocol message was received or
about to be sent. They are typically used if the client
participating along the path of a signaling protocol or if the
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.
the case of configuration, the Named ClientSI may include
information about the module, interface, or functionality to
configured. The ordering of multiple ClientSIs is not important
Finally, LPDPDecision object holds information regarding the
decision made by the LPDP
Malformed Request messages MUST result in the PDP specifying
Decision message with the appropriate error code
Durham, et al. Standards Track [Page 23]
RFC 2748 COPS January 2000
3.2 Decision (DEC) PDP ->
The PDP responds to the REQ with a DEC message that includes
associated client handle and one or more decision objects
relative to a Context object and Decision Flags object type pair.
there was a protocol error an error object is returned instead
It is required that the first decision message for a new/
request will have the solicited message flag set (value = 1) in
COPS header. This avoids the issue of keeping track of which
request (that is, a request reissued for the same handle)
particular decision corresponds. It is important that, for a
handle, there be at most one outstanding solicited decision
request. This essentially means that the PEP SHOULD NOT issue
than one REQ (for a given handle) before it receives a
DEC with the solicited message flag set. The PDP MUST always
decisions for requests on a particular handle in the order
arrive and all requests MUST have a corresponding decision
To avoid deadlock, the PEP can always timeout after issuing a
that does not receive a decision. It MUST then delete the timed-
handle, and may try again using a new handle
The format of the Decision message is as follows
<Decision Message> ::=
<Decision(s)> |
[<Integrity>]
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision
<Decision> ::=
<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
more context plus associated decision objects. COPS protocol
are reported in the Error object (e.g. an error with the format
the original request including malformed request messages,
COPS objects in the Request, etc.). The applicable Decision object(s
depend on the context and the type of client. The only
requirement for decision objects is that the required Decision
object type MUST precede the other Decision object types per
binding
Durham, et al. Standards Track [Page 24]
RFC 2748 COPS January 2000
3.3 Report State (RPT) PEP ->
The RPT message is used by the PEP to communicate to the PDP
success or failure in carrying out the PDP's decision, or to
an accounting related change in state. The Report-Type specifies
kind of report and the optional ClientSI can carry
information per Client-Type
For every DEC message containing a configuration context that
received by a PEP, the PEP MUST generate a corresponding Report
message with the Solicited Message flag set describing its success
failure in applying the configuration decision. In addition
outsourcing decisions from the PDP MAY result in a
solicited Report State from the PEP depending on the context and
type of client. RPT messages solicited by decisions for a
Client Handle MUST set the Solicited Message flag and MUST be sent
the same order as their corresponding Decision messages
received. There MUST never be more than one Report State
generated with the Solicited Message flag set per Decision
The Report State may also be used to provide periodic updates
client specific information for accounting and state
purposes depending on the type of the client. In such cases
accounting report type should be specified utilizing the
client specific information object
::==
[]
[<Integrity>]
3.4 Delete Request State (DRQ) PEP ->
When sent from the PEP this message indicates to the remote PDP
the state identified by the client handle is no
available/relevant. This information will then be used by the
PDP to initiate the appropriate housekeeping actions. The reason
object is interpreted with respect to the client-type and
the reason for the removal
The format of the Delete Request State message is as follows
::=
[<Integrity>]
Durham, et al. Standards Track [Page 25]
RFC 2748 COPS January 2000
Given the stateful nature of COPS, it is important that when
request state is finally removed from the PEP, a DRQ message for
request state is sent to the PDP so the corresponding state
likewise be removed on the PDP. Request states not explicitly
by the PEP will be maintained by the PDP until either the
session is closed or the connection is terminated
Malformed Decision messages MUST trigger a DRQ specifying
appropriate erroneous reason code (Bad Message Format) and
associated state on the PEP SHOULD either be removed or re-requested
If a Decision contained an unknown COPS Decision Object, the PEP
delete its request specifying the Unknown COPS Object reason
because the PEP will be unable to comply with the
contained in the unknown object. In any case, after issuing a DRQ
the PEP may retry the corresponding Request again
3.5 Synchronize State Request (SSQ) PDP ->
The format of the Synchronize State Query message is as follows
::=
[]
[<Integrity>]
This message indicates that the remote PDP wishes the client (
appears in the common header) to re-send its state. If the
Client Handle is present, only the state associated with this
is synchronized. If the PEP does not recognize the requested handle
it MUST immediately send a DRQ message to the PDP for the handle
was specified in the SSQ message. If no handle is specified in
SSQ message, all the active client state MUST be synchronized
the PDP
The client performs state synchronization by re-issuing
queries of the specified client-type for the existing state in
PEP. When synchronization is complete, the PEP MUST issue
synchronize state complete message to the PDP
3.6 Client-Open (OPN) PEP ->
The Client-Open message can be used by the PEP to specify to the
the client-types the PEP can support, the last PDP to which the
connected for the given client-type, and/or client specific
negotiation. A Client-Open message can be sent to the PDP at any
and multiple Client-Open messages for the same client-type
allowed (in case of global state changes).
Durham, et al. Standards Track [Page 26]
RFC 2748 COPS January 2000
::=
[]
[]
[<Integrity>]
The PEPID is a symbolic, variable length name that
identifies the specific client to the PDP (see Section 2.2.11).
A named ClientSI object can be included for relaying
global information about the PEP to the PDP when required (
specified in the appropriate extensions document for the client
type).
The PEP may also provide a Last PDP Address object in its Client-
message specifying the last PDP (for the given client-type) for
it is still caching decisions since its last reboot. A PDP can
this information to determine the appropriate
behavior (See section 2.5).
If the PDP receives a malformed Client-Open message it MUST
a Client-Close message specifying the appropriate error code
3.7 Client-Accept (CAT) PDP ->
The Client-Accept message is used to positively respond to
Client-Open message. This message will return to the PEP a
object indicating the maximum time interval between keep-
messages. Optionally, a timer specifying the minimum allowed
between accounting report messages may be included when applicable
::=
[]
[<Integrity>]
If the PDP refuses the client, it will instead issue a Client-
message
The KA Timer corresponds to maximum acceptable intermediate
between the generation of messages by the PDP and PEP. The
value is determined by the PDP and is specified in seconds. A
value of 0 implies no secondary connection verification is necessary
The optional ACCT Timer allows the PDP to indicate to the PEP
periodic accounting reports SHOULD NOT exceed the specified
interval per client handle. This allows the PDP to control the
at which accounting reports are sent by the PEP (when applicable).
Durham, et al. Standards Track [Page 27]
RFC 2748 COPS January 2000
In general, accounting type Report messages are sent to the PDP
determined appropriate by the PEP. The accounting timer merely
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
the rate at which accounting updates are generated
If the PEP receives a malformed Client-Accept message it
generate a Client-Close message specifying the appropriate
code
3.8 Client-Close (CC) PEP -> PDP, PDP ->
The Client-Close message can be issued by either the PDP or PEP
notify the other that a particular type of client is no longer
supported
::=
[]
[<Integrity>]
The Error object is included to describe the reason for the
(e.g. the requested client-type is not supported by the remote PDP
client failure).
A PDP MAY optionally include a PDP Redirect Address object in
to inform the PEP of the alternate PDP it SHOULD use for the client
type specified in the common header
3.9 Keep-Alive (KA) PEP -> PDP, PDP ->
The keep-alive message MUST be transmitted by the PEP within
period defined by the minimum of all KA Timer values specified in
received CAT messages for the connection. A KA message MUST
generated randomly between 1/4 and 3/4 of this minimum KA
interval. When the PDP receives a keep-alive message from a PEP,
MUST echo a keep-alive back to the PEP. This message
validation for each side that the connection is still
even when there is no other messaging
Note: The client-type in the header MUST always be set to 0 as the
is used for connection verification (not per client
verification).
::=
[<Integrity>]
Durham, et al. Standards Track [Page 28]
RFC 2748 COPS January 2000
Both client and server MAY assume the TCP connection is
for the client-type with the minimum time value (specified in the
message) if no communication activity is detected for a
exceeding the timer period. For the PEP, such detection implies
remote PDP or connection is down and the PEP SHOULD now attempt
use an alternative/backup PDP
3.10 Synchronize State Complete (SSC) PEP ->
The Synchronize State Complete is sent by the PEP to the PDP
the PDP sends a synchronize state request to the PEP and the PEP
finished synchronization. It is useful so that the PDP will know
all the old client state has been successfully re-requested and
thus, the PEP and PDP are completely synchronized. The Client
object only needs to be included if the corresponding
State Message originally referenced a specific handle
Complete> ::=
[]
[<Integrity>]
4. Common
This section describes the typical exchanges between remote
servers and PEP clients
4.1 Security and Sequence Number
COPS message security is negotiated once per connection and
all communication over a particular connection. If COPS
security is required, it MUST be negotiated during the
Client-Open/Client-Accept message exchange specifying a Client-
of zero (which is reserved for connection level security
and connection verification).
If a PEP is not 