draft-ietf-rap-cops-02.txt   draft-ietf-rap-cops-03.txt 
Internet Draft Jim Boyle Internet Draft Jim Boyle
Expiration: February 1999 Level 3 Expiration: April 1999 Level 3
File: draft-ietf-rap-cops-02.txt Ron Cohen File: draft-ietf-rap-cops-03.txt Ron Cohen
Cisco Cisco
David Durham David Durham
Intel Intel
Shai Herzog Shai Herzog
IPHighway IPHighway
Raju Rajan Raju Rajan
IBM IBM
Arun Sastry Arun Sastry
Cisco Cisco
The COPS (Common Open Policy Service) Protocol The COPS (Common Open Policy Service) Protocol
Last Updated: August 6, 1998 Last Updated: November 18, 1998
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at page 1, line 41 skipping to change at page 1, line 41
"working draft" or "work in progress". "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. munnari.oz.au.
A revised version of this draft document will be submitted to the A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community. RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire before February 1999. Distribution of this document will expire before April 1999. Distribution of this draft
draft is unlimited. is unlimited.
Status of this Memo................................................1
Abstract...........................................................3
1. Introduction....................................................3
1.1 Basic Model....................................................4
2. The Protocol....................................................7
2.1 Common Header..................................................7
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)......................................11
2.2.6 Decision Object (Decision)..................................12
2.2.7 LDP Decision Object (LDPDecision)...........................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)..........................15
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.3 Communication.................................................17
2.4 Client Handle Usage...........................................19
2.5 Synchronization Behavior......................................19
3. Message Content................................................20
3.1 Request (REQ) PEP -> PDP.....................................20
3.2 Decision (DEC) PDP -> PEP....................................21
3.3 Report State (RPT) PEP -> PDP................................22
3.4 Delete Request State (DRQ) PEP -> PDP........................22
3.5 Synchronize State Request (SSQ) PDP -> PEP...................22
3.6 Client-Open (OPN) PEP -> PDP.................................23
3.7 Client-Accept (CAT) PDP -> PEP...............................24
3.8 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................24
3.9 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................25
3.10 Synchronize State Complete (SSC) PEP -> PDP..................25
4. Common Operation...............................................26
4.1 PEP Initialization............................................26
4.2 Outsourcing Operations........................................26
4.3 Configuration Operations......................................27
4.4 Keep-Alive Operations.........................................27
4.5 PEP Shutdown..................................................27
5. Security.......................................................28
6. IANA Considerations............................................29
7. References.....................................................30
8. Author Information and Acknowledgments.........................31
Abstract Abstract
This document describes a simple client/server model for supporting This document describes a simple client/server model for supporting
policy control over QoS Signaling Protocols and provisioned QoS policy control over QoS Signaling Protocols and provisioned QoS
resource management. It is designed to be extensible so that other resource management. It is designed to be extensible so that other
kinds of policy clients may be supported in the future. The model kinds of policy clients may be supported in the future. The model
does not make any assumptions about the methods of the policy does not make any assumptions about the methods of the policy
server, but is based on the server returning decisions to policy server, but is based on the server returning decisions to policy
requests. requests.
skipping to change at page 3, line 22 skipping to change at page 4, line 22
any time for a currently installed request state. By (2) we mean any time for a currently installed request state. By (2) we mean
that the server may respond to new queries differently because that the server may respond to new queries differently because
of previously installed Request/Decision state(s) that are of previously installed Request/Decision state(s) that are
related. related.
6. Additionally, the protocol is stateful in that it allows the 6. Additionally, the protocol is stateful in that it allows the
server to push configuration information to the client, and then server to push configuration information to the client, and then
allows the server to remove such state from the client when it allows the server to remove such state from the client when it
is no longer applicable. is no longer applicable.
1.1. Basic Model 1.1 Basic Model
+----------------+ +----------------+
| | | |
| Network Node | Policy Server | Network Node | Policy Server
| | | |
| +-----+ | COPS +-----+ | +-----+ | COPS +-----+
| | PEP |<-----|-------------->| PDP | | | PEP |<-----|-------------->| PDP |
| +-----+ | +-----+ | +-----+ | +-----+
| ^ | | ^ |
| | | | | |
skipping to change at page 3, line 52 skipping to change at page 4, line 52
typical COPS example (taken from [WRK]). Here, COPS is used to typical COPS example (taken from [WRK]). Here, COPS is used to
communicate policy information between a Policy Enforcement Point communicate policy information between a Policy Enforcement Point
(PEP) and a remote Policy Decision Point (PDP) within the context of (PEP) and a remote Policy Decision Point (PDP) within the context of
a particular type of client. a particular type of client.
It is assumed that each participating policy client is functionally It is assumed that each participating policy client is functionally
consistent with a PEP [WRK]. The PEP may communicate with a policy consistent with a PEP [WRK]. The PEP may communicate with a policy
server (herein referred to as a remote PDP [WRK]) to obtain policy server (herein referred to as a remote PDP [WRK]) to obtain policy
decisions or directives. decisions or directives.
The PEP uses a TCP connection to send requests to and receive The PEP is responsible for initiating a persistent TCP connection to
decisions from the remote PDP. Communication between the PEP and a PDP. The PEP uses this TCP connection to send requests to and
remote PDP is mainly in the form of a stateful request/decision 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 exchange, though the remote PDP may occasionally send unsolicited
decisions to the PEP to force changes in previously approved request decisions to the PEP to force changes in previously approved request
states. The PEP also has the capacity to report to the remote PDP states. The PEP also has the capacity to report to the remote PDP
that it has committed to an accepted request state for purposes of that it has committed to an accepted request state for purposes of
accounting and monitoring. The PEP is responsible for notifying the accounting and monitoring. The PEP is responsible for notifying the
PDP when a request state has changed on the PEP. Finally, the PEP is 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 responsible for the deletion of any state that is no longer
applicable due to events at the client or decisions issued by the applicable due to events at the client or decisions issued by the
server. server.
skipping to change at page 4, line 44 skipping to change at page 5, line 45
have a corresponding usage draft specifying the specifics of its have a corresponding usage draft specifying the specifics of its
interaction with this policy protocol. interaction with this policy protocol.
The context of each request corresponds to the type of event that The context of each request corresponds to the type of event that
triggered it. COPS identifies three types of outsourcing events: (1) triggered it. COPS identifies three types of outsourcing events: (1)
the arrival of an incoming message (2) allocation of local the arrival of an incoming message (2) allocation of local
resources, and (3) the forwarding of an outgoing message. Each of resources, and (3) the forwarding of an outgoing message. Each of
these events may require different decisions to be made. Context sub these events may require different decisions to be made. Context sub
types are also available to describe the type of message that types are also available to describe the type of message that
triggered the policy event. The content of a COPS request/decision triggered the policy event. The content of a COPS request/decision
message depends on the context. A forth type of request is useful message depends on the context. A fourth type of request is useful
for types of clients that wish to receive configuration information for types of clients that wish to receive configuration information
from the PDP. This allows a PEP to issue a configuration request for from the PDP. This allows a PEP to issue a configuration request for
a specific named device or module that requires configuration a specific named device or module that requires configuration
information to be installed. information to be installed.
The PEP may also have the capability to make a local policy decision The PEP may also have the capability to make a local policy decision
via its Local Decision Point (LDP) [WRK], however, the PDP remains via its Local Decision Point (LDP) [WRK], however, the PDP remains
the authoritative decision point at all times. This means that the the authoritative decision point at all times. This means that the
relevant local decision information must be relayed to the PDP. That relevant local decision information must be relayed to the PDP. That
is, the PDP must be granted access to all relevant information to is, the PDP must be granted access to all relevant information to
make a final policy decision. To facilitate this functionality, the make a final policy decision. To facilitate this functionality, the
PEP must send its local decision information to the remote PDP via a PEP must send its local decision information to the remote PDP via a
LDP decision object. The PEP must then abide by the PDP's decision LDP decision object. The PEP must then abide by the PDP's decision
as it is absolute. as it is absolute.
Finally, fault tolerance is a required capability for this protocol, Finally, fault tolerance is a required capability for this protocol,
particularly due to the fact it is associated with the security and particularly due to the fact it is associated with the security and
service management of distributed network devices. Fault tolerance service management of distributed network devices. Fault tolerance
is achieved by having both the PEP and remote PDP constantly verify can be achieved by having both the PEP and remote PDP constantly
their connection to each other via keep-alive messages. When a verify their connection to each other via keep-alive messages. When
failure is detected, the PEP must try to reconnect to the remote PDP a failure is detected, the PEP must try to reconnect to the remote
or attempt to connect to a new/alternative PDP. While disconnected, PDP or attempt to connect to a new/alternative PDP. While
the PEP should revert to making local decisions. Once a connection disconnected, the PEP should revert to making local decisions. Once
is reestablished, the PEP is expected to notify the PDP of any a connection is reestablished, the PEP is expected to notify the PDP
events that passed local admission control after the connection was of any deleted state or new events that passed local admission
lost. Additionally, the remote PDP may request that all the PEP's control after the connection was lost. Additionally, the remote PDP
internal state be resynchronized (all previously installed requests may request that all the PEP's internal state be resynchronized (all
are to be reissued). After failure and before the new connection is previously installed requests are to be reissued). After failure and
fully functional, disruption of service can be minimized if the PEP before the new connection is fully functional, disruption of service
caches previously communicated decisions and continues to use them can be minimized if the PEP caches previously communicated decisions
for some limited amount of time, typically in the order of minutes. and continues to use them for some limited amount of time.
(Discussions of specific provisions for such a mechanism are outside
of the scope of this draft, and are left to client specific
implementations).
2. The Protocol 2. The Protocol
This section describes the message formats and objects exchanged This section describes the message formats and objects exchanged
between the PEP and remote PDP. between the PEP and remote PDP.
2.1 Common Header 2.1 Common Header
Each COPS message consists of the COPS header followed by a number Each COPS message consists of the COPS header followed by a number
of typed objects. of typed objects.
skipping to change at page 6, line 48 skipping to change at page 7, line 48
10= Client-Close (CC) 10= Client-Close (CC)
11= Synchronize Complete (SSC) 11= Synchronize Complete (SSC)
Client-type: 16 bits Client-type: 16 bits
The Client-type identifies the policy client. Interpretation of The Client-type identifies the policy client. Interpretation of
all encapsulated objects is relative to the client-type. Client- all encapsulated objects is relative to the client-type. Client-
types that set the most significant bit in the client-type field types that set the most significant bit in the client-type field
are enterprise specific (these are client-types 0x8000 - are enterprise specific (these are client-types 0x8000 -
0xFFFF). (See the specific client usage documents for particular 0xFFFF). (See the specific client usage documents for particular
client-type IDs). client-type IDs). For KA Messages, the client-type in the header
should always be set to 0 as the KA is used for connection
verification (not per client session verification).
Message Length: 32 bits Message Length: 32 bits
Size of message in octets, which includes the standard COPS Size of message in octets, which includes the standard COPS
header and all encapsulated objects. Messages must be aligned on header and all encapsulated objects. Messages must be aligned on
4 octet intervals. 4 octet intervals.
2.2 COPS Specific Object Formats 2.2 COPS Specific Object Formats
All the objects follow the same object format; each object consists 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 of one or more 32-bit words with a four-octet header, using the
skipping to change at page 7, line 26 skipping to change at page 8, line 26
// (Object contents) // // (Object contents) //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
The length is a two-octet value that describes the number of octets The length is a two-octet value that describes the number of octets
(including the header) that compose the object. If the length in (including the header) that compose the object. If the length in
octets does not fall on a 32-bit word boundary, padding must be 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- 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 bit boundary before the object can be sent on the wire. On the
receiving side, a subsequent object boundary can be found by simply receiving side, a subsequent object boundary can be found by simply
rounding up the previous stated object length to the first 32-bit rounding up the previous stated object length to the next 32-bit
boundary. boundary.
Typically, C-Num identifies the class of information contained in Typically, C-Num identifies the class of information contained in
the object, and the C-Type identifies the subtype or version of the the object, and the C-Type identifies the subtype or version of the
information contained in the object. information contained in the object.
C-num: 8 bits C-num: 8 bits
1 = Handle 1 = Handle
3 = Context 3 = Context
4 = In Interface 4 = In Interface
5 = Out Interface 5 = Out Interface
6 = Reason code 6 = Reason code
7 = Decision 7 = Decision
8 = LDP Decision 8 = LDP Decision
9 = Protocol Error 9 = Error
10 = Client Specific Info 10 = Client Specific Info
11 = Timer 11 = Keep-Alive Timer
12 = PEP Identification 12 = PEP Identification
13 = Report Type 13 = Report Type
14 = PDP Address 14 = PDP Redirect Address
15 = Last PDP Address
16 = Accounting Timer
C-type: 8 bits C-type: 8 bits
Values defined per C-num. Values defined per C-num.
2.2.1 Handle Object (Handle) 2.2.1 Handle Object (Handle)
The Handle Object encapsulates a unique value that identifies an The Handle Object encapsulates a unique value that identifies an
installed state. This identification is used by most COPS installed state. This identification is used by most COPS
operations. A state corresponding to a handle must be explicitly operations. A state corresponding to a handle must be explicitly
deleted when it is no longer applicable. deleted when it is no longer applicable.
skipping to change at page 9, line 4 skipping to change at page 10, line 7
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| R-Type | M-Type | | R-Type | M-Type |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
R-Type (Request Type Flag) R-Type (Request Type Flag)
0x01 = Incoming-Message/Admission Control request 0x01 = Incoming-Message/Admission Control request
0x02 = Resource-Allocation request 0x02 = Resource-Allocation request
0x04 = Outgoing-Message request 0x04 = Outgoing-Message request
0x08 = Configuration request 0x08 = Configuration request
M-Type (Message Type) M-Type (Message Type)
Client Specific 16 bit values of protocol message types Client Specific 16 bit values of protocol message types
2.2.3 In-Interface Object (IN-Int) 2.2.3 In-Interface Object (IN-Int)
The In-Interface Object is used to identify the incoming interface The In-Interface Object is used to identify the incoming interface
on which a particular request/decision applies. For flows or on which a particular request applies and the address where the
messages generated from the PEP's local host, the loop back address received message originated. For flows or messages generated from
is used. the PEP's local host, the loop back address and ifindex are used.
Note: In-Interface is typically relative to the flow of the This Interface object is also used to identify the incoming
underlying protocol messages. That is, the In-Interface is the (receiving) interface via its ifindex. The ifindex may be used to
interface on which the protocol message was received. 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.
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.
C-Num = 4 C-Num = 4
C-Type = 1, IPv4 Address C-Type = 1, IPv4 Address + Interface
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| IPv4 Address format | | IPv4 Address format |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
C-Type = 2, IPv6 Address For this type of the interface object, the IPv4 address should
specify the IP address that the incoming message came from.
C-Type = 2, IPv6 Address + Interface
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| | | |
+ + + +
| | | |
+ IPv6 Address format + + IPv6 Address format +
| | | |
+ + + +
| | | |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
C-Type = 3, Ifindex value
0 1 2 3
+--------------+--------------+--------------+--------------+
| ifindex | | ifindex |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv6 address should
Ifindex may be used to differ between sub-interfaces and unnumbered specify the IP address that the incoming message came from. The
interfaces (see RSVP's LIH for an example). When appropriate, this ifindex is used to refer to the MIB-II defined local incoming
ifindex integer should correspond to the same integer value for the interface on the PEP as described above.
interface in the SNMP MIB-II interface index table.
2.2.4 Out-Interface Object (OUT-Int) 2.2.4 Out-Interface Object (OUT-Int)
The Out-Interface is used to identify the outgoing interface to The Out-Interface is used to identify the outgoing interface to
which a specific request/decision applies. It has the same format as which a specific request applies and the address for where the
the In-Interface Object. 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.
C-Num = 5, C-Type = (same C-Type as for In-Interface) 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.
Note: Out-Interface is typically relative to the flow of the Note: The ifindex specified in the Out-Interface is typically
underlying protocol messages. That is, the Out-Interface is the one relative to the flow of the underlying protocol messages. The
on which a protocol message is about to be forwarded. ifindex is the one on which a protocol message is about to be
forwarded.
C-Num = 5
C-Type = 1, IPv4 Address + Interface
Same C-Type format as the In-Interface object. The IPv4 address
should specify 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-Type = 2, IPv6 Address + Interface
Same C-Type format as the In-Interface object. For this type of the
interface object, the IPv6 address should specify 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.
2.2.5 Reason Object (Reason) 2.2.5 Reason Object (Reason)
This object specifies the reason why the request state was deleted. This object specifies the reason why the request state was deleted.
It should appear in the delete request (DRQ) message. The Reason It should appear in the delete request (DRQ) message. The Reason
Sub-code field is reserved for more detailed client-specific reason Sub-code field is reserved for more detailed client-specific reason
codes defined in the corresponding documents. codes defined in the corresponding documents.
C-Num = 6, C-Type = 1 C-Num = 6, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Reason-Code | Reason Sub-code | | Reason-Code | Reason Sub-code |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Reason Code: Reason Code:
1 = Unspecified 1 = Unspecified
2 = Management 2 = Management
3 = Preempted 3 = Preempted (Another request state takes precedence)
4 = Tear 4 = Tear (Used to communicate a signaled state removal)
5 = Timeout 5 = Timeout (Local state has timed-out)
6 = Route Change 6 = Route Change (Change invalidates request state)
7 = Insufficient Resources 7 = Insufficient Resources (No local resource available)
8 = PDP's Directive 8 = PDP's Directive (PDP decision caused the delete)
9 = Unsupported decision 9 = Unsupported decision (PDP decision not supported)
10= Synchronize Handle Unknown 10= Synchronize Handle Unknown
11= Transient Handle (stateless event) 11= Transient Handle (stateless event)
12= Malformed Decision (could not recover)
2.2.6 Decision Object (Decision) 2.2.6 Decision Object (Decision)
Decision made by the PDP. Must appear in replies. The specific non- Decision made by the PDP. Must appear in replies. The specific non-
mandatory decision objects required in a decision to a particular mandatory decision objects required in a decision to a particular
request depend on the type of client. request depend on the type of client.
C-Num = 7 C-Num = 7
CType = 1, Decision Flags (Mandatory) C-Type = 1, Decision Flags (Mandatory)
A flag bit set to 1 implies a negative decision for that flag.
Not setting any flags generally implies a positive decision.
Flag values not applicable to a given request type MUST be
ignored by the PEP.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Flags | | Flags |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Flags: Flags:
0x01 = Allow Incoming (Reject if set) 0x01 = Admit Signaled (Reject if set)
0x02 = Allocate Resources (Reject if set)
0x04 = Forward Outgoing (do not forward if set)
0x08 = Trigger Error (Trigger error message if set) 0x08 = Trigger Error (Trigger error message if set)
Note: For the above flags, a flag bit set to 1
implies a negative decision for that flag. Not
setting a flag implies a positive decision.
0x10 = NULL Configuration (No configuration data if set) 0x10 = NULL Configuration (No configuration data if set)
0x20 = Install Configuration (Nothing to install if set) 0x20 = Install Configuration (Install named data if set)
0x40 = Remove Configuration (Nothing to remove if set) 0x40 = Remove Configuration (Remove named data if set)
0x80 = Enable Configuration (Nothing to enable if set) Note: If NULL Configuration ignore Install/Remove.
0x100= Disable Configuration (Nothing to disable if set) Note: Only one of Install OR Remove may be set in
one decision flags object.
0x200= Solicited Decision 0x200= Solicited Decision
(Initial decision after a new/updated request if set) (Initial decision after a new/updated request if set)
Ctype = 2, Resource Allocation Data Flag values not applicable to a given context's R-Type MUST be
ignored by the PEP. See table below:
Decision Flag : Valid Context R-Type
-------------------------------------------------------
Admit Signaled : Incoming-Message/Admission Control
Admit Signaled : Resource-Allocation
Admit Signaled : Outgoing-Message
Trigger Error : Any of the above R-Types
NULL Configuration : Configuration
Install Config. : Configuration
Remove Config. : Configuration
Solicited Decision : Any R-Type
C-Type = 2, Resource Allocation Data
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.
It is expected that even outsourcing PEPs will be able to make It is expected that even outsourcing PEPs will be able to make
some simple stateless policy decisions locally in their LDP. As some simple stateless policy decisions locally in their LDP. As
this set is well known and implemented ubiquitously, PDPs are this set is well known and implemented ubiquitously, PDPs are
aware of it as well (either universally, through configuration, aware of it as well (either universally, through configuration,
or using the Client-Open message). The PDP may also include this or using the Client-Open message). The PDP may also include this
information in its decision, and the PEP should apply it to the information in its decision, and the PEP should apply it to the
resource allocation event that generated the request. resource allocation event that generated the request.
As an example, reservations may be admitted by a PDP contingent As an example, reservations may be admitted by a PDP contingent
on some type of per-session preemption priority. A RSVP PEP on some type of per-session preemption priority. A RSVP PEP
could have a set of stateless policy rules for when to preempt could have a set of stateless policy rules for when to preempt
other reservations in favor of a new one (e.g. higher-priority other reservations in favor of a new one (e.g. higher-priority
pre-empts any of lower priority). The PDP would need to include pre-empts any of lower priority). The PDP would need to include
appropriate priority information for each reservation in its appropriate priority information for each reservation in its
decisions that the PEP can use to apply its rules. decisions that the PEP can use to apply its rules.
CType = 3, Replacement Data C-Type = 3, Replacement Data
This object is typically applicable as a decision for an This type of decision object carries replacement data that is to
outgoing request. Format includes a list of client specific data replace existing data in a signaled message. It is a variable
that is to be used in place of information specified in the length object and its internal format should be specified in the
request. Use of this decision type is optional. For RSVP, this relevant COPS extension document for the given client-type. It
decision is used to change objects carried in RSVP messages. For is optional in Decision messages and is interpreted relative to
example, replacing the policy data objects when forwarding a a given context.
Resv message upstream is possible due to this decision type. If
this decision doesn't appear in a decision message, all signaled
objects are passed as if the PDP was not there. To remove an
object the decision should carry an empty object of length 4
(header only).
CType = 4, Client Specific Decision Data C-Type = 4, Client Specific Decision Data
Additional decision types can be introduced using the Client Additional decision types can be introduced using the Client
Specific Decision Data Object. Like the Replacement Data object, Specific Decision Data Object. It is a variable length object
client specific information is encapsulated within the Client and its internal format should be specified in the relevant COPS
Data Object. extension document for the given client-type. It is optional in
Decision messages and is interpreted relative to a given
context.
Ctype = 5, Named Decision Data C-Type = 5, Named Decision Data
Named configuration information should be encapsulated in this Named configuration information should be encapsulated in this
version of the decision object in response to configuration version of the decision object in response to configuration
requests. 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.
2.2.7 LDP Decision Object (LDPDecision) 2.2.7 LDP Decision Object (LDPDecision)
Decision made by the PEP's local decision point (LDP). May appear in Decision made by the PEP's local decision point (LDP). May appear in
requests. These objects correspond to and are formatted the same as requests. These objects correspond to and are formatted the same as
the client specific decision objects defined above. the client specific decision objects defined above.
C-Num = 8 C-Num = 8
CType = (same C-Type as for Decision objects) C-Type = (same C-Type as for Decision objects)
2.2.8 Error Object (Error) 2.2.8 Error Object (Error)
This object is used to identify a particular COPS protocol error. This object is used to identify a particular COPS protocol error.
The error sub-code field contains additional detailed client The error sub-code field contains additional detailed client
specific error codes. specific error codes. The appropriate Error Sub-codes for a
particular client-type should be specified in the relevant COPS
extensions document.
C-Num 9, C-Type = 1 C-Num 9, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code | | Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Error-Code: Error-Code:
1 = Bad handle 1 = Bad handle
2 = Invalid handle reference 2 = Invalid handle reference
3 = Bad message format 3 = Bad message format (Malformed Message)
4 = Unable to process (server gives up on query) 4 = Unable to process (server gives up on query)
5 = Mandatory client-specific info missing 5 = Mandatory client-specific info missing
6 = Unsupported client-type 6 = Unsupported client-type
7 = Mandatory COPS object missing 7 = Mandatory COPS object missing
8 = Client Failure 8 = Client Failure
9 = Communication Failure 9 = Communication Failure
10= Unspecified 10= Unspecified
11= Shutting down 11= Shutting down
2.2.9 Client Specific Information Object (ClientSI) 2.2.9 Client Specific Information Object (ClientSI)
The various types of this object are required for requests, and used The various types of this object are required for requests, and used
in reports and opens when required. It contains client-related in reports and opens when required. It contains client-type specific
information. information.
C-Num = 10, C-Num = 10,
C-Type = 1, Signaled ClientSI. C-Type = 1, Signaled ClientSI.
Variable-length field. All objects/attributes specific to a client's Variable-length field. All objects/attributes specific to a client's
signaling protocol or internal state must be encapsulated within one signaling protocol or internal state must be encapsulated within one
or more signaled Client Specific Information Objects. The format of or more signaled Client Specific Information Objects. The format of
the data encapsulated in the ClientSI object is determined by the the data encapsulated in the ClientSI object is determined by the
client-type. client-type.
C-Type = 2, Named ClientSI. C-Type = 2, Named ClientSI.
Variable-length field. Contains named configuration information Variable-length field. Contains named configuration information
useful for relaying specific information about the PEP, a request, useful for relaying specific information about the PEP, a request,
or configured state to the server. or configured state to the PDP server.
2.2.10 Timer Object (Timer) 2.2.10 Keep-Alive Timer Object (KATimer)
Times are encoded as 2 octet integer values and are in units of Times are encoded as 2 octet integer values and are in units of
seconds. The timer value is treated as a delta. seconds. The timer value is treated as a delta.
C-Num = 11, C-Num = 11,
C-Type = 1, Keep-alive timer value C-Type = 1, Keep-alive timer value
Timer object used to specify the maximum time interval over which a Timer object used to specify the maximum time interval over which a
COPS message must be sent or received. The value of zero implies COPS message must be sent or received. The value of zero implies
infinity. infinity.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ////////////// | KA Timer Value | | ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
C-Type = 2, Accounting timer value
Optional timer value used to determine the minimum interval between
periodic accounting type reports. The value of zero implies
infinity.
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+
2.2.11 PEP Identification Object (PEPID) 2.2.11 PEP Identification Object (PEPID)
The PEP Identification Object is used to identify the PEP client to The PEP Identification Object is used to identify the PEP client to
the remote PDP. It is required for Client-Open messages. the remote PDP. It is required for Client-Open messages.
C-Num = 12, C-Type = 1 C-Num = 12, C-Type = 1
Variable-length field (zero padded ASCII symbolic name) configured Variable-length field configured by local administrators for the
by local administrators for the PEP. For example, it can be the PEP. It is a NULL terminated ASCII string that is also zero padded
PEP's main IP address (not to be confused with the actual IP address to a 32-bit word boundary (so the object length is a multiple of 4
used in the persistent TCP connection). It may also be the PEP's DNS octets). For example, it can be the PEP's main IP address (not to be
name, or any other symbol that uniquely identifies each PEP within confused with the actual IP address used in the persistent TCP
the policy domain. The choice of configuration bears no significance connection). It may also be the PEP's DNS name, or any other symbol
for the COPS protocol, but does for policy at the PDP that may need that uniquely identifies each PEP within the policy domain. The
to uniquely identify individual PEPs. By default, at least the choice of configuration bears no significance for the COPS protocol,
primary IP address of the PEP represented as a string is expected in but does for policies at the PDP that may need to uniquely identify
the PEPID. individual PEPs. By default, at least the primary IP address of the
PEP represented as a string is expected in the PEPID.
2.2.12 Report-Type Object (Report-Type) 2.2.12 Report-Type Object (Report-Type)
The Type of Report on the request state associated with a handle: The Type of Report on the request state associated with a handle:
C-Num = 13, C-Type = 1 C-Num = 13, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Report-Type | ///////////// | | Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Report-Type: Report-Type:
1 = Commit : PEP's local resources now allocated 1 = Commit : PEP's local resources now allocated
2 = Accounting: Accounting update for an installed state 2 = Accounting: Accounting update for an installed state
3 = No Commit : PEP's resource allocation failure 3 = No Commit : PEP's resource allocation failure
4 = Installed : Named configuration installed 4 = Installed : Named configuration installed
5 = Removed : Named configuration removed 5 = Removed : Named configuration removed
6 = Enabled : Named configuration enabled 6 = NotInstall: Named configuration was not installed
7 = Disabled : Named configuration disabled 7 = NotRemoved: Named configuration was not removed
8 = Inst&Enab : Named config. installed and enabled
2.2.13 PDP Address (PDPAddr) 2.2.13 PDP Redirect Address (PDPRedirAddr)
A PDP when closing a PEP session for a particular client-type may A PDP when closing a PEP session for a particular client-type may
optionally use this object to redirect the PEP to another PDP server optionally use this object to redirect the PEP to another PDP
via this object: server:
C-Num = 14, C-Num = 14,
C-Type = 1, IPv4 Address (4 octets, as shown for In-interface) C-Type = 1, IPv4 Address (4 octets)
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
C-Type = 2, IPv6 Address (16 octets, as shown for In-interface) C-Type = 2, IPv6 Address (16 octets)
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
2.2.14 Last PDP Address (LastPDPAddr)
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.
C-Num = 15,
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 of
seconds. The timer value is treated as a delta.
C-Num = 16,
C-Type = 1, Accounting timer value
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 accounting updates via
Report messages where applicable. The value of zero implies there
are no timing constraints on accounting updates.
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+
2.3 Communication 2.3 Communication
The COPS protocol uses a single persistent TCP connection between The COPS protocol uses a single persistent TCP connection between
the PEP and a remote PDP. The remote PDP listens on a well-known the PEP and a remote PDP. The remote PDP listens on a well-known
port number (COPS=3288), and the PEP is responsible for initiating port number (COPS=3288 [IANA]), and the PEP is responsible for
the connection. The location of the remote PDP can either be initiating the connection. The location of the remote PDP can either
configured, or obtained via a service location mechanism [SRVLOC]. be configured, or obtained via a service location mechanism
Service discovery is outside the scope of this protocol, however. [SRVLOC]. Service discovery is outside the scope of this protocol,
however.
If a single PEP can support multiple client-types, it will send
multiple Client-Open messages, each specifying a particular client-
type to a PDP. The 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 for a given client-
type.
It is possible a single PEP may have open connections to multiple It is possible a single PEP may have open connections to multiple
PDPs. This is the case when there are physically different PDPs PDPs. This is the case when there are physically different PDPs
supporting different client-types as shown in figure 2. supporting different client-types as shown in figure 2.
+----------------+ +----------------+
| | | |
| Network Node | Policy Server | Network Node | Policy Servers
| | | |
| +-----+ | COPS Client Type 1 +-----+ | +-----+ | COPS Client Type 1 +-----+
| |PEP1 |<-----|-------------------->| PDP1| | | |<-----|-------------------->| PDP1|
| +-----+ | | COPS Client Type 2 +-----+ | + PEP + | COPS Client Type 2 +-----+
| ^ | PEP2|<--|---------\ +-----+ | | |<-----|---------\ +-----+
| | +-----+ | \----------| PDP2| | +-----+ | \----------| PDP2|
| \-->+-----+ | +-----+ | ^ | +-----+
| | |
| \-->+-----+ |
| | LDP | | | | LDP | |
| +-----+ | | +-----+ |
| | | |
+----------------+ +----------------+
Figure 2: Multiple PDPs illustration. Figure 2: Multiple PDPs illustration.
When a TCP connection is torn down or is lost, both the PEP and PDP When a TCP connection is torn down or is lost, the PDP is expected
is expected to clean up any outstanding state related to any to eventually clean up any outstanding request state related to
pervious request/decision exchanges. Additionally, the PEP should request/decision exchanges with the PEP. When the PEP detects a lost
continuously attempt to contact the primary PDP or, if unsuccessful, connection due to a timeout condition it should explicitly send a
any known backup PDPs. If a PEP is in communication with a backup Client-Close message for each opened client-type containing an
PDP and the primary PDP becomes available, the backup PDP should <Error> object indicating the "Communication Failure" Error-Code.
redirect the PEP back to the primary PDP (via a close/redirect Additionally, the PEP should continuously attempt to contact the
message for the affected client-type). 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 indicating the primary PDP to use for each
affected client-type).
2.4 Client Handle Usage 2.4 Client Handle Usage
The client handle is used to identify a unique request state. Client The client handle is used to identify a unique request state. Client
handles are chosen by the PEP and are opaque to the PDP. The PDP handles are chosen by the PEP and are opaque to the PDP. The PDP
simply uses the request handle to uniquely identify the request simply uses the request handle to uniquely identify the request
state and generically tie its decisions to a corresponding request. state and generically tie its decisions to a corresponding request.
Client handles are initiated in request messages and are then used Client handles are initiated in request messages and are then used
by subsequent request, decision, and report messages to reference by subsequent request, decision, and report messages to reference
the same request state. When the PEP is ready to remove a local 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 request state, it will issue a delete message to the PDP for the
corresponding client handle. A handle MUST be explicitly deleted by corresponding client handle. A handle MUST be explicitly deleted by
the PEP before it can be used to identify a new request state. the PEP before it can be used to identify a new request state.
Handles referring to different request states must be unique. Handles referring to different request states must be unique.
2.5 Synchronization Behavior
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. 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.
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.
A PEP that caches state from a previous exchange with a disconnected
PDP is expected to communicate this fact to any PDP with which it is
able to later reconnect. This is accomplished by including the
address of the last PDP for which the PEP is still caching state in
the Client-Open message. The <LastPDPAddr> object may 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 completing the synchronization process).
3. Message Content 3. Message Content
This section describes the basic messages exchanged between a PEP This section describes the basic messages exchanged between a PEP
and a remote PDP as well as their contents. 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. Malformed messages are to be silently
dropped unless otherwise specified.
3.1 Request (REQ) PEP -> PDP 3.1 Request (REQ) PEP -> PDP
The PEP establishes a request state client handle for which the The PEP establishes a request state client handle for which the
remote PDP may maintain a state. The remote PDP then uses this remote PDP may maintain a state. The remote PDP then uses this
handle to refer to the exchanged information and decisions. handle to refer to the exchanged information and decisions.
Once a stateful handle is established for a new request, any Once a stateful handle is established for a new request, any
subsequent modifications of the request can be made using the REQ subsequent modifications of the request can be made using the REQ
message specifying the previously installed handle. The PEP is message specifying the previously installed handle. The PEP is
responsible for notifying the PDP whenever its local state changes responsible for notifying the PDP whenever its local state changes
so the PDP's state will be able to accurately mirror the PEP's so the PDP's state will be able to accurately mirror the PEP's
state. state.
The format of the Request message is as follows: The format of the Request message is as follows:
<Request> ::= <Common Header> <Request Message> ::= <Common Header>
<Client Handle> <Client Handle>
<Context> <Context>
[<IN-Int>] [<IN-Int>]
[<OUT-Int>] [<OUT-Int>]
<ClientSI(s)> [<ClientSI(s)>]
[<LDPDecision>] [<LDPDecision(s)>]
<ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
<LDPDecision(s)> ::= <LDPDecision> |
<LDPDecision(s)> <LDPDecision>
The context object is used to determine the context within which all The context object is used to determine the context within which all
the other objects are to be interpreted. It also is used to the other objects are to be interpreted. It also is used to
determine the kind of decision to be returned from the policy determine the kind of decision to be returned from the policy
server. This decision might be related to admission control, server. This decision might be related to admission control,
resource allocation, object forwarding and substitution, or resource allocation, object forwarding and substitution, or
configuration. configuration.
The interface objects are used to determine the corresponding The interface objects are used to determine the corresponding
interface on which a signaling protocol message was received or is interface on which a signaling protocol message was received or is
about to be sent. They are typically used if the client is about to be sent. They are typically used if the client is
participating along the path of a signaling protocol or if the participating along the path of a signaling protocol or if the
client is requesting configuration data for a particular interface. client is requesting configuration data for a particular interface.
ClientSI, the client specific information object holds the client- ClientSI, the client specific information object, holds the client-
type specific data for which a policy decision needs to be made. In type specific data for which a policy decision needs to be made. In
the case of configuration, the named clientSI may include named the case of configuration, the Named ClientSI may include named
information about the module, interface, or functionality to be information about the module, interface, or functionality to be
configured. configured. The ordering of multiple ClientSIs is not important.
Finally, LDPDecision object holds information regarding the local Finally, LDPDecision object holds information regarding the local
decision made by the LDP. decision made by the LDP.
3.2 Decision (DEC) PDP -> PEP 3.2 Decision (DEC) PDP -> PEP
The PDP responds to the REQ with a DEC message that includes the The PDP responds to the REQ with a DEC message that includes the
associated client handle and one or more decision objects. If there associated client handle and one or more decision objects grouped
was a protocol error an error object is returned instead. relative to a Context object and Decision Flags object type pair. If
there was a protocol error an error object is returned instead.
It is assumed that the first decision for a new/updated request will It is assumed that the first decision for a new/updated request will
set the solicited decision flag. This avoids the issue of keeping set the solicited decision flag in all included Decision Flag object
track of which updated request (that is, a request reissued for the types. This avoids the issue of keeping track of which updated
same handle) a particular decision corresponds. It is important request (that is, a request reissued for the same handle) a
that, for a given handle, there be at most one outstanding solicited particular decision corresponds. It is important that, for a given
decision per request. This essentially means that the PEP should not handle, there be at most one outstanding solicited decision per
issue more than one REQ (for a given handle) before it receives a request. This essentially means that the PEP should not issue more
corresponding DEC with the solicited decision flag set. than one REQ (for a given handle) before it receives a corresponding
DEC with the solicited decision flag set.
To avoid deadlock, the client can always timeout after issuing a To avoid deadlock, the client can always timeout after issuing a
request. It must then delete the timed-out handle, and possibly try request. It must then delete the timed-out handle, and possibly try
again using a different (new) handle. again using a different (new) handle.
The format of the Decision message is as follows: The format of the Decision message is as follows:
<Decision> ::= <Common Header> <Decision Message> ::= <Common Header>
<Client Handle> <Client Handle>
<Context> <Decision(s)> | <Error>
<Decision(s)> || <Error>
The decision may include either an Error object or one or more <Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
decision objects. COPS protocol problems are reported in the Error
object (e.g. an error with the format of the original request). <Decision> ::= <Context>
Decision object(s) depend on the context and the type of client. <Decision: Flags>
[<Decision: Resource Alloc 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). 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 proceed
the other Decision object types per context binding.
3.3 Report State (RPT) PEP -> PDP 3.3 Report State (RPT) PEP -> PDP
This message is used by the PEP to communicate a change in the This message is used by the PEP to communicate a change in the
status of a previously installed state to the PDP. A commit or no- status of a previously installed state to the PDP. A commit or no-
commit report-type indicates to the PDP that a particular policy commit report-type indicates to the PDP that a particular policy
directive has or has not been acted upon as is relevant for directive has or has not been acted upon as is relevant for
accounting purposes. (In RSVP this would mean that a reservation accounting purposes. (In RSVP this would mean that a reservation
passed or failed local capacity admission control. For a passed or failed local capacity admission control [RSVP]. For a
configuration decision, it would mean the decision data either could configuration decision, it would mean the configuration identified
or could not be installed by the PEP). in the ClientSI either could or could not be installed by the PEP).
The Report State may also be used to provide periodic updates of The Report State may also be used to provide periodic updates of
client specific information for accounting and state monitoring client specific information for accounting and state monitoring
purposes depending on the type of the client. In such cases the purposes depending on the type of the client. In such cases the
accounting report type should be specified utilizing the client accounting report type should be specified utilizing the appropriate
specific information object. client specific information object.
<Report State> ::== <Common Header> <Report State> ::== <Common Header>
<Client Handle> <Client Handle>
<Report-Type> <Report-Type>
[<ClientSI(s)>] [<ClientSI>]
3.4 Delete Request State (DRQ) PEP -> PDP 3.4 Delete Request State (DRQ) PEP -> PDP
When sent from the PEP this message indicates to the remote PDP that When sent from the PEP this message indicates to the remote PDP that
the state identified by the client handle is no longer the state identified by the client handle is no longer
available/relevant. This information will then be used by the remote available/relevant. This information will then be used by the remote
PDP to initiate the appropriate housekeeping actions. The reason PDP to initiate the appropriate housekeeping actions. The reason
code object is interpreted with respect to the client-type and code object is interpreted with respect to the client-type and
signifies the reason for the removal. signifies the reason for the removal.
skipping to change at page 18, line 27 skipping to change at page 22, line 49
<Client Handle> <Client Handle>
<Reason> <Reason>
Given the stateful nature of COPS, it is important that when a Given the stateful nature of COPS, it is important that when a
request state is finally removed from the PEP, a DRQ message for 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 this request state is sent to the PDP so the corresponding state may
likewise be removed on the PDP. Request states not explicitly likewise be removed on the PDP. Request states not explicitly
deleted by the PEP will be maintained by the PDP until either the deleted by the PEP will be maintained by the PDP until either the
client session is closed or the connection is terminated. client session is closed or the connection is terminated.
Malformed Decision messages should trigger a DRQ specifying the
appropriate error code (Bad Message Format) and local state should
either be removed or re-requested.
3.5 Synchronize State Request (SSQ) PDP -> PEP 3.5 Synchronize State Request (SSQ) PDP -> PEP
The format of the Synchronize State Query message is as follows: The format of the Synchronize State Query message is as follows:
<Synchronize State> ::= <Common Header> <Synchronize State> ::= <Common Header>
[<Client Handle>] [<Client Handle>]
This message indicates that the remote PDP wishes the client (which This message indicates that the remote PDP wishes the client (which
appears in the common header) to re-send its state. If the optional appears in the common header) to re-send its state. If the optional
Client Handle is present, only the state associated with this handle Client Handle is present, only the state associated with this handle
skipping to change at page 18, line 51 skipping to change at page 23, line 25
with the PDP. with the PDP.
The client performs state synchronization by re-issuing request The client performs state synchronization by re-issuing request
queries of the specified client-type for the existing state in the queries of the specified client-type for the existing state in the
PEP. When synchronization is complete, the PEP must issue a PEP. When synchronization is complete, the PEP must issue a
synchronize state complete message to the PDP. synchronize state complete message to the PDP.
3.6 Client-Open (OPN) PEP -> PDP 3.6 Client-Open (OPN) PEP -> PDP
The Client-Open message can be used by the PEP to specify to the PDP The Client-Open message can be used by the PEP to specify to the PDP
the client-types the PEP can support, a *suggested* time interval the client-types the PEP can support, the last PDP to which the PEP
for keep-alive messages, and/or minimum time intervals for connected for the given client-type, and/or client specific feature
accounting updates, and/or client specific feature negotiation. A negotiation. A Client-Open message can be sent to the PDP at any
Client-Open message can be sent to the PDP at any time and multiple time and multiple Client-Open messages for the same client-type are
Client-Open messages for the same client-type are allowed (in case allowed (in case of global state changes).
of global state changes).
<Client-Open> ::= <Common Header> <Client-Open> ::= <Common Header>
<PEPID> <PEPID>
[<KA Timer>] [<ClientSI>]
[<ACCT Timer>] [<LastPDPAddr>]
[<Client ClientSI>]
The PEPID is a symbolic, variable length name that identifies the
specific client to the PDP. Values for the PEPID are configurable by
administrators of administrative domains and are of direct
significance to the COPS protocol. By default, the PEPID specifies
the primary IP address in the form of a string for the PEP in
question.
If included, the timer corresponds to PEP's preference for the The PEPID is a symbolic, variable length name that uniquely
maximum intermediate time between the generation of messages for identifies the specific client to the PDP.
connection verification and/or the minimum time interval between
periodic accounting reports.
Finally, a named ClientSI object can be included for relaying A named ClientSI object can be included for relaying additional
additional global information about the PEP to the PDP when required global information about the PEP to the PDP when required (as
(as specified in the appropriate extensions document for the client- specified in the appropriate extensions document for the client-
type). type).
Finally, the PEP may 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. If the PEP just rebooted (or otherwise
lost its state), the Last PDP Address object must NOT be included,
implying the PEP has lost all state associated with a previous PDP.
Likewise, if there are no longer any cached decisions being used by
the PEP the Last PDP Address object must not be included.
3.7 Client-Accept (CAT) PDP -> PEP 3.7 Client-Accept (CAT) PDP -> PEP
The Client-Accept message is used to positively respond to the The Client-Accept message is used to positively respond to the
Client-Open message. This message will return to the PEP a timer Client-Open message. This message will return to the PEP a timer
object indicating the maximum time interval between keep-alive object indicating the maximum time interval between keep-alive
messages. Optionally, a timer specifying the minimum allowed messages. Optionally, a timer specifying the minimum allowed
interval between accounting report messages may be included when interval between accounting report messages may be included when
applicable. applicable.
<Client-Accept> ::= <Common Header> <Client-Accept> ::= <Common Header>
<KA Timer> <KA Timer>
[<ACCT Timer>] [<ACCT Timer>]
If the PDP refuses the client, it will instead issue a Client-Close If the PDP refuses the client, it will instead issue a Client-Close
message. message.
The KA Timer corresponds to maximum acceptable intermediate time The KA Timer corresponds to maximum acceptable intermediate time
between the generation of messages by the PDP and PEP. The timer between the generation of messages by the PDP and PEP. The timer
value is determined by the PDP taking into account the client's value is determined by the PDP and is specified in seconds. A timer
preference established with the OPN message. A timer value of 0 value of 0 implies no secondary connection verification is
implies no secondary connection verification is necessary. necessary.
The optional accounting timer allows the PDP to indicate to the PEP The optional accounting timer allows the PDP to indicate to the PEP
that periodic accounting reports should not exceed the specified that periodic accounting reports should not exceed the specified
timer interval. This allows the PDP to control the rate at which timer interval. This allows the PDP to control the rate at which
accounting reports are sent by the PEP (when applicable). accounting reports are sent by the PEP (when applicable). 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).
3.8 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 3.8 Keep-Alive (KA) PEP -> PDP, PDP -> PEP
The keep-alive message only needs to be transmitted when there has The keep-alive message must be transmitted by the PEP within the
been no activity between the client and server for a period period defined by the minimum of all KA Timer values specified in
approaching half that of the minimum of all timer values negotiated all received CAT messages for the connection. A KA message must be
with the OPN & CAT messages. It is a validation for each side that generated randomly between 1/4 and 3/4 of this minimum TA timer
the connection is still functioning. 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.
Note: The client-type in the header should always be set to 0 as the Note: The client-type in the header should always be set to 0 as the
KA is used for connection verification (not per client session KA is used for connection verification (not per client session
verification). verification).
<Keep-Alive> ::= <Common Header> <Keep-Alive> ::= <Common Header>
Both client and server may assume the connection is insufficient for Both client and server may assume the TCP connection is insufficient
the client-type with the minimum time value (specified in the CAT for the client-type with the minimum time value (specified in the
message) if no communication activity is detected for a period CAT message) if no communication activity is detected for a period
exceeding the timer period. For the PEP, such detection implies the exceeding the timer period. For the PEP, such detection implies the
remote PDP or connection is down and the PEP should now attempt to remote PDP or connection is down and the PEP should now attempt to
use an alternative/backup PDP. use an alternative/backup PDP. Before the PEP terminates a timed-out
connection the PEP should explicitly issue a Client-Close message
for each client-type opened for the connection.
3.9 Client-Close (CC) PEP -> PDP, PDP -> PEP 3.9 Client-Close (CC) PEP -> PDP, PDP -> PEP
The Client-Close message can be issued by either the PDP or PEP to 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 notify the other that a particular type of client is no longer being
supported. supported.
<Client-Close> ::= <Common Header> <Client-Close> ::= <Common Header>
[<Error>] [<Error>]
[<PDPAddr>] [<PDPRedirAddr>]
An Error object is optionally included to describe the reason for An Error object is optionally included to describe the reason for
the close due to an error condition (e.g. requested client-type is the close due to an error condition (e.g. requested client-type is
not supported by the remote PDP or client failure). not supported by the remote PDP or client failure).
A PDP may optionally include a PDP-Address object in order to inform A PDP may optionally include a PDP Redirect Address object in order
the PEP of the alternate PDP it should use for the client-type to inform the PEP of the alternate PDP it should use for the client-
specified in the common header. type specified in the common header.
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.
This should be done before terminating the TCP connection and moving
on to a backup/alternative PDP.
3.10 Synchronize State Complete (SSC) PEP -> PDP 3.10 Synchronize State Complete (SSC) PEP -> PDP
The Synchronize State Complete is sent by the PEP to the PDP after 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 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 finished synchronization. It is useful so that the PDP will know
when all the old client state has been successfully re-requested when all the old client state has been successfully re-requested
and, thus, the PEP and PDP are completely synchronized. and, thus, the PEP and PDP are completely synchronized.
<Synchronize State Complete> ::= <Common Header> <Synchronize State Complete> ::= <Common Header>
skipping to change at page 21, line 4 skipping to change at page 26, line 4
3.10 Synchronize State Complete (SSC) PEP -> PDP 3.10 Synchronize State Complete (SSC) PEP -> PDP
The Synchronize State Complete is sent by the PEP to the PDP after 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 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 finished synchronization. It is useful so that the PDP will know
when all the old client state has been successfully re-requested when all the old client state has been successfully re-requested
and, thus, the PEP and PDP are completely synchronized. and, thus, the PEP and PDP are completely synchronized.
<Synchronize State Complete> ::= <Common Header> <Synchronize State Complete> ::= <Common Header>
4. Common Operation 4. Common Operation
This section describes the typical exchanges between remote PDP This section describes the typical exchanges between remote PDP
servers and PEP clients. servers and PEP clients.
4.1 PEP Initialization
Sometime after a connection is established between the PEP and a Sometime after a connection is established between the PEP and a
remote PDP, the PEP will send one or more Client-Open messages to remote PDP, the PEP will send one or more Client-Open messages to
the remote PDP, at least one for each client-type supported by the the remote PDP, one for each client-type supported by the PEP. The
PEP. The open message should contain the common header noting one Client-Open message must contain the address of the last PDP with
client-type supported by the PEP. The remote PDP will then respond which the PEP is still caching decisions. If no decisions are being
with a Client-Accept message echoing back each of the client-types cached from a previous PDP the LastPDPAddr object must not be
the PEP supports that it can support as well. If a specific client- included in the Client-Open message. Each Client-Open message should
type is not supported by the PDP, the PDP will instead respond with at least contain the common header noting one client-type supported
a Client-Close specifying the client-type is not supported and will by the PEP. The remote PDP will then respond with separate Client-
possibly suggest an alternate PDP address. Otherwise, the PDP will Accept messages for each of the client-types requested by the PEP
specify the timer interval between keep-alive messages in its that the PDP can also support.
Client-Accept and the PEP can begin issuing its requests to the PDP.
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.
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.
4.2 Outsourcing Operations
In the outsourcing scenario, when the PEP receives an event that In the outsourcing scenario, when the PEP receives an event that
requires a new policy decision it sends a request message to the requires a new policy decision it sends a request message to the
remote PDP. What specifically qualifies as an event for a particular remote PDP. What specifically qualifies as an event for a particular
client-type should be specified in the specific document for that client-type should be specified in the specific document for that
client-type. The remote PDP then makes a decision and sends a client-type. The remote PDP then makes a decision and sends a
decision message back to the PEP. Since the request is stateful, the decision message back to the PEP. Since the request is stateful, the
request will be remembered, or installed, on the remote PDP. The request will be remembered, or installed, on the remote PDP. The
unique handle, specified in both the request and its corresponding unique handle, specified in both the request and its corresponding
decision identifies this request state. The PEP is responsible for decision identifies this request state. The PEP is responsible for
skipping to change at page 21, line 43 skipping to change at page 27, line 5
The PEP can update a previously installed request state by reissuing The PEP can update a previously installed request state by reissuing
a request for the previously installed handle. The remote PDP is a request for the previously installed handle. The remote PDP is
then expected to make new decisions and send a decision message back then expected to make new decisions and send a decision message back
to the PEP. Likewise, the server may change a previously issued to the PEP. Likewise, the server may change a previously issued
decision on any currently installed request state at any time by decision on any currently installed request state at any time by
issuing another decision message. At all times the PEP module is issuing another decision message. At all times the PEP module is
expected to abide by the PDP's decisions and notify the PDP of any expected to abide by the PDP's decisions and notify the PDP of any
state changes. state changes.
Likewise, in the configuration scenario, the PEP will make a 4.3 Configuration Operations
configuration request to the PDP for a particular interface, module,
or functionality that may be specified in the named client specific In the configuration scenario, as in the outsourcing scenario, the
information object. The PDP will then send potentially several PEP will make a configuration request to the PDP for a particular
decisions containing named units of configuration data to the PEP. interface, module, or functionality that may be specified in the
The PEP is expected to install and use the configuration locally. A named client specific information object. The PDP will then send
particular named configuration can be updated by simply sending potentially several decisions containing named units of
additional decision messages for the same named configuration. When configuration data to the PEP. The PEP is expected to install and
the PDP no longer wishes the PEP to use a piece of configuration use the configuration locally. A particular named configuration can
information, it will send a decision message specifying the named be updated by simply sending additional decision messages for the
configuration and a decision flags object with the remove same named configuration. When the PDP no longer wishes the PEP to
configuration flag set. The PEP should then proceed to remove the use a piece of configuration information, it will send a decision
corresponding configuration and send a report message to the PDP message specifying the named configuration and a decision flags
that specifies it has been deleted. object with the remove configuration flag set. The PEP should then
proceed to remove the corresponding configuration and send a report
message to the PDP that specifies it has been deleted.
In all cases, the PEP may notify the remote PDP of the local status In all cases, the PEP may notify the remote PDP of the local status
of an installed state using the report message where appropriate. of an installed state using the report message where appropriate.
The report message is to be used to signify when billing should The report message is to be used to signify when billing should
begin, what actions were taken, or to produce periodic updates for begin, what actions were taken, or to produce periodic updates for
monitoring and accounting purposes depending on the client. This monitoring and accounting purposes depending on the client. This
message can carry client specific information when needed. message can carry client specific information when needed.
The keep-alive message is used to validate the connection between 4.4 Keep-Alive Operations
the client and server is still functioning when there is no other
messaging between the PEP and PDP. The PEP must generate a COPS The Keep-Alive message is used to validate the connection between
message within one half the negotiated minimum timer interval or the client and server is still functioning even when there is no
else a keep-alive message must be generated. Likewise, the PDP must other messaging from the PEP to PDP. The PEP must generate a COPS KA
either have sent a COPS message to every connected PEP within half message randomly within one-fourth to three-fourths the negotiated
the negotiated minimum timer interval or a keep-alive must be minimum KA Timer interval. On receiving a Keep-Alive message from
issued. If either side does not receive a keep-alive or any other the PEP, the PDP must then respond to this Keep-Alive message by
COPS message within the negotiated timer interval from the other, echoing a Keep-Alive message back to the PEP. If either side does
the connection should be considered lost. not receive a Keep-Alive or any other COPS message within the
negotiated timer interval from the other, the connection should be
considered lost.
4.5 PEP Shutdown
Finally, Client-Close messages are used to negate the effects of the Finally, Client-Close messages are used to negate the effects of the
corresponding Client-Open messages, notifying the other side that corresponding Client-Open messages, notifying the other side that
the specified client-type is no longer supported/active. the specified client-type is no longer supported/active. When a PEP
times out a TCP connection due to the keep-alive timer, it should
explicitly send a Client-Close message for each client-type opened
on the connection. Then the PEP may proceed to terminate the
connection to the PDP and attempt to reconnect again or try a
backup/alternative PDP.
5. Security 5. Security
The security of RSVP messages is provided by inter-router MD5 The security of RSVP messages is provided by inter-router MD5
authentication [MD5]. This assumes a chain-of-trust model for inter authentication [MD5]. This assumes a chain-of-trust model for inter
PEP authentication. Security between the client (PEP) and server PEP authentication. Security between the client (PEP) and server
(PDP) is provided by IPSEC [IPSEC]. (PDP) is provided by IPSEC [IPSEC].
To ensure the client (PEP) is communicating with the correct policy To ensure the client (PEP) is communicating with the correct policy
server (PDP) involves two issues: authentication of the policy server (PDP) involves two issues: authentication of the policy
client and server using a shared secret, and consistent proof that client and server using a shared secret, and consistent proof that
the connection remains valid. The shared secret requires manual the connection remains valid. The shared secret requires manual
configuration of keys, which is a maintenance issue. IPSEC AH may be configuration of keys, which is a maintenance issue. IPSEC AH may be
used for the validation of the connection; IPSEC ESP may be used to used for the validation of the connection; IPSEC ESP may be used to
provide both validation and secrecy. provide both validation and secrecy.
6. Open issues 6. IANA Considerations
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 common header's client-type
field are enterprise specific (these are client-types 0x8000 -
0xFFFF). All new client-type values within the range 0x0000-0x7FFF
must be registered with IANA and their behavior and applicability
should be described in a COPS extensions document.
7. References 7. References
[RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP)
Version 1 - Functional Specification", RFC 2205, September Version 1 - Functional Specification", RFC 2205, September
1997. 1997.
[WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission
Control", Internet-Draft, draft-ietf-rap-framework-00.txt, Control", Internet-Draft, draft-ietf-rap-framework-00.txt,
November 1997. November 1997.
skipping to change at page 26, line 5 skipping to change at page 30, line 36
Draft, draft-ietf-rsvp-md5-05.txt, August 1997. Draft, draft-ietf-rsvp-md5-05.txt, August 1997.
[RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP)
- Version 1 Message Processing Rules", RFC 2209, September - Version 1 Message Processing Rules", RFC 2209, September
1997. 1997.
[UserID]Yadav, S., Pabbati, R., Ford, P., Herzog, S., "User Identity [UserID]Yadav, S., Pabbati, R., Ford, P., Herzog, S., "User Identity
Representation for RSVP", Internet-Draft, draft-ietf-rap- Representation for RSVP", Internet-Draft, draft-ietf-rap-
user-identity-00.txt, March 1998. user-identity-00.txt, March 1998.
[IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers
8. Author Information and Acknowledgments 8. Author Information and Acknowledgments
Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar, Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs,
Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan, Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch
and Dimitrios Pendarakis for their valuable contributions. Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable
contributions.
Jim Boyle Ron Cohen Jim Boyle Ron Cohen
Level 3 Communications Cisco Systems Level 3 Communications Cisco Systems
1450 Infinite Drive13 Hasadna St. 1450 Infinite Drive13 Hasadna St.
Louisville, CO 80027 Ra'anana 43650 Israel Louisville, CO 80027 Ra'anana 43650 Israel
303.926.3100 972.9.7462020 303.926.3100 972.9.7462020
email: jboyle@l3.net ronc@classdata.com email: jboyle@l3.net ronc@classdata.com
David Durham Raju Rajan David Durham Raju Rajan
Intel IBM T.J. Watson Research Cntr Intel IBM T.J. Watson Research Cntr
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/