draft-ietf-rap-cops-07.txt   rfc2748.txt 
Internet Draft Jim Boyle
Expiration: January 2000 Level 3
File: draft-ietf-rap-cops-07.txt Ron Cohen
Cisco
Editor: David Durham
Intel
Shai Herzog
IPHighway
Raju Rajan
AT&T
Arun Sastry
Cisco
The COPS (Common Open Policy Service) Protocol Network Working Group D. Durham, Ed.
Request for Comments: 2748 Intel
Category: Standards Track J. Boyle
Level 3
R. Cohen
Cisco
S. Herzog
IPHighway
R. Rajan
AT&T
A. Sastry
Cisco
January 2000
Last Updated: August 16, 1999 The COPS (Common Open Policy Service) Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
Abstract
This document describes a simple client/server model for supporting
policy control over QoS signaling protocols. The model does not make
any assumptions about the methods of the policy server, but is based
on the server returning decisions to policy requests. The model is
designed to be extensible so that other kinds of policy clients may
be supported in the future. However, this document makes no claims
that it is the only or the preferred approach for enforcing future
types of policies.
Table Of Contents
Status of this Memo................................................1
Conventions used in this document..................................1
Abstract...........................................................3
1. Introduction....................................................3 1. Introduction....................................................3
1.1 Basic Model....................................................4 1.1 Basic Model....................................................4
2. The Protocol....................................................7 2. The Protocol....................................................6
2.1 Common Header..................................................7 2.1 Common Header..................................................6
2.2 COPS Specific Object Formats...................................8 2.2 COPS Specific Object Formats...................................8
2.2.1 Handle Object (Handle).......................................9 2.2.1 Handle Object (Handle).......................................9
2.2.2 Context Object (Context).....................................9 2.2.2 Context Object (Context).....................................9
2.2.3 In-Interface Object (IN-Int)................................10 2.2.3 In-Interface Object (IN-Int)................................10
2.2.4 Out-Interface Object (OUT-Int)..............................11 2.2.4 Out-Interface Object (OUT-Int)..............................11
2.2.5 Reason Object (Reason)......................................12 2.2.5 Reason Object (Reason)......................................12
2.2.6 Decision Object (Decision)..................................12 2.2.6 Decision Object (Decision)..................................12
2.2.7 LDP Decision Object (LDPDecision)...........................14 2.2.7 LPDP Decision Object (LPDPDecision).........................14
2.2.8 Error Object (Error)........................................14 2.2.8 Error Object (Error)........................................14
2.2.9 Client Specific Information Object (ClientSI)...............14 2.2.9 Client Specific Information Object (ClientSI)...............15
2.2.10 Keep-Alive Timer Object (KATimer)..........................15 2.2.10 Keep-Alive Timer Object (KATimer)..........................15
2.2.11 PEP Identification Object (PEPID)..........................15 2.2.11 PEP Identification Object (PEPID)..........................16
2.2.12 Report-Type Object (Report-Type)...........................15 2.2.12 Report-Type Object (Report-Type)...........................16
2.2.13 PDP Redirect Address (PDPRedirAddr)........................16 2.2.13 PDP Redirect Address (PDPRedirAddr)........................16
2.2.14 Last PDP Address (LastPDPAddr).............................16 2.2.14 Last PDP Address (LastPDPAddr).............................17
2.2.15 Accounting Timer Object (AcctTimer)........................17 2.2.15 Accounting Timer Object (AcctTimer)........................17
2.2.16 Message Integrity Object (Integrity).......................17 2.2.16 Message Integrity Object (Integrity).......................18
2.3 Communication.................................................18 2.3 Communication.................................................19
2.4 Client Handle Usage...........................................19 2.4 Client Handle Usage...........................................21
2.5 Synchronization Behavior......................................20 2.5 Synchronization Behavior......................................21
3. Message Content................................................21 3. Message Content................................................22
3.1 Request (REQ) PEP -> PDP.....................................21 3.1 Request (REQ) PEP -> PDP.....................................22
3.2 Decision (DEC) PDP -> PEP....................................22 3.2 Decision (DEC) PDP -> PEP....................................24
3.3 Report State (RPT) PEP -> PDP................................23 3.3 Report State (RPT) PEP -> PDP................................25
3.4 Delete Request State (DRQ) PEP -> PDP........................23 3.4 Delete Request State (DRQ) PEP -> PDP........................25
3.5 Synchronize State Request (SSQ) PDP -> PEP...................24 3.5 Synchronize State Request (SSQ) PDP -> PEP...................26
3.6 Client-Open (OPN) PEP -> PDP.................................25 3.6 Client-Open (OPN) PEP -> PDP.................................26
3.7 Client-Accept (CAT) PDP -> PEP...............................25 3.7 Client-Accept (CAT) PDP -> PEP...............................27
3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................26 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................28
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................26 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................28
3.10 Synchronize State Complete (SSC) PEP -> PDP..................27 3.10 Synchronize State Complete (SSC) PEP -> PDP..................29
4. Common Operation...............................................28 4. Common Operation...............................................29
4.1 Security and Sequence Number Negotiation......................28 4.1 Security and Sequence Number Negotiation......................29
4.2 Key Maintenance...............................................29 4.2 Key Maintenance...............................................31
4.3 PEP Initialization............................................30 4.3 PEP Initialization............................................31
4.4 Outsourcing Operations........................................30 4.4 Outsourcing Operations........................................32
4.5 Configuration Operations......................................31 4.5 Configuration Operations......................................32
4.6 Keep-Alive Operations.........................................31 4.6 Keep-Alive Operations.........................................33
4.7 PEP/PDP Close.................................................31 4.7 PEP/PDP Close.................................................33
5. Security Considerations........................................32 5. Security Considerations........................................33
6. IANA Considerations............................................33 6. IANA Considerations............................................34
7. References.....................................................34 7. References.....................................................35
8. Author Information and Acknowledgments.........................35 8. Author Information and Acknowledgments.........................36
9. Full Copyright Statement.......................................38
Abstract
This document describes a simple client/server model for supporting
policy control over QoS Signaling Protocols and provisioned QoS
resource management. It is designed to be extensible so that other
kinds of policy clients may be supported in the future. The model
does not make any assumptions about the methods of the policy
server, but is based on the server returning decisions to policy
requests.
1. Introduction 1. Introduction
This document describes a simple query and response protocol that This document describes a simple query and response protocol that can
can be used to exchange policy information between a policy server be used to exchange policy information between a policy server
(Policy Decision Point or PDP) and its clients (Policy Enforcement (Policy Decision Point or PDP) and its clients (Policy Enforcement
Points or PEPs). One example of a policy client is RSVP routers Points or PEPs). One example of a policy client is an RSVP router
that must exercise policy-based admission control over RSVP usage that must exercise policy-based admission control over RSVP usage
[RSVP]. We assume that at least one policy server exists in each [RSVP]. We assume that at least one policy server exists in each
controlled administrative domain. The basic model of interaction controlled administrative domain. The basic model of interaction
between a policy server and its clients is compatible with between a policy server and its clients is compatible with the
the framework document for policy based admission control [WRK]. framework document for policy based admission control [WRK].
A chief objective of policy control protocol is to begin with a A chief objective of this policy control protocol is to begin with a
simple but extensible design. The main characteristics of the COPS simple but extensible design. The main characteristics of the COPS
protocol include: protocol include:
1. The protocol employs a client/server model where the PEP 1. The protocol employs a client/server model where the PEP sends
sends requests, updates, and deletes to the remote PDP and the requests, updates, and deletes to the remote PDP and the PDP
PDP returns decisions back to the PEP. returns decisions back to the PEP.
2. The protocol uses TCP as its transport protocol for reliable 2. The protocol uses TCP as its transport protocol for reliable
exchange of messages between policy clients and a server. exchange of messages between policy clients and a server.
Therefore, no additional mechanisms are necessary for reliable Therefore, no additional mechanisms are necessary for reliable
communication between a server and its clients. communication between a server and its clients.
3. The protocol is extensible in that it is designed to leverage 3. The protocol is extensible in that it is designed to leverage
off self-identifying objects and can support diverse client off self-identifying objects and can support diverse client
specific information without requiring modifications to the COPS specific information without requiring modifications to the
protocol itself. The protocol was created for the general COPS protocol itself. The protocol was created for the general
administration, configuration, and enforcement of policies administration, configuration, and enforcement of policies.
whether signaled or provisioned. The protocol may be extended
for the administration of a variety of signaling protocols as
well as policy configuration on a device.
4. COPS provides message level security for authentication, 4. COPS provides message level security for authentication, replay
replay protection, and message integrity. COPS can also reuse protection, and message integrity. COPS can also reuse existing
existing protocols for security such as IPSEC [IPSEC] or TLS to protocols for security such as IPSEC [IPSEC] or TLS to
authenticate and secure the channel between the PEP and the PDP. authenticate and secure the channel between the PEP and the
PDP.
5. The protocol is stateful in two main aspects: 5. The protocol is stateful in two main aspects: (1)
(1) Request/Decision state is shared between client and server Request/Decision state is shared between client and server and
and (2) State from various events (Request/Decision pairs) may (2) State from various events (Request/Decision pairs) may be
be inter-associated. By (1) we mean that requests from the inter-associated. By (1) we mean that requests from the client
client PEP are installed or remembered by the remote PDP until PEP are installed or remembered by the remote PDP until they
they are explicitly deleted by the PEP. At the same time, are explicitly deleted by the PEP. At the same time, Decisions
Decisions from the remote PDP can be generated asynchronously at from the remote PDP can be generated asynchronously at any time
any time for a currently installed request state. By (2) we mean for a currently installed request state. By (2) we mean that
that the server may respond to new queries differently because the server may respond to new queries differently because of
of previously installed Request/Decision state(s) that are 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
allows the server to remove such state from the client when it then allows the server to remove such state from the client
is no longer applicable. when it 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 |
| +-----+ | +-----+ | +-----+ | +-----+
| ^ | | ^ |
| | | | | |
| \-->+-----+ | | \-->+-----+ |
| | LDP | | | | LPDP| |
| +-----+ | | +-----+ |
| | | |
+----------------+ +----------------+
Figure 1: A COPS illustration. Figure 1: A COPS illustration.
Figure 1 Illustrates the layout of various policy components in a Figure 1 Illustrates the layout of various policy components in a
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. The optional Local Decision Point (LDP) a particular type of client. The optional Local Policy Decision Point
can be used by the device to make local policy decisions in the (LPDP) can be used by the device to make local policy decisions in
absence of a PDP. the absence of a PDP.
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 is responsible for initiating a persistent TCP connection to The PEP is responsible for initiating a persistent TCP connection to
a PDP. The PEP uses this TCP connection to send requests to and a PDP. The PEP uses this TCP connection to send requests to and
receive decisions from the remote PDP. Communication between the PEP receive decisions from the remote PDP. Communication between the PEP
and remote PDP is mainly in the form of a stateful request/decision 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 successfully completed performing the PDP's decision that it has successfully completed performing the PDP's decision
locally, useful for accounting and monitoring purposes. The PEP is locally, useful for accounting and monitoring purposes. The PEP is
responsible for notifying the PDP when a request state has changed responsible for notifying the PDP when a request state has changed on
on the PEP. Finally, the PEP is responsible for the deletion of any the PEP. Finally, the PEP is responsible for the deletion of any
state that is no longer applicable due to events at the client or state that is no longer applicable due to events at the client or
decisions issued by the server. decisions issued by the server.
When the PEP sends a configuration request, it expects the PDP to When the PEP sends a configuration request, it expects the PDP to
continuously send named units of configuration data to the PEP via continuously send named units of configuration data to the PEP via
decision messages as applicable for the configuration request. When decision messages as applicable for the configuration request. When a
a unit of named configuration data is successfully installed on the unit of named configuration data is successfully installed on the
PEP, the PEP should send a report message to the PDP confirming the PEP, the PEP should send a report message to the PDP confirming the
installation. The server may then update or remove the named installation. The server may then update or remove the named
configuration information via a new decision message. When the PDP configuration information via a new decision message. When the PDP
sends a decision to remove named configuration data from the PEP, sends a decision to remove named configuration data from the PEP, the
the PEP will delete the specified configuration and send a report PEP will delete the specified configuration and send a report message
message to the PDP as confirmation. to the PDP as confirmation.
The policy protocol is designed to communicate self-identifying The policy protocol is designed to communicate self-identifying
objects which contain the data necessary for identifying request objects which contain the data necessary for identifying request
states, establishing the context for a request, identifying the type states, establishing the context for a request, identifying the type
of request, referencing previously installed requests, relaying of request, referencing previously installed requests, relaying
policy decisions, reporting errors, providing message integrity, and policy decisions, reporting errors, providing message integrity, and
transferring client specific/namespace information. transferring client specific/namespace information.
To distinguish between different kinds of clients, the type of To distinguish between different kinds of clients, the type of client
client is identified in each message. Different types of clients may is identified in each message. Different types of clients may have
have different client specific data and may require different kinds different client specific data and may require different kinds of
of policy decisions. It is expected that each new client-type will policy decisions. It is expected that each new client-type will have
have a corresponding usage draft specifying the specifics of its 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. The COPS Context object identifies the type of request
the arrival of an incoming message (2) allocation of local and message (if applicable) that triggered a policy event via its
resources, and (3) the forwarding of an outgoing message. Each of message type and request type fields. COPS identifies three types of
these events may require different decisions to be made. Context sub outsourcing events: (1) the arrival of an incoming message (2)
types are also available to describe the type of message that allocation of local resources, and (3) the forwarding of an outgoing
triggered the policy event. The content of a COPS request/decision message. Each of these events may require different decisions to be
message depends on the context. A fourth type of request is useful made. The content of a COPS request/decision message depends on the
for types of clients that wish to receive configuration information context. A fourth type of request is useful for types of clients that
from the PDP. This allows a PEP to issue a configuration request for wish to receive configuration information from the PDP. This allows a
a specific named device or module that requires configuration PEP to issue a configuration request for a specific named device or
information to be installed. module that requires configuration 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 Policy Decision Point (LPDP) [WRK], however, the PDP
the authoritative decision point at all times. This means that the remains the authoritative decision point at all times. This means
relevant local decision information must be relayed to the PDP. That that the relevant local decision information must be relayed to the
is, the PDP must be granted access to all relevant information to PDP. That is, the PDP must be granted access to all relevant
make a final policy decision. To facilitate this functionality, the information to make a final policy decision. To facilitate this
PEP must send its local decision information to the remote PDP via a functionality, the PEP must send its local decision information to
LDP decision object. The PEP must then abide by the PDP's decision the remote PDP via an LPDP decision object. The PEP must then abide
as it is absolute. by the PDP's decision 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
can be achieved by having both the PEP and remote PDP constantly can be achieved by having both the PEP and remote PDP constantly
verify their connection to each other via keep-alive messages. When verify their connection to each other via keep-alive messages. When a
a failure is detected, the PEP must try to reconnect to the remote failure is detected, the PEP must try to reconnect to the remote PDP
PDP or attempt to connect to a backup/alternative PDP. While or attempt to connect to a backup/alternative PDP. While
disconnected, the PEP should revert to making local decisions. Once disconnected, the PEP should revert to making local decisions. Once a
a connection is reestablished, the PEP is expected to notify the PDP connection is reestablished, the PEP is expected to notify the PDP of
of any deleted state or new events that passed local admission any deleted state or new events that passed local admission control
control after the connection was lost. Additionally, the remote PDP after the connection was lost. Additionally, the remote PDP may
may request that all the PEP's internal state be resynchronized (all request that all the PEP's internal state be resynchronized (all
previously installed requests are to be reissued). After failure and previously installed requests are to be reissued). After failure and
before the new connection is fully functional, disruption of service before the new connection is fully functional, disruption of service
can be minimized if the PEP caches previously communicated decisions can be minimized if the PEP caches previously communicated decisions
and continues to use them for some limited amount of time. Sections and continues to use them for some limited amount of time. Sections
2.3 and 2.5 detail COPS mechanisms for achieving reliability. 2.3 and 2.5 detail COPS mechanisms for achieving reliability.
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
of typed objects. typed objects.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
|Version| Flags| Op Code | Client-type | |Version| Flags| Op Code | Client-type |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Message Length | | Message Length |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Global note: //// implies field is reserved, set to 0. Global note: //// implies field is reserved, set to 0.
The fields in the header are: The fields in the header are:
Version: 4 bits Version: 4 bits
COPS version number. Current version is 1. COPS version number. Current version is 1.
Flags: 4 bits Flags: 4 bits
Defined flag values (all other flags MUST be set to 0): Defined flag values (all other flags MUST be set to 0):
0x1 Solicited Message Flag Bit 0x1 Solicited Message Flag Bit
This flag is set when the message is solicited by This flag is set when the message is solicited by
another COPS message. This flag is NOT to be set another COPS message. This flag is NOT to be set
skipping to change at page 7, line 50 skipping to change at page 7, line 31
4 = Delete Request State (DRQ) 4 = Delete Request State (DRQ)
5 = Synchronize State Req (SSQ) 5 = Synchronize State Req (SSQ)
6 = Client-Open (OPN) 6 = Client-Open (OPN)
7 = Client-Accept (CAT) 7 = Client-Accept (CAT)
8 = Client-Close (CC) 8 = Client-Close (CC)
9 = Keep-Alive (KA) 9 = Keep-Alive (KA)
10= Synchronize Complete (SSC) 10= 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). For KA Messages, the client-type in the header client-type IDs). For KA Messages, the client-type in the header
MUST always be set to 0 as the KA is used for connection MUST always be set to 0 as the KA is used for connection
verification (not per client session verification). 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
following format: following format:
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type | | Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// (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
added to the end of the object so that it is aligned to the next 32- to the end of the object so that it is aligned to the next 32-bit
bit boundary before the object can be sent on the wire. On the boundary before the object can be sent on the wire. On the receiving
receiving side, a subsequent object boundary can be found by simply side, a subsequent object boundary can be found by simply rounding up
rounding up the previous stated object length to the next 32-bit 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
the object, and the C-Type identifies the subtype or version of 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
2 = Context 2 = Context
3 = In Interface 3 = In Interface
4 = Out Interface 4 = Out Interface
5 = Reason code 5 = Reason code
6 = Decision 6 = Decision
7 = LDP Decision 7 = LPDP Decision
8 = Error 8 = Error
9 = Client Specific Info 9 = Client Specific Info
10 = Keep-Alive Timer 10 = Keep-Alive Timer
11 = PEP Identification 11 = PEP Identification
12 = Report Type 12 = Report Type
13 = PDP Redirect Address 13 = PDP Redirect Address
14 = Last PDP Address 14 = Last PDP Address
15 = Accounting Timer 15 = Accounting Timer
16 = Message Integrity 16 = Message Integrity
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.
operations. A state corresponding to a handle MUST be explicitly A state corresponding to a handle MUST be explicitly deleted when it
deleted when it is no longer applicable. See Section 2.4 for is no longer applicable. See Section 2.4 for details.
details.
C-Num = 1 C-Num = 1
C-Type = 1, Client Handle. C-Type = 1, Client Handle.
Variable-length field, no implied format other than it is unique Variable-length field, no implied format other than it is unique from
from other client handles from the same PEP (a.k.a. COPS TCP other client handles from the same PEP (a.k.a. COPS TCP connection)
connection) for a particular client-type. It is always initially for a particular client-type. It is always initially chosen by the
chosen by the PEP and then deleted by the PEP when no longer PEP and then deleted by the PEP when no longer applicable. The client
applicable. The client handle is used to refer to a request state handle is used to refer to a request state initiated by a particular
initiated by a particular PEP and installed at the PDP for a client- PEP and installed at the PDP for a client-type. A PEP will specify a
type. A PEP will specify a client handle in its Request messages, client handle in its Request messages, Report messages and Delete
Report messages and Delete messages sent to the PDP. In all cases, messages sent to the PDP. In all cases, the client handle is used to
the client handle is used to uniquely identify a particular PEP's uniquely identify a particular PEP's request for a client-type.
request for a client-type.
The client handle value is set by the PEP and is opaque to the PDP. The client handle value is set by the PEP and is opaque to the PDP.
The PDP simply performs a byte-wise comparison on the value in this The PDP simply performs a byte-wise comparison on the value in this
object with respect to the handle object values of other currently object with respect to the handle object values of other currently
installed requests. installed requests.
2.2.2 Context Object (Context) 2.2.2 Context Object (Context)
Specifies the type of event(s) that triggered the query. Required Specifies the type of event(s) that triggered the query. Required for
for request messages. Admission control, resource allocation, and request messages. Admission control, resource allocation, and
forwarding requests are all amenable to client-types that outsource forwarding requests are all amenable to client-types that outsource
their decision making facility to the PDP. For applicable client- their decision making facility to the PDP. For applicable client-
types a PEP can also make a request to receive named configuration types a PEP can also make a request to receive named configuration
information from the PDP. This named configuration data may be in a information from the PDP. This named configuration data may be in a
form useful for setting system attributes on a PEP, or it may be in form useful for setting system attributes on a PEP, or it may be in
the form of policy rules that are to be directly verified by the the form of policy rules that are to be directly verified by the PEP.
PEP.
Multiple flags can be set for the same request. This is only Multiple flags can be set for the same request. This is only allowed,
allowed, however, if the set of client specific information in the however, if the set of client specific information in the combined
combined request is identical to the client specific information request is identical to the client specific information that would be
that would be specified if individual requests were made for each specified if individual requests were made for each specified flag.
specified flag.
C-num = 2, C-Type = 1 C-num = 2, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| 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
skipping to change at page 10, line 25 skipping to change at page 10, line 22
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
on which a particular request applies and the address where the which a particular request applies and the address where the received
received message originated. For flows or messages generated from message originated. For flows or messages generated from the PEP's
the PEP's local host, the loop back address and ifindex are used. local host, the loop back address and ifindex are used.
This Interface object is also used to identify the incoming This Interface object is also used to identify the incoming
(receiving) interface via its ifindex. The ifindex may be used to (receiving) interface via its ifindex. The ifindex may be used to
differentiate between sub-interfaces and unnumbered interfaces (see differentiate between sub-interfaces and unnumbered interfaces (see
RSVP's LIH for an example). When SNMP is supported by the PEP, this 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 ifindex integer MUST correspond to the same integer value for the
interface in the SNMP MIB-II interface index table. interface in the SNMP MIB-II interface index table.
Note: The ifindex specified in the In-Interface is typically Note: The ifindex specified in the In-Interface is typically relative
relative to the flow of the underlying protocol messages. The to the flow of the underlying protocol messages. The ifindex is the
ifindex is the interface on which the protocol message was received. interface on which the protocol message was received.
C-Num = 3 C-Num = 3
C-Type = 1, IPv4 Address + Interface C-Type = 1, IPv4 Address + Interface
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| IPv4 Address format | | IPv4 Address format |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ifindex | | ifindex |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv4 address specifies For this type of the interface object, the IPv4 address specifies the
the IP address that the incoming message came from. IP address that the incoming message came from.
C-Type = 2, IPv6 Address + Interface C-Type = 2, IPv6 Address + Interface
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| | | |
+ + + +
| | | |
+ IPv6 Address format + + IPv6 Address format +
| | | |
+ + + +
| | | |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ifindex | | ifindex |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv6 address specifies For this type of the interface object, the IPv6 address specifies the
the IP address that the incoming message came from. The ifindex is IP address that the incoming message came from. The ifindex is used
used to refer to the MIB-II defined local incoming interface on the to refer to the MIB-II defined local incoming interface on the PEP as
PEP as described above. described above.
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
which a specific request applies and the address for where the a specific request applies and the address for where the forwarded
forwarded message is to be sent. For flows or messages destined to message is to be sent. For flows or messages destined to the PEP's
the PEP's local host, the loop back address and ifindex are used. local host, the loop back address and ifindex are used. The Out-
The Out-Interface has the same formats as the In-Interface Object. Interface has the same formats as the In-Interface Object.
This Interface object is also used to identify the outgoing This Interface object is also used to identify the outgoing
(forwarding) interface via its ifindex. The ifindex may be used to (forwarding) interface via its ifindex. The ifindex may be used to
differentiate between sub-interfaces and unnumbered interfaces (see differentiate between sub-interfaces and unnumbered interfaces (see
RSVP's LIH for an example). When SNMP is supported by the PEP, this 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 ifindex integer MUST correspond to the same integer value for the
interface in the SNMP MIB-II interface index table. interface in the SNMP MIB-II interface index table.
Note: The ifindex specified in the Out-Interface is typically Note: The ifindex specified in the Out-Interface is typically
relative to the flow of the underlying protocol messages. The relative to the flow of the underlying protocol messages. The ifindex
ifindex is the one on which a protocol message is about to be is the one on which a protocol message is about to be forwarded.
forwarded.
C-Num = 4 C-Num = 4
C-Type = 1, IPv4 Address + Interface C-Type = 1, IPv4 Address + Interface
Same C-Type format as the In-Interface object. The IPv4 address Same C-Type format as the In-Interface object. The IPv4 address
specifies the IP address to which the outgoing message is going. The specifies the IP address to which the outgoing message is going. The
ifindex is used to refer to the MIB-II defined local outgoing ifindex is used to refer to the MIB-II defined local outgoing
interface on the PEP. interface on the PEP.
skipping to change at page 13, line 24 skipping to change at page 13, line 37
C-Type = 2, Stateless Data C-Type = 2, Stateless Data
This type of decision object carries additional stateless This type of decision object carries additional stateless
information that can be applied by the PEP locally. It is a information that can be applied by the PEP locally. It is a
variable length object and its internal format SHOULD be variable length object and its internal format SHOULD be
specified in the relevant COPS extension document for the given specified in the relevant COPS extension document for the given
client-type. This object is optional in Decision messages and is client-type. This object is optional in Decision messages and is
interpreted relative to a given context. 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 LPDP. 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 MUST apply it to the information in its decision, and the PEP MUST apply it to the
resource allocation event that generated the request. resource allocation event that generated the request.
C-Type = 3, Replacement Data C-Type = 3, Replacement Data
This type of decision object carries replacement data that is to This type of decision object carries replacement data that is to
replace existing data in a signaled message. It is a variable replace existing data in a signaled message. It is a variable
length object and its internal format SHOULD be specified in the length object and its internal format SHOULD be specified in the
relevant COPS extension document for the given client-type. It relevant COPS extension document for the given client-type. It is
is optional in Decision messages and is interpreted relative to optional in Decision messages and is interpreted relative to a
a given context. given context.
C-Type = 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. It is a variable length object Specific Decision Data Object. It is a variable length object and
and its internal format SHOULD be specified in the relevant COPS its internal format SHOULD be specified in the relevant COPS
extension document for the given client-type. It is optional in extension document for the given client-type. It is optional in
Decision messages and is interpreted relative to a given Decision messages and is interpreted relative to a given context.
context.
C-Type = 5, Named Decision Data C-Type = 5, Named Decision Data
Named configuration information is encapsulated in this version Named configuration information is encapsulated in this version
of the decision object in response to configuration requests. It of the decision object in response to configuration requests. It
is a variable length object and its internal format SHOULD be is a variable length object and its internal format SHOULD be
specified in the relevant COPS extension document for the given specified in the relevant COPS extension document for the given
client-type. It is optional in Decision messages and is client-type. It is optional in Decision messages and is
interpreted relative to both a given context and decision flags. interpreted relative to both a given context and decision flags.
2.2.7 LDP Decision Object (LDPDecision) 2.2.7 LPDP Decision Object (LPDPDecision)
Decision made by the PEP's local decision point (LDP). May appear in Decision made by the PEP's local policy decision point (LPDP). May
requests. These objects correspond to and are formatted the same as appear in requests. These objects correspond to and are formatted the
the client specific decision objects defined above. same as the client specific decision objects defined above.
C-Num = 7 C-Num = 7
C-Type = (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
specific error codes. The appropriate Error Sub-codes for a error codes. The appropriate Error Sub-codes for a particular
particular client-type SHOULD be specified in the relevant COPS client-type SHOULD be specified in the relevant COPS extensions
extensions document. document.
C-Num = 8, C-Type = 1 C-Num = 8, 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:
skipping to change at page 15, line 15 skipping to change at page 15, line 37
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 are encapsulated within one or signaling protocol or internal state are encapsulated within one or
more signaled Client Specific Information Objects. The format of the more signaled Client Specific Information Objects. The format of the
data encapsulated in the ClientSI object is determined by 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
or configured state to the PDP server. configured state to the PDP server.
2.2.10 Keep-Alive Timer Object (KATimer) 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 = 10, C-Num = 10,
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 range of finite timeouts COPS message MUST be sent or received. The range of finite timeouts
is 1 to 65535 seconds represented as an unsigned two-octet integer. is 1 to 65535 seconds represented as an unsigned two-octet integer.
The value of zero implies infinity. The value of zero implies infinity.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ////////////// | KA Timer Value | | ////////////// | KA 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 = 11, C-Type = 1 C-Num = 11, C-Type = 1
Variable-length field. It is a NULL terminated ASCII string that is Variable-length field. It is a NULL terminated ASCII string that is
also zero padded to a 32-bit word boundary (so the object length is also zero padded to a 32-bit word boundary (so the object length is a
a multiple of 4 octets). The PEPID MUST contain an ASCII string that multiple of 4 octets). The PEPID MUST contain an ASCII string that
uniquely identifies the PEP within the policy domain in a manner uniquely identifies the PEP within the policy domain in a manner that
that is persistent across PEP reboots. For example, it may be the is persistent across PEP reboots. For example, it may be the PEP's
PEP's statically assigned IP address or DNS name. This identifier statically assigned IP address or DNS name. This identifier may
may safely be used by a PDP as a handle for identifying the PEP in safely be used by a PDP as a handle for identifying the PEP in its
its policy rules. policy rules.
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 = 12, C-Type = 1 C-Num = 12, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Report-Type | ///////////// | | Report-Type | ///////////// |
skipping to change at page 17, line 36 skipping to change at page 18, line 24
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value | | ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
2.2.16 Message Integrity Object (Integrity) 2.2.16 Message Integrity Object (Integrity)
The integrity object includes a sequence number and a message digest The integrity object includes a sequence number and a message digest
useful for authenticating and validating the integrity of a COPS useful for authenticating and validating the integrity of a COPS
message. When used, integrity is provided at the end of a COPS message. When used, integrity is provided at the end of a COPS
message as the last COPS object. The digest is then computed over message as the last COPS object. The digest is then computed over all
all of a particular COPS message up to but not including the digest of a particular COPS message up to but not including the digest value
value itself. The sender of a COPS message will compute and fill in itself. The sender of a COPS message will compute and fill in the
the digest portion of the Integrity object. The receiver of a COPS digest portion of the Integrity object. The receiver of a COPS
message will then compute a digest over the received message and message will then compute a digest over the received message and
verify it matches the digest in the received Integrity object. verify it matches the digest in the received Integrity object.
C-Num = 16, C-Num = 16,
C-Type = 1, HMAC digest C-Type = 1, HMAC digest
The HMAC integrity object employs HMAC (Keyed-Hashing for Message The HMAC integrity object employs HMAC (Keyed-Hashing for Message
Authentication) [HMAC] to calculate the message digest based on a Authentication) [HMAC] to calculate the message digest based on a key
key shared between the PEP and its PDP. shared between the PEP and its PDP.
This Integrity object specifies a 32-bit Key ID used to identify a This Integrity object specifies a 32-bit Key ID used to identify a
specific key shared between a particular PEP and its PDP and the specific key shared between a particular PEP and its PDP and the
cryptographic algorithm to be used. The Key ID allows for multiple cryptographic algorithm to be used. The Key ID allows for multiple
simultaneous keys to exist on the PEP with corresponding keys on the simultaneous keys to exist on the PEP with corresponding keys on the
PDP for the given PEPID. The key identified by the Key ID was used PDP for the given PEPID. The key identified by the Key ID was used to
to compute the message digest in the Integrity object. All compute the message digest in the Integrity object. All
implementations, at a minimum, MUST support HMAC-MD5-96, which is implementations, at a minimum, MUST support HMAC-MD5-96, which is
HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to
96-bits to calculate the message digest. 96-bits to calculate the message digest.
This object also includes a sequence number that is a 32-bit This object also includes a sequence number that is a 32-bit unsigned
unsigned integer used to avoid replay attacks. The sequence number integer used to avoid replay attacks. The sequence number is
is initiated during an initial Client-Open Client-Accept message initiated during an initial Client-Open Client-Accept message
exchange and is then incremented by one each time a new message is exchange and is then incremented by one each time a new message is
sent over the TCP connection in the same direction. If the sequence sent over the TCP connection in the same direction. If the sequence
number reaches the value of 0xFFFFFFFF, the next increment will number reaches the value of 0xFFFFFFFF, the next increment will
simply rollover to a value of zero. simply rollover to a value of zero.
The variable length digest is calculated over a COPS message The variable length digest is calculated over a COPS message starting
starting with the COPS Header up to the Integrity Object (which MUST with the COPS Header up to the Integrity Object (which MUST be the
be the last object in a COPS message) INCLUDING the Integrity last object in a COPS message) INCLUDING the Integrity object's
object's header, Key ID, and Sequence Number. The Keyed Message header, Key ID, and Sequence Number. The Keyed Message Digest field
Digest field is not included as part of the digest calculation. In is not included as part of the digest calculation. In the case of
the case of HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that is then to
is then to be truncated to 96-bits before being stored in or be truncated to 96-bits before being stored in or verified against
verified against the Keyed Message Digest field as specified in the Keyed Message Digest field as specified in [HMAC]. The Keyed
[HMAC]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is Message Digest MUST be 96-bits when HMAC-MD5-96 is used.
used.
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Key ID | | Key ID |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Sequence Number | | Sequence Number |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| ...Keyed Message Digest... | | ...Keyed Message Digest... |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
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
the PEP and a remote PDP. One PDP implementation per server MUST PEP and a remote PDP. One PDP implementation per server MUST listen
listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP on a well-known TCP port number (COPS=3288 [IANA]). The PEP is
is responsible for initiating the TCP connection to a PDP. The responsible for initiating the TCP connection to a PDP. The location
location of the remote PDP can either be configured, or obtained via of the remote PDP can either be configured, or obtained via a service
a service location mechanism [SRVLOC]. Service discovery is outside location mechanism [SRVLOC]. Service discovery is outside the scope
the scope of this protocol, however. of this protocol, however.
If a single PEP can support multiple client-types, it may send If a single PEP can support multiple client-types, it may send
multiple Client-Open messages, each specifying a particular client- multiple Client-Open messages, each specifying a particular client-
type to a PDP over one or more TCP connections. Likewise, a PDP type to a PDP over one or more TCP connections. Likewise, a PDP
residing at a given address and port number may support one or more residing at a given address and port number may support one or more
client-types. Given the client-types it supports, a PDP has the client-types. Given the client-types it supports, a PDP has the
ability to either accept or reject each client-type independently. ability to either accept or reject each client-type independently.
If a client-type is rejected, the PDP can redirect the PEP to an If a client-type is rejected, the PDP can redirect the PEP to an
alternative PDP address and TCP port for a given client-type via alternative PDP address and TCP port for a given client-type via
COPS. Different TCP port numbers can be used to redirect the PEP to COPS. Different TCP port numbers can be used to redirect the PEP to
another PDP implementation running on the same server. Additional another PDP implementation running on the same server. Additional
provisions for supporting multiple client-types (perhaps from provisions for supporting multiple client-types (perhaps from
independent PDP vendors) on a single remote PDP server are not independent PDP vendors) on a single remote PDP server are not
provided by the COPS protocol, but, rather, are left to the software provided by the COPS protocol, but, rather, are left to the software
architecture of the given server platform. architecture of the given server platform.
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.
skipping to change at page 19, line 28 skipping to change at page 20, line 24
| Network Node | Policy Servers | Network Node | Policy Servers
| | | |
| +-----+ | COPS Client Type 1 +-----+ | +-----+ | COPS Client Type 1 +-----+
| | |<-----|-------------------->| PDP1| | | |<-----|-------------------->| PDP1|
| + PEP + | COPS Client Type 2 +-----+ | + PEP + | COPS Client Type 2 +-----+
| | |<-----|---------\ +-----+ | | |<-----|---------\ +-----+
| +-----+ | \----------| PDP2| | +-----+ | \----------| PDP2|
| ^ | +-----+ | ^ | +-----+
| | | | | |
| \-->+-----+ | | \-->+-----+ |
| | LDP | | | | LPDP| |
| +-----+ | | +-----+ |
| | | |
+----------------+ +----------------+
Figure 2: Multiple PDPs illustration. Figure 2: Multiple PDPs illustration.
When a TCP connection is torn down or is lost, the PDP is expected When a TCP connection is torn down or is lost, the PDP is expected to
to eventually clean up any outstanding request state related to eventually clean up any outstanding request state related to
request/decision exchanges with the PEP. When the PEP detects a lost request/decision exchanges with the PEP. When the PEP detects a lost
connection due to a timeout condition it SHOULD explicitly send a connection due to a timeout condition it SHOULD explicitly send a
Client-Close message for each opened client-type containing an Client-Close message for each opened client-type containing an
<Error> object indicating the "Communication Failure" Error-Code. <Error> object indicating the "Communication Failure" Error-Code.
Additionally, the PEP SHOULD continuously attempt to contact the Additionally, the PEP SHOULD continuously attempt to contact the
primary PDP or, if unsuccessful, any known backup PDPs. Specifically primary PDP or, if unsuccessful, any known backup PDPs. Specifically
the PEP SHOULD keep trying all relevant PDPs with which it has been 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 configured until it can establish a connection. If a PEP is in
communication with a backup PDP and the primary PDP becomes communication with a backup PDP and the primary PDP becomes
available, the backup PDP is responsible for redirecting the PEP available, the backup PDP is responsible for redirecting the PEP back
back to the primary PDP (via a <Client-Close> message containing a to the primary PDP (via a <Client-Close> message containing a
<PDPRedirAddr> object identifying the primary PDP to use for each <PDPRedirAddr> object identifying the primary PDP to use for each
affected client-type). Section 2.5 details synchronization behavior affected client-type). Section 2.5 details synchronization behavior
between PEPs and PDPs. between PEPs and PDPs.
2.4 Client Handle Usage 2.4 Client Handle Usage
The client handle is used to identify a unique request state for a The client handle is used to identify a unique request state for a
single PEP per client-type. Client handles are chosen by the PEP and single PEP per client-type. Client handles are chosen by the PEP and
are opaque to the PDP. The PDP simply uses the request handle to are opaque to the PDP. The PDP simply uses the request handle to
uniquely identify the request state for a particular Client-Type uniquely identify the request state for a particular Client-Type over
over a particular TCP connection and generically tie its decisions a particular TCP connection and generically tie its decisions to a
to a corresponding request. Client handles are initiated in request corresponding request. Client handles are initiated in request
messages and are then used by subsequent request, decision, and messages and are then used by subsequent request, decision, and
report messages to reference the same request state. When the PEP is report messages to reference the same request state. When the PEP is
ready to remove a local request state, it will issue a delete ready to remove a local request state, it will issue a delete message
message to the PDP for the corresponding client handle. A handle to the PDP for the corresponding client handle. A handle MUST be
MUST be explicitly deleted by the PEP before it can be used by the explicitly deleted by the PEP before it can be used by the PEP to
PEP to identify a new request state. Handles referring to different identify a new request state. Handles referring to different request
request states MUST be unique within the context of a particular TCP states MUST be unique within the context of a particular TCP
connection and client-type. connection and client-type.
2.5 Synchronization Behavior 2.5 Synchronization Behavior
When disconnected from a PDP, the PEP SHOULD revert to making local When disconnected from a PDP, the PEP SHOULD revert to making local
decisions. Once a connection is reestablished, the PEP is expected decisions. Once a connection is reestablished, the PEP is expected to
to notify the PDP of any events that have passed local admission notify the PDP of any events that have passed local admission
control. Additionally, the remote PDP may request that all the PEP's control. Additionally, the remote PDP may request that all the PEP's
internal state be resynchronized (all previously installed requests internal state be resynchronized (all previously installed requests
are to be reissued) by sending a Synchronize State message. are to be reissued) by sending a Synchronize State message.
After a failure and before a new connection is fully functional, After a failure and before a new connection is fully functional,
disruption of service can be minimized if the PEP caches previously disruption of service can be minimized if the PEP caches previously
communicated decisions and continues to use them for some communicated decisions and continues to use them for some appropriate
appropriate length of time. Specific rules for such behavior are to length of time. Specific rules for such behavior are to be defined in
be defined in the appropriate COPS client-type extension the appropriate COPS client-type extension specifications.
specifications.
A PEP that caches state from a previous exchange with a disconnected A PEP that caches state from a previous exchange with a disconnected
PDP MUST communicate this fact to any PDP with which it is able to PDP MUST communicate this fact to any PDP with which it is able to
later reconnect. This is accomplished by including the address and later reconnect. This is accomplished by including the address and
TCP port of the last PDP for which the PEP is still caching state in TCP port of the last PDP for which the PEP is still caching state in
the Client-Open message. The <LastPDPAddr> object will only be the Client-Open message. The <LastPDPAddr> object will only be
included for the last PDP with which the PEP was completely in sync. included for the last PDP with which the PEP was completely in sync.
If the service interruption was temporary and the PDP still contains If the service interruption was temporary and the PDP still contains
the complete state for the PEP, the PDP may choose not to the complete state for the PEP, the PDP may choose not to synchronize
synchronize all states. It is still the responsibility of the PEP to all states. It is still the responsibility of the PEP to update the
update the PDP of all state changes that occurred during the PDP of all state changes that occurred during the disruption of
disruption of service including any states communicated to the service including any states communicated to the previous PDP that
previous PDP that had been deleted after the connection was lost. had been deleted after the connection was lost. These MUST be
These MUST be explicitly deleted after a connection is explicitly deleted after a connection is reestablished. If the PDP
reestablished. If the PDP issues a synchronize request the PEP MUST issues a synchronize request the PEP MUST pass all current states to
pass all current states to the PDP followed by a Synchronize State the PDP followed by a Synchronize State Complete message (thus
Complete message (thus completing the synchronization process). If completing the synchronization process). If the PEP crashes and loses
the PEP crashes and loses all cached state for a client-type, it all cached state for a client-type, it will simply not include a
will simply not include a <LastPDPAddr> in its Client-Open message. <LastPDPAddr> in its Client-Open message.
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
and a remote PDP as well as their contents. As a convention, object a remote PDP as well as their contents. As a convention, object
ordering is expected as shown in the BNF for each COPS message ordering is expected as shown in the BNF for each COPS message unless
unless otherwise noted. The Integrity object, if included, MUST otherwise noted. The Integrity object, if included, MUST always be
always be the last object in a message. If security is required and the last object in a message. If security is required and a message
a message was received without a valid Integrity object, the was received without a valid Integrity object, the receiver MUST send
receiver MUST send a Client-Close message for Client-Type=0 a Client-Close message for Client-Type=0 specifying the appropriate
specifying the appropriate error code. error code.
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 state. The remote PDP then uses this handle remote PDP may maintain state. The remote PDP then uses this handle
to refer to the exchanged information and decisions communicated to refer to the exchanged information and decisions communicated over
over the TCP connection to a particular PEP for a given client-type. the TCP connection to a particular PEP for a given client-type.
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
so the PDP's state will be able to accurately mirror the PEP's 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 Message> ::= <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(s)>] [<LPDPDecision(s)>]
[<Integrity>] [<Integrity>]
<ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI> <ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
<LDPDecision(s)> ::= <LDPDecision> | <LPDPDecision(s)> ::= <LPDPDecision> |
<LDPDecision(s)> <LDPDecision> <LPDPDecision(s)> <LPDPDecision>
<LPDPDecision> ::= [<Context>]
<LPDPDecision: Flags>
[<LPDPDecision: Stateless Data>]
[<LPDPDecision: Replacement Data>]
[<LPDPDecision: ClientSI Data>]
[<LPDPDecision: Named Data>]
The context object is used to determine the context within which all The 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
determine the kind of decision to be returned from the policy the kind of decision to be returned from the policy server. This
server. This decision might be related to admission control, decision might be related to admission control, resource allocation,
resource allocation, object forwarding and substitution, or 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
client is requesting configuration data for a particular interface. 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. The ordering of multiple ClientSIs is not important. configured. The ordering of multiple ClientSIs is not important.
Finally, LDPDecision object holds information regarding the local Finally, LPDPDecision object holds information regarding the local
decision made by the LDP. decision made by the LPDP.
Malformed Request messages MUST result in the PDP specifying a Malformed Request messages MUST result in the PDP specifying a
Decision message with the appropriate error code. Decision message with the appropriate error code.
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 grouped associated client handle and one or more decision objects grouped
relative to a Context object and Decision Flags object type pair. If relative to a Context object and Decision Flags object type pair. If
there was a protocol error an error object is returned instead. there was a protocol error an error object is returned instead.
skipping to change at page 22, line 38 skipping to change at page 24, line 24
COPS header. This avoids the issue of keeping track of which updated COPS header. This avoids the issue of keeping track of which updated
request (that is, a request reissued for the same handle) a request (that is, a request reissued for the same handle) a
particular decision corresponds. It is important that, for a given particular decision corresponds. It is important that, for a given
handle, there be at most one outstanding solicited decision per handle, there be at most one outstanding solicited decision per
request. This essentially means that the PEP SHOULD NOT issue more request. This essentially means that the PEP SHOULD NOT issue more
than one REQ (for a given handle) before it receives a corresponding than one REQ (for a given handle) before it receives a corresponding
DEC with the solicited message flag set. The PDP MUST always issue DEC with the solicited message flag set. The PDP MUST always issue
decisions for requests on a particular handle in the order they decisions for requests on a particular handle in the order they
arrive and all requests MUST have a corresponding decision. arrive and all requests MUST have a corresponding decision.
To avoid deadlock, the PEP can always timeout after issuing a To avoid deadlock, the PEP can always timeout after issuing a request
request that does not receive a decision. It MUST then delete the that does not receive a decision. It MUST then delete the timed-out
timed-out handle, and may try again using a new handle. handle, and may try again using a new handle.
The format of the Decision message is as follows: The format of the Decision message is as follows:
<Decision Message> ::= <Common Header> <Decision Message> ::= <Common Header>
<Client Handle> <Client Handle>
<Decision(s)> | <Error> <Decision(s)> | <Error>
[<Integrity>] [<Integrity>]
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision> <Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
<Decision> ::= <Context> <Decision> ::= <Context>
<Decision: Flags> <Decision: Flags>
[<Decision: Stateless Data>] [<Decision: Stateless Data>]
[<Decision: Replacement Data>] [<Decision: Replacement Data>]
[<Decision: ClientSI Data>] [<Decision: ClientSI Data>]
[<Decision: Named Data>] [<Decision: Named Data>]
The Decision message may include either an Error object or one or The Decision message may include either an Error object or one or
more context plus associated decision objects. COPS protocol more context plus associated decision objects. COPS protocol problems
problems are reported in the Error object (e.g. an error with the are reported in the Error object (e.g. an error with the format of
format of the original request including malformed request messages, the original request including malformed request messages, unknown
unknown COPS objects in the Request, etc.). The applicable Decision COPS objects in the Request, etc.). The applicable Decision object(s)
object(s) depend on the context and the type of client. The only depend on the context and the type of client. The only ordering
ordering requirement for decision objects is that the required requirement for decision objects is that the required Decision Flags
Decision Flags object type MUST precede the other Decision object object type MUST precede the other Decision object types per context
types per context binding. binding.
3.3 Report State (RPT) PEP -> PDP 3.3 Report State (RPT) PEP -> PDP
The RPT message is used by the PEP to communicate to the PDP its The RPT message is used by the PEP to communicate to the PDP its
success or failure in carrying out the PDP's decision, or to report success or failure in carrying out the PDP's decision, or to report
an accounting related change in state. The Report-Type specifies the an accounting related change in state. The Report-Type specifies the
kind of report and the optional ClientSI can carry additional kind of report and the optional ClientSI can carry additional
information per Client-Type. information per Client-Type.
For every DEC message containing a configuration context that is For every DEC message containing a configuration context that is
received by a PEP, the PEP MUST generate a corresponding Report received by a PEP, the PEP MUST generate a corresponding Report State
State message with the Solicited Message flag set describing its message with the Solicited Message flag set describing its success or
success or failure in applying the configuration decision. In failure in applying the configuration decision. In addition,
addition, outsourcing decisions from the PDP MAY result in a outsourcing decisions from the PDP MAY result in a corresponding
corresponding solicited Report State from the PEP depending on the solicited Report State from the PEP depending on the context and the
context and the type of client. RPT messages solicited by decisions type of client. RPT messages solicited by decisions for a given
for a given Client Handle MUST set the Solicited Message flag and Client Handle MUST set the Solicited Message flag and MUST be sent in
MUST be sent in the same order as their corresponding Decision the same order as their corresponding Decision messages were
messages were received. There MUST never be more than one Report received. There MUST never be more than one Report State message
State message generated with the Solicited Message flag set per generated with the Solicited Message flag set per Decision.
Decision.
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 appropriate accounting report type should be specified utilizing the appropriate
client specific information object. client specific information object.
<Report State> ::== <Common Header> <Report State> ::== <Common Header>
<Client Handle> <Client Handle>
<Report-Type> <Report-Type>
[<ClientSI>] [<ClientSI>]
[<Integrity>] [<Integrity>]
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
code object is interpreted with respect to the client-type and object is interpreted with respect to the client-type and signifies
signifies the reason for the removal. the reason for the removal.
The format of the Delete Request State message is as follows: The format of the Delete Request State message is as follows:
<Delete Request> ::= <Common Header> <Delete Request> ::= <Common Header>
<Client Handle> <Client Handle>
<Reason> <Reason>
[<Integrity>] [<Integrity>]
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
this request state is sent to the PDP so the corresponding state may 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
deleted by the PEP will be maintained by the PDP until either the by the PEP will be maintained by the PDP until either the client
client session is closed or the connection is terminated. session is closed or the connection is terminated.
Malformed Decision messages MUST trigger a DRQ specifying the Malformed Decision messages MUST trigger a DRQ specifying the
appropriate erroneous reason code (Bad Message Format) and any appropriate erroneous reason code (Bad Message Format) and any
associated state on the PEP SHOULD either be removed or re- associated state on the PEP SHOULD either be removed or re-requested.
requested. If a Decision contained an unknown COPS Decision Object, If a Decision contained an unknown COPS Decision Object, the PEP MUST
the PEP MUST delete its request specifying the Unknown COPS Object delete its request specifying the Unknown COPS Object reason code
reason code because the PEP will be unable to comply with the because the PEP will be unable to comply with the information
information contained in the unknown object. In any case, after contained in the unknown object. In any case, after issuing a DRQ,
issuing a DRQ, the PEP may retry the corresponding Request again. the PEP may retry the corresponding Request again.
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>]
[<Integrity>] [<Integrity>]
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
is synchronized. If the PEP does not recognize the requested handle, is synchronized. If the PEP does not recognize the requested handle,
it MUST immediately send a DRQ message to the PDP for the handle it MUST immediately send a DRQ message to the PDP for the handle that
that was specified in the SSQ message. If no handle is specified in was specified in the SSQ message. If no handle is specified in the
the SSQ message, all the active client state MUST be synchronized SSQ message, all the active client state MUST be synchronized with
with the PDP. 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, the last PDP to which the PEP the client-types the PEP can support, the last PDP to which the PEP
connected for the given client-type, and/or client specific feature connected for the given client-type, and/or client specific feature
negotiation. A Client-Open message can be sent to the PDP at any negotiation. A Client-Open message can be sent to the PDP at any time
time and multiple Client-Open messages for the same client-type are and multiple Client-Open messages for the same client-type are
allowed (in case of global state changes). allowed (in case of global state changes).
<Client-Open> ::= <Common Header> <Client-Open> ::= <Common Header>
<PEPID> <PEPID>
[<ClientSI>] [<ClientSI>]
[<LastPDPAddr>] [<LastPDPAddr>]
[<Integrity>] [<Integrity>]
The PEPID is a symbolic, variable length name that uniquely The PEPID is a symbolic, variable length name that uniquely
identifies the specific client to the PDP (see Section 2.2.11). identifies the specific client to the PDP (see Section 2.2.11).
A named ClientSI object can be included for relaying additional A named ClientSI object can be included for relaying additional
global information about the PEP to the PDP when required (as global information about the PEP to the PDP when required (as
specified in the appropriate extensions document for the client- specified in the appropriate extensions document for the client-
type). type).
The PEP may also provide a Last PDP Address object in its Client- The PEP may also provide a Last PDP Address object in its Client-Open
Open message specifying the last PDP (for the given client-type) for message specifying the last PDP (for the given client-type) for which
which it is still caching decisions since its last reboot. A PDP can it is still caching decisions since its last reboot. A PDP can use
use this information to determine the appropriate synchronization this information to determine the appropriate synchronization
behavior (See section 2.5). behavior (See section 2.5).
If the PDP receives a malformed Client-Open message it MUST generate If the PDP receives a malformed Client-Open message it MUST generate
a Client-Close message specifying the appropriate error code. a Client-Close message specifying the appropriate error code.
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
interval between accounting report messages may be included when 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>]
[<Integrity>] [<Integrity>]
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 and is specified in seconds. A timer value is determined by the PDP and is specified in seconds. A timer
value of 0 implies no secondary connection verification is value of 0 implies no secondary connection verification is necessary.
necessary.
The optional ACCT Timer allows the PDP to indicate to the PEP that The optional ACCT Timer allows the PDP to indicate to the PEP that
periodic accounting reports SHOULD NOT exceed the specified timer periodic accounting reports SHOULD NOT exceed the specified timer
interval per client handle. This allows the PDP to control the rate interval per client handle. This allows the PDP to control the rate
at which accounting reports are sent by the PEP (when applicable). at which accounting reports are sent by the PEP (when applicable).
In general, accounting type Report messages are sent to the PDP when In general, accounting type Report messages are sent to the PDP when
determined appropriate by the PEP. The accounting timer merely is 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. 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). Preventing the PEP from blasting the PDP with accounting reports).
Not including this object implies there are no PDP restrictions on Not including this object implies there are no PDP restrictions on
the rate at which accounting updates are generated. the rate at which accounting updates are generated.
If the PEP receives a malformed Client-Accept message it MUST If the PEP receives a malformed Client-Accept message it MUST
generate a Client-Close message specifying the appropriate error generate a Client-Close message specifying the appropriate error
code. code.
skipping to change at page 26, line 35 skipping to change at page 28, line 28
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>
[<PDPRedirAddr>] [<PDPRedirAddr>]
[<Integrity>] [<Integrity>]
The Error object is included to describe the reason for the close The Error object is included to describe the reason for the close
(e.g. the requested client-type is not supported by the remote PDP (e.g. the requested client-type is not supported by the remote PDP or
or client failure). client failure).
A PDP MAY optionally include a PDP Redirect Address object in order A PDP MAY optionally include a PDP Redirect Address object in order
to inform the PEP of the alternate PDP it SHOULD use for the client- to inform the PEP of the alternate PDP it SHOULD use for the client-
type specified in the common header. type specified in the common header.
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP
The keep-alive message MUST be transmitted by the PEP within the The keep-alive message MUST be transmitted by the PEP within the
period defined by the minimum of all KA Timer values specified in period defined by the minimum of all KA Timer values specified in all
all received CAT messages for the connection. A KA message MUST be received CAT messages for the connection. A KA message MUST be
generated randomly between 1/4 and 3/4 of this minimum KA timer generated randomly between 1/4 and 3/4 of this minimum KA timer
interval. When the PDP receives a keep-alive message from a PEP, it 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 MUST echo a keep-alive back to the PEP. This message provides
validation for each side that the connection is still functioning validation for each side that the connection is still functioning
even when there is no other messaging. even when there is no other messaging.
Note: The client-type in the header MUST always be set to 0 as the Note: The client-type in the header MUST always be set to 0 as the KA
KA is used for connection verification (not per client session is used for connection verification (not per client session
verification). verification).
<Keep-Alive> ::= <Common Header> <Keep-Alive> ::= <Common Header>
[<Integrity>] [<Integrity>]
Both client and server MAY assume the TCP connection is insufficient Both client and server MAY assume the TCP connection is insufficient
for the client-type with the minimum time value (specified in the for the client-type with the minimum time value (specified in the CAT
CAT message) if no communication activity is detected for a period 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.
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
when all the old client state has been successfully re-requested all the old client state has been successfully re-requested and,
and, thus, the PEP and PDP are completely synchronized. The Client thus, the PEP and PDP are completely synchronized. The Client Handle
Handle object only needs to be included if the corresponding object only needs to be included if the corresponding Synchronize
Synchronize State Message originally referenced a specific handle. State Message originally referenced a specific handle.
<Synchronize State Complete> ::= <Common Header> <Synchronize State Complete> ::= <Common Header>
[<Client Handle>] [<Client Handle>]
[<Integrity>] [<Integrity>]
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.
skipping to change at page 28, line 24 skipping to change at page 29, line 45
security is required, it MUST be negotiated during the initial security is required, it MUST be negotiated during the initial
Client-Open/Client-Accept message exchange specifying a Client-Type Client-Open/Client-Accept message exchange specifying a Client-Type
of zero (which is reserved for connection level security negotiation of zero (which is reserved for connection level security negotiation
and connection verification). and connection verification).
If a PEP is not configured to use COPS security with a PDP it will If a PEP is not configured to use COPS security with a PDP it will
simply send the PDP Client-Open messages for the supported Client- simply send the PDP Client-Open messages for the supported Client-
Types as specified in section 4.3 and will not include the Integrity Types as specified in section 4.3 and will not include the Integrity
object in any COPS messages. object in any COPS messages.
Otherwise, security can be initiated by the PEP if it sends the PDP Otherwise, security can be initiated by the PEP if it sends the PDP a
a Client-Open message with Client-Type=0 before opening any other Client-Open message with Client-Type=0 before opening any other
Client-Type. If the PDP receives a Client-Open with a Client-Type=0 Client-Type. If the PDP receives a Client-Open with a Client-Type=0
after another Client-Type has already been opened successfully it after another Client-Type has already been opened successfully it
MUST return a Client-Close message (for Client-Type=0) to that PEP. MUST return a Client-Close message (for Client-Type=0) to that PEP.
This first Client-Open message MUST specify a Client-Type of zero This first Client-Open message MUST specify a Client-Type of zero and
and MUST provide the PEPID and a COPS Integrity object. This MUST provide the PEPID and a COPS Integrity object. This Integrity
Integrity object will contain the initial sequence number the PEP object will contain the initial sequence number the PEP requires the
requires the PDP to increment during subsequent communication after PDP to increment during subsequent communication after the initial
the initial Client-Open/Client-Accept exchange and the Key ID Client-Open/Client-Accept exchange and the Key ID identifying the
identifying the algorithm and key used to compute the digest. algorithm and key used to compute the digest.
Similarly, if the PDP accepts the PEP's security key and algorithm Similarly, if the PDP accepts the PEP's security key and algorithm by
by validating the message digest using the identified key, the PDP validating the message digest using the identified key, the PDP MUST
MUST send a Client-Accept message with a Client-Type of zero to the send a Client-Accept message with a Client-Type of zero to the PEP
PEP carrying an Integrity object. This Integrity object will contain carrying an Integrity object. This Integrity object will contain the
the initial sequence number the PDP requires the PEP to increment initial sequence number the PDP requires the PEP to increment during
during all subsequent communication with the PDP and the Key ID all subsequent communication with the PDP and the Key ID identifying
identifying the key and algorithm used to compute the digest. the key and algorithm used to compute the digest.
If the PEP, from the perspective of a PDP that requires security, If the PEP, from the perspective of a PDP that requires security,
fails or never performs the security negotiation by not sending an fails or never performs the security negotiation by not sending an
initial Client-Open message with a Client-Type=0 including a valid initial Client-Open message with a Client-Type=0 including a valid
Integrity object, the PDP MUST send to the PEP a Client-Close Integrity object, the PDP MUST send to the PEP a Client-Close message
message with a Client-Type=0 specifying the appropriate error code. with a Client-Type=0 specifying the appropriate error code.
Similarly, if the PDP, from the perspective of a PEP that requires Similarly, if the PDP, from the perspective of a PEP that requires
security, fails the security negotiation by not sending back a security, fails the security negotiation by not sending back a
Client-Accept message with a Client-Type=0 including a valid Client-Accept message with a Client-Type=0 including a valid
Integrity object, the PEP MUST send to the PDP a Client-Close Integrity object, the PEP MUST send to the PDP a Client-Close message
message with a Client-Type=0 specifying the appropriate error code. with a Client-Type=0 specifying the appropriate error code. Such a
Such a Client-Close message need not carry an integrity object (as Client-Close message need not carry an integrity object (as the
the security negotiation did not yet complete). security negotiation did not yet complete).
The security initialization can fail for one of several reasons: 1. The security initialization can fail for one of several reasons: 1.
The side receiving the message requires COPS level security but an The side receiving the message requires COPS level security but an
Integrity object was not provided (Authentication Required error Integrity object was not provided (Authentication Required error
code). 2. A COPS Integrity object was provided, but with an code). 2. A COPS Integrity object was provided, but with an
unknown/unacceptable C-Type (Unknown COPS Object error code unknown/unacceptable C-Type (Unknown COPS Object error code
specifying the unsupported C-Num and C-Type). 3. The message digest specifying the unsupported C-Num and C-Type). 3. The message digest
or Key ID in the provided Integrity object was incorrect and or Key ID in the provided Integrity object was incorrect and
therefore the message could not be authenticated using the therefore the message could not be authenticated using the identified
identified key (Authentication Failure error code). key (Authentication Failure error code).
Once the initial security negotiation is complete, the PEP will know Once the initial security negotiation is complete, the PEP will know
what sequence numbers the PDP expects and the PDP will know what what sequence numbers the PDP expects and the PDP will know what
sequence numbers the PEP expects. ALL COPS messages must then sequence numbers the PEP expects. ALL COPS messages must then include
include the negotiated Integrity object specifying the correct the negotiated Integrity object specifying the correct sequence
sequence number with the appropriate message digest (including the number with the appropriate message digest (including the Client-
Client-Open/Client-Accept messages for specific Client-Types). ALL Open/Client-Accept messages for specific Client-Types). ALL
subsequent messages from the PDP to the PEP MUST result in an subsequent messages from the PDP to the PEP MUST result in an
increment of the sequence number provided by the PEP in the increment of the sequence number provided by the PEP in the Integrity
Integrity object of the initial Client-Open message. Likewise, ALL object of the initial Client-Open message. Likewise, ALL subsequent
subsequent messages from the PEP to the PDP MUST result in an messages from the PEP to the PDP MUST result in an increment of the
increment of the sequence number provided by the PDP in the sequence number provided by the PDP in the Integrity object of the
Integrity object of the initial Client-Accept message. Sequence initial Client-Accept message. Sequence numbers are incremented by
numbers are incremented by one starting with the corresponding one starting with the corresponding initial sequence number. For
initial sequence number. For example, if the sequence number example, if the sequence number specified to the PEP by the PDP in
specified to the PEP by the PDP in the initial Client-Accept was 10, the initial Client-Accept was 10, the next message the PEP sends to
the next message the PEP sends to the PDP will provide an Integrity the PDP will provide an Integrity object with a sequence number of
object with a sequence number of 11... Then the next message the PEP 11... Then the next message the PEP sends to the PDP will have a
sends to the PDP will have a sequence number of 12 and so on. If any sequence number of 12 and so on. If any subsequent received message
subsequent received message contains the wrong sequence number, an contains the wrong sequence number, an unknown Key ID, an invalid
unknown Key ID, an invalid message digest, or is missing an message digest, or is missing an Integrity object after integrity was
Integrity object after integrity was negotiated, then a Client-Close negotiated, then a Client-Close message MUST be generated for the
message MUST be generated for the Client-Type zero containing a Client-Type zero containing a valid Integrity object and specifying
valid Integrity object and specifying the appropriate error code. the appropriate error code. The connection should then be dropped.
The connection should then be dropped.
4.2 Key Maintenance 4.2 Key Maintenance
Key maintenance is outside the scope of this document, but COPS Key maintenance is outside the scope of this document, but COPS
implementations MUST at least provide the ability to manually implementations MUST at least provide the ability to manually
configure keys and their parameters locally. The key used to produce configure keys and their parameters locally. The key used to produce
the Integrity object's message digest is identified by the Key ID the Integrity object's message digest is identified by the Key ID
field. Thus, a Key ID parameter is used to identify one of field. Thus, a Key ID parameter is used to identify one of
potentially multiple simultaneous keys shared by the PEP and PDP. A potentially multiple simultaneous keys shared by the PEP and PDP. A
Key ID is relative to a particular PEPID on the PDP or to a Key ID is relative to a particular PEPID on the PDP or to a
particular PDP on the PEP. Each key must also be configured with particular PDP on the PEP. Each key must also be configured with
lifetime parameters for the time period within which it is valid as lifetime parameters for the time period within which it is valid as
well as an associated cryptographic algorithm parameter specifying well as an associated cryptographic algorithm parameter specifying
the algorithm to be used with the key. At a minimum, all COPS the algorithm to be used with the key. At a minimum, all COPS
implementations MUST support the HMAC-MD5-96 [HMAC][MD5] implementations MUST support the HMAC-MD5-96 [HMAC][MD5]
cryptographic algorithm for computing a message digest for inclusion cryptographic algorithm for computing a message digest for inclusion
in the Keyed Message Digest of the Integrity object which is in the Keyed Message Digest of the Integrity object which is appended
appended to the message. to the message.
It is good practice to regularly change keys. Keys MUST be It is good practice to regularly change keys. Keys MUST be
configurable such that their lifetimes overlap allowing smooth configurable such that their lifetimes overlap allowing smooth
transitions between keys. At the midpoint of the lifetime overlap transitions between keys. At the midpoint of the lifetime overlap
between two keys, senders should transition from using the current between two keys, senders should transition from using the current
key to the next/longer-lived key. Meanwhile, receivers simply accept key to the next/longer-lived key. Meanwhile, receivers simply accept
any identified key received within its configured lifetime and any identified key received within its configured lifetime and reject
reject those that are not. those that are not.
4.3 PEP Initialization 4.3 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 and after security is negotiated (if required), the PEP remote PDP and after security is negotiated (if required), the PEP
will send one or more Client-Open messages to the remote PDP, one will send one or more Client-Open messages to the remote PDP, one for
for each client-type supported by the PEP. The Client-Open message each client-type supported by the PEP. The Client-Open message MUST
MUST contain the address of the last PDP with which the PEP is still contain the address of the last PDP with which the PEP is still
caching a complete set of decisions. If no decisions are being caching a complete set of decisions. If no decisions are being cached
cached from the previous PDP the LastPDPAddr object MUST NOT be from the previous PDP the LastPDPAddr object MUST NOT be included in
included in the Client-Open message (see Section 2.5). Each Client- the Client-Open message (see Section 2.5). Each Client-Open message
Open message MUST at least contain the common header noting one MUST at least contain the common header noting one client-type
client-type supported by the PEP. The remote PDP will then respond supported by the PEP. The remote PDP will then respond with separate
with separate Client-Accept messages for each of the client-types Client-Accept messages for each of the client-types requested by the
requested by the PEP that the PDP can also support. PEP that the PDP can also support.
If a specific client-type is not supported by the PDP, the PDP will 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 instead respond with a Client-Close specifying the client-type is not
not supported and will possibly suggest an alternate PDP address and supported and will possibly suggest an alternate PDP address and
port. Otherwise, the PDP will send a Client-Accept specifying the port. Otherwise, the PDP will send a Client-Accept specifying the
timer interval between keep-alive messages and the PEP may begin timer interval between keep-alive messages and the PEP may begin
issuing requests to the PDP. issuing requests to the PDP.
4.4 Outsourcing Operations 4.4 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 (unique per TCP connection and client-type), specified unique handle (unique per TCP connection and client-type), specified
in both the request and its corresponding decision identifies this in both the request and its corresponding decision identifies this
request state. The PEP is responsible for deleting this request request state. The PEP is responsible for deleting this request state
state once the request is no longer applicable. once the request is no longer applicable.
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
then expected to make new decisions and send a decision message back expected to make new decisions and send a decision message back to
to the PEP. Likewise, the server MAY change a previously issued the PEP. Likewise, the server MAY change a previously issued decision
decision on any currently installed request state at any time by on any currently installed request state at any time by issuing an
issuing an unsolicited decision message. At all times the PEP module unsolicited decision message. At all times the PEP module is expected
is expected to abide by the PDP's decisions and notify the PDP of to abide by the PDP's decisions and notify the PDP of any state
any state changes. changes.
4.5 Configuration Operations 4.5 Configuration Operations
In the configuration scenario, as in the outsourcing scenario, the In the configuration scenario, as in the outsourcing scenario, the
PEP will make a configuration request to the PDP for a particular PEP will make a configuration request to the PDP for a particular
interface, module, or functionality that may be specified in the interface, module, or functionality that may be specified in the
named client specific information object. The PDP will then send named client specific information object. The PDP will then send
potentially several decisions containing named units of potentially several decisions containing named units of configuration
configuration data to the PEP. The PEP is expected to install and data to the PEP. The PEP is expected to install and use the
use the configuration locally. A particular named configuration can configuration locally. A particular named configuration can be
be updated by simply sending additional decision messages for the updated by simply sending additional decision messages for the same
same named configuration. When the PDP no longer wishes the PEP to named configuration. When the PDP no longer wishes the PEP to use a
use a piece of configuration information, it will send a decision piece of configuration information, it will send a decision message
message specifying the named configuration and a decision flags specifying the named configuration and a decision flags object with
object with the remove configuration command. The PEP SHOULD then the remove configuration command. The PEP SHOULD then proceed to
proceed to remove the corresponding configuration and send a report remove the corresponding configuration and send a report message to
message to the PDP that specifies it has been deleted. 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 can begin, The report message is to be used to signify when billing can begin,
what actions were taken, or to produce periodic updates for 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.
4.6 Keep-Alive Operations 4.6 Keep-Alive Operations
The Keep-Alive message is used to validate the connection between The Keep-Alive message is used to validate the connection between the
the client and server is still functioning even when there is no client and server is still functioning even when there is no other
other messaging from the PEP to PDP. The PEP MUST generate a COPS KA messaging from the PEP to PDP. The PEP MUST generate a COPS KA
message randomly within one-fourth to three-fourths the minimum KA message randomly within one-fourth to three-fourths the minimum KA
Timer interval specified by the PDP in the Client-Accept message. On Timer interval specified by the PDP in the Client-Accept message. On
receiving a Keep-Alive message from the PEP, the PDP MUST then receiving a Keep-Alive message from the PEP, the PDP MUST then
respond to this Keep-Alive message by echoing a Keep-Alive message respond to this Keep-Alive message by echoing a Keep-Alive message
back to the PEP. If either side does not receive a Keep-Alive or any back to the PEP. If either side does not receive a Keep-Alive or any
other COPS message within the minimum KA Timer interval from the other COPS message within the minimum KA Timer interval from the
other, the connection SHOULD be considered lost. other, the connection SHOULD be considered lost.
4.7 PEP/PDP Close 4.7 PEP/PDP Close
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
the specified client-type is no longer supported/active. When the specified client-type is no longer supported/active. When the PEP
PEP detects a lost connection due to a keep-alive timeout condition detects a lost connection due to a keep-alive timeout condition it
it SHOULD explicitly send a Client-Close message for each opened SHOULD explicitly send a Client-Close message for each opened
client-type specifying a communications failure error code. Then the client-type specifying a communications failure error code. Then the
PEP MAY proceed to terminate the connection to the PDP and attempt PEP MAY proceed to terminate the connection to the PDP and attempt to
to reconnect again or try a backup/alternative PDP. When the PDP is reconnect again or try a backup/alternative PDP. When the PDP is
shutting down, it SHOULD also explicitly send a Client-Close to all shutting down, it SHOULD also explicitly send a Client-Close to all
connected PEPs for each client-type, perhaps specifying an connected PEPs for each client-type, perhaps specifying an
alternative PDP to use instead. alternative PDP to use instead.
5. Security Considerations 5. Security Considerations
The COPS protocol provides an Integrity object that can achieve The COPS protocol provides an Integrity object that can achieve
authentication, message integrity, and replay prevention. All COPS authentication, message integrity, and replay prevention. All COPS
implementations MUST support the COPS Integrity object and its implementations MUST support the COPS Integrity object and its
mechanisms as described in this document. To ensure the client (PEP) mechanisms as described in this document. To ensure the client (PEP)
is communicating with the correct policy server (PDP) requires is communicating with the correct policy server (PDP) requires
authentication of the PEP and PDP using a shared secret, and authentication of the PEP and PDP using a shared secret, and
consistent proof that the connection remains valid. The shared consistent proof that the connection remains valid. The shared secret
secret minimally requires manual configuration of keys (identified minimally requires manual configuration of keys (identified by a Key
by a Key ID) shared between the PEP and its PDP. The key is used in ID) shared between the PEP and its PDP. The key is used in
conjunction with the contents of a COPS message to calculate a conjunction with the contents of a COPS message to calculate a
message digest that is part of the Integrity object. The Integrity message digest that is part of the Integrity object. The Integrity
object is then used to validate all COPS messages sent over the TCP object is then used to validate all COPS messages sent over the TCP
connection between a PEP and PDP. connection between a PEP and PDP.
Key maintenance is outside the scope of this document beyond the Key maintenance is outside the scope of this document beyond the
specific requirements discussed in section 4.2. In general, it is specific requirements discussed in section 4.2. In general, it is
good practice to regularly change keys to maintain security. good practice to regularly change keys to maintain security.
Furthermore, it is good practice to use localized keys specific to a Furthermore, it is good practice to use localized keys specific to a
particular PEP such that a stolen PEP will not compromise the particular PEP such that a stolen PEP will not compromise the
security of an entire administrative domain. security of an entire administrative domain.
The COPS Integrity object also provides sequence numbers to avoid The COPS Integrity object also provides sequence numbers to avoid
replay attacks. The PDP chooses the initial sequence number for the replay attacks. The PDP chooses the initial sequence number for the
PEP and the PEP chooses the initial sequence number for the PDP. PEP and the PEP chooses the initial sequence number for the PDP.
These initial numbers are then incremented with each successive These initial numbers are then incremented with each successive
message sent over the connection in the corresponding direction. The message sent over the connection in the corresponding direction. The
initial sequence numbers SHOULD be chosen such that they are initial sequence numbers SHOULD be chosen such that they are
monotonically increasing and never repeat for a particular key. monotonically increasing and never repeat for a particular key.
Security between the client (PEP) and server (PDP) MAY be provided Security between the client (PEP) and server (PDP) MAY be provided by
by IP Security [IPSEC]. In this case, the IPSEC Authentication IP Security [IPSEC]. In this case, the IPSEC Authentication Header
Header (AH) SHOULD be used for the validation of the connection; (AH) SHOULD be used for the validation of the connection;
additionally IPSEC Encapsulation Security Payload (ESP) MAY be used additionally IPSEC Encapsulation Security Payload (ESP) MAY be used
to provide both validation and secrecy. to provide both validation and secrecy.
Transport Layer Security [TLS] MAY be used for both connection-level Transport Layer Security [TLS] MAY be used for both connection-level
validation and privacy. validation and privacy.
6. IANA Considerations 6. IANA Considerations
The Client-type identifies the policy client application to which a The Client-type identifies the policy client application to which a
message refers. Client-type values within the range 0x0001-0x3FFF message refers. Client-type values within the range 0x0001-0x3FFF are
are reserved Specification Required status as defined in [IANA- reserved Specification Required status as defined in [IANA-
CONSIDERATIONS]. These values MUST be registered with IANA and their CONSIDERATIONS]. These values MUST be registered with IANA and their
behavior and applicability MUST be described in a COPS extension behavior and applicability MUST be described in a COPS extension
document. document.
Client-type values in the range 0x4000 - 0x7FFF are reserved for Client-type values in the range 0x4000 - 0x7FFF are reserved for
Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types
are not tracked by IANA and are not to be used in standards or are not tracked by IANA and are not to be used in standards or
general-release products, as their uniqueness cannot be assured. general-release products, as their uniqueness cannot be assured.
Client-type values in the range 0x8000 - 0xFFFF are First Come First Client-type values in the range 0x8000 - 0xFFFF are First Come First
Served as defined in [IANA-CONSIDERATIONS]. These Client-types are Served as defined in [IANA-CONSIDERATIONS]. These Client-types are
tracked by IANA but do not require published documents describing tracked by IANA but do not require published documents describing
their use. IANA merely assures their uniqueness. their use. IANA merely assures their uniqueness.
Objects in the COPS Protocol are identified by their C-Num and C- Objects in the COPS Protocol are identified by their C-Num and C-Type
Type values. IETF Consensus as identified in [IANA-CONSIDERATIONS] values. IETF Consensus as identified in [IANA-CONSIDERATIONS] is
is required to introduce new values for these numbers and, required to introduce new values for these numbers and, therefore,
therefore, new objects into the base COPS protocol. new objects into the base COPS protocol.
Additional Context Object R-Types, Reason-Codes, Report-Types, Additional Context Object R-Types, Reason-Codes, Report-Types,
Decision Object Command-Codes/Flags, and Error-Codes MAY be defined Decision Object Command-Codes/Flags, and Error-Codes MAY be defined
for use with future Client-types, but such additions require IETF for use with future Client-types, but such additions require IETF
Consensus as defined in [IANA-CONSIDERATIONS]. Consensus as defined in [IANA-CONSIDERATIONS].
Context Object M-Types, Reason Sub-Codes, and Error Sub-codes MAY be Context Object M-Types, Reason Sub-Codes, and Error Sub-codes MAY be
defined relative to a particular Client-type following the same IANA defined relative to a particular Client-type following the same IANA
considerations as their respective Client-type. considerations as their respective Client-type.
7. References 7. References
[RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S.
Version 1 - Functional Specification", RFC 2205, September and S. Jamin, "Resource ReSerVation Protocol
1997. (RSVP) Version 1 - Functional Specification",
RFC 2205, September 1997.
[WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission [WRK] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Control", Internet-Draft, draft-ietf-rap-framework-01.txt, Framework for Policy-Based Admission Control",
November 1998. RFC 2753, January 2000.
[SRVLOC]Guttman, E. et al., "Service Location Protocol , Version 2", [SRVLOC] Guttman, E., Perkins, C., Veizades, J. and M.
Internet-Draft, RFC 2608, June 1999. Day, "Service Location Protocol , Version 2",
RFC 2608, June 1999.
[INSCH] Shenker, S., Wroclawski, J., "General Characterization [INSCH] Shenker, S. and J. Wroclawski, "General
Parameters for Integrated Service Network Elements", RFC Characterization Parameters for Integrated
2215, September 1997. Service Network Elements", RFC 2215, September
1997.
[IPSEC] Atkinson, R., "Security Architecture for the Internet [IPSEC] Atkinson, R., "Security Architecture for the
Protocol", RFC 2401, August 1995. Internet Protocol", RFC 2401, August 1995.
[HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing [HMAC] Krawczyk, H., Bellare, M. and R. Canetti,
for Message Authentication", RFC 2104, February 1997. "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm",
April 1992. RFC 1321, April 1992.
[RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) [RSVPPR] Braden, R. and L. Zhang, "Resource ReSerVation
- Version 1 Message Processing Rules", RFC 2209, September Protocol (RSVP) - Version 1 Message Processing
1997. Rules", RFC 2209, September 1997.
[TLS] Dierks T., Allen C., "The TLS Protocol Version 1.0", RFC [TLS] Dierks T. and C. Allen, "The TLS Protocol
2246, January 1999. Version 1.0", RFC 2246, January 1999.
[IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers [IANA] http://www.isi.edu/in-
notes/iana/assignments/port-numbers
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, RFC Writing an IANA Considerations Section in
2434, October 1998. RFCs", BCP 26, RFC 2434, October 1998.
8. Author Information and Acknowledgments 8. Author Information and Acknowledgments
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs,
Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch
Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable
contributions. contributions.
Jim Boyle Ron Cohen Jim Boyle
Level 3 Communications Cisco Systems Level 3 Communications
1450 Infinite Drive13 Hasadna St. 1025 Eldorado Boulevard
Louisville, CO 80027 Ra'anana 43650 Israel Broomfield, CO 80021
303.926.3100 972.9.7462020
email: jboyle@l3.net ronc@classdata.com
David Durham Raju Rajan Phone: 720.888.1192
Intel AT&T Shannon Laboratory EMail: jboyle@Level3.net
2111 NE 25th Avenue 180 Park Avenue
Hillsboro, OR 97124 P.O. Box 971
503.264.6232 Florham Park, NJ 07932-0971
David.Durham@mail.intel.com rajan@research.att.com
Shai Herzog Arun Sastry Ron Cohen
IPHighway Cisco Systems CISCO Systems
Parker Plaza, 16th Floor 506210 W Tasman Drive 4 Maskit St.
400 Kelby St. Fort-Lee NJ 07024 San Jose, CA 95134 Herzeliya Pituach 46766 Israel
201.585.0800 408.526.7685
herzog@iphighway.com asastry@cisco.com Phone: +972.9.9700064
EMail: ronc@cisco.com
David Durham
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: 503.264.6232
EMail: David.Durham@intel.com
Raju Rajan
AT&T Shannon Laboratory
180 Park Avenue
P.O. Box 971
Florham Park, NJ 07932-0971
EMail: rajan@research.att.com
Shai Herzog
IPHighway, Inc.
55 New York Avenue
Framingham, MA 01701
Phone: 508.620.1141
EMail: herzog@iphighway.com
Arun Sastry
Cisco Systems
4 The Square
Stockley Park
Uxbridge, Middlesex UB11 1BN
UK
Phone: +44-208-756-8693
EMail: asastry@cisco.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 143 change blocks. 
577 lines changed or deleted 560 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/