draft-ietf-rap-cops-05.txt   draft-ietf-rap-cops-06.txt 
Internet Draft Jim Boyle Internet Draft Jim Boyle
Expiration: June 1999 Level 3 Expiration: August 1999 Level 3
File: draft-ietf-rap-cops-05.txt Ron Cohen File: draft-ietf-rap-cops-06.txt Ron Cohen
Cisco Cisco
David Durham David Durham
Intel Intel
Shai Herzog Shai Herzog
IPHighway IPHighway
Raju Rajan Raju Rajan
IBM IBM
Arun Sastry Arun Sastry
Cisco Cisco
The COPS (Common Open Policy Service) Protocol The COPS (Common Open Policy Service) Protocol
Last Updated: January 18, 1999 Last Updated: February 24, 1999
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its Areas, all provisions of Section 10 of RFC2026.
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet-Drafts are working documents of the Internet Engineering
months. Internet Drafts may be updated, replaced, or obsoleted by Task Force (IETF), its areas, and its working groups. Note that
other documents at any time. It is not appropriate to use Internet other groups may also distribute working documents as Internet-
Drafts as reference material or to cite them other than as a Drafts.
"working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the Internet-Drafts are draft documents valid for a maximum of six
1id-abstracts.txt listing contained in the Internet-Drafts Shadow months and may be updated, replaced, or obsoleted by other documents
Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or at any time. It is inappropriate to use Internet-Drafts as
munnari.oz.au. reference material or to cite them other than as "work in progress."
A revised version of this draft document will be submitted to the The list of current Internet-Drafts can be accessed at
RFC editor as a Proposed Standard for the Internet Community. http://www.ietf.org/ietf/1id-abstracts.txt
Discussion and suggestions for improvement are requested. This
document will expire before June 1999. Distribution of this draft is The list of Internet-Draft Shadow Directories can be accessed at
unlimited. http://www.ietf.org/shadow.html.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
Status of this Memo................................................1 Status of this Memo................................................1
Conventions used in this document..................................1
Abstract...........................................................3 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....................................................7
2.1 Common Header..................................................7 2.1 Common Header..................................................7
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 LDP Decision Object (LDPDecision)...........................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)...............14
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)..........................15
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.3 Communication.................................................17 2.3 Communication.................................................17
2.4 Client Handle Usage...........................................18 2.4 Client Handle Usage...........................................19
2.5 Synchronization Behavior......................................19 2.5 Synchronization Behavior......................................19
3. Message Content................................................20 3. Message Content................................................20
3.1 Request (REQ) PEP -> PDP.....................................20 3.1 Request (REQ) PEP -> PDP.....................................20
3.2 Decision (DEC) PDP -> PEP....................................21 3.2 Decision (DEC) PDP -> PEP....................................21
3.3 Report State (RPT) PEP -> PDP................................22 3.3 Report State (RPT) PEP -> PDP................................22
3.4 Delete Request State (DRQ) PEP -> PDP........................22 3.4 Delete Request State (DRQ) PEP -> PDP........................22
3.5 Synchronize State Request (SSQ) PDP -> PEP...................23 3.5 Synchronize State Request (SSQ) PDP -> PEP...................23
3.6 Client-Open (OPN) PEP -> PDP.................................23 3.6 Client-Open (OPN) PEP -> PDP.................................23
3.7 Client-Accept (CAT) PDP -> PEP...............................24 3.7 Client-Accept (CAT) PDP -> PEP...............................24
3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................24 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................24
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................25 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................25
3.10 Synchronize State Complete (SSC) PEP -> PDP..................25 3.10 Synchronize State Complete (SSC) PEP -> PDP..................25
4. Common Operation...............................................26 4. Common Operation...............................................26
4.1 PEP Initialization............................................26 4.1 PEP Initialization............................................26
4.2 Outsourcing Operations........................................26 4.2 Outsourcing Operations........................................26
4.3 Configuration Operations......................................27 4.3 Configuration Operations......................................27
4.4 Keep-Alive Operations.........................................27 4.4 Keep-Alive Operations.........................................27
4.5 PEP/PDP Close.................................................27 4.5 PEP/PDP Close.................................................27
5. Security.......................................................28 5. Security Considerations........................................28
6. IANA Considerations............................................29 6. IANA Considerations............................................29
7. References.....................................................30 7. References.....................................................30
8. Author Information and Acknowledgments.........................31 8. Author Information and Acknowledgments.........................31
Abstract Abstract
This document describes a simple client/server model for supporting This document describes a simple client/server model for supporting
policy control over QoS Signaling Protocols and provisioned QoS policy control over QoS Signaling Protocols and provisioned QoS
resource management. It is designed to be extensible so that other resource management. It is designed to be extensible so that other
kinds of policy clients may be supported in the future. The model kinds of policy clients may be supported in the future. The model
skipping to change at page 4, line 45 skipping to change at page 4, line 45
| +-----+ | | +-----+ |
| | | |
+----------------+ +----------------+
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. a particular type of client. The optional Local Decision Point (LDP)
can be used by the device to make local policy decisions in 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
skipping to change at page 6, line 14 skipping to change at page 6, line 16
PEP must send its local decision information to the remote PDP via a PEP must send its local decision information to the remote PDP via a
LDP decision object. The PEP must then abide by the PDP's decision LDP decision object. The PEP must then abide by the PDP's decision
as it is absolute. as it is absolute.
Finally, fault tolerance is a required capability for this protocol, Finally, fault tolerance is a required capability for this protocol,
particularly due to the fact it is associated with the security and particularly due to the fact it is associated with the security and
service management of distributed network devices. Fault tolerance service management of distributed network devices. Fault tolerance
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 failure is detected, the PEP must try to reconnect to the remote a failure is detected, the PEP must try to reconnect to the remote
PDP or attempt to connect to a new/alternative PDP. While PDP 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 connection is reestablished, the PEP is expected to notify the PDP a connection is reestablished, the PEP is expected to notify the PDP
of any deleted state or new events that passed local admission of any deleted state or new events that passed local admission
control after the connection was lost. Additionally, the remote PDP control after the connection was lost. Additionally, the remote PDP
may request that all the PEP's internal state be resynchronized (all may 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. and continues to use them for some limited amount of time. Sections
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 typed objects. of typed objects.
skipping to change at page 9, line 12 skipping to change at page 9, line 12
14 = Last PDP Address 14 = Last PDP Address
15 = Accounting Timer 15 = Accounting Timer
C-type: 8 bits C-type: 8 bits
Values defined per C-num. Values defined per C-num.
2.2.1 Handle Object (Handle) 2.2.1 Handle Object (Handle)
The Handle Object encapsulates a unique value that identifies an The Handle Object encapsulates a unique value that identifies an
installed state. This identification is used by most COPS installed state. This identification is used by most COPS
operations. A state corresponding to a handle must be explicitly operations. A state corresponding to a handle must be explicitly
deleted when it is no longer applicable. deleted when it is no longer applicable. See Section 2.4 for
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 other client handles. It is always initially chosen by the PEP from other client handles from the same PEP (a.k.a. COPS TCP
and then deleted by the PEP when no longer applicable. The client connection) for a particular client-type. It is always initially
handle is used to refer to a request state initiated by the PEP and chosen by the PEP and then deleted by the PEP when no longer
installed at the PDP. A PEP will specify a client handle in its applicable. The client handle is used to refer to a request state
Request messages, Report messages and Delete messages sent to the initiated by a particular PEP and installed at the PDP for a client-
PDP. In all cases, the client handle is used to uniquely identify type. A PEP will specify a client handle in its Request messages,
the PEP request. Report messages and Delete messages sent to the PDP. In all cases,
the client handle is used to uniquely identify a particular PEP's
request for a client-type.
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 request messages. Admission control, resource allocation, and for request messages. Admission control, resource allocation, and
skipping to change at page 12, line 34 skipping to change at page 12, line 34
3 = Preempted (Another request state takes precedence) 3 = Preempted (Another request state takes precedence)
4 = Tear (Used to communicate a signaled state removal) 4 = Tear (Used to communicate a signaled state removal)
5 = Timeout (Local state has timed-out) 5 = Timeout (Local state has timed-out)
6 = Route Change (Change invalidates request state) 6 = Route Change (Change invalidates request state)
7 = Insufficient Resources (No local resource available) 7 = Insufficient Resources (No local resource available)
8 = PDP's Directive (PDP decision caused the delete) 8 = PDP's Directive (PDP decision caused the delete)
9 = Unsupported decision (PDP decision not supported) 9 = Unsupported decision (PDP decision not supported)
10= Synchronize Handle Unknown 10= Synchronize Handle Unknown
11= Transient Handle (stateless event) 11= Transient Handle (stateless event)
12= Malformed Decision (could not recover) 12= Malformed Decision (could not recover)
13= Unknown COPS Object from PDP:
Sub-code (octet 2) should contain unknown object's
C-Num and (octet 3) should contain unknown object's
C-Type.
2.2.6 Decision Object (Decision) 2.2.6 Decision Object (Decision)
Decision made by the PDP. Must appear in replies. The specific non- Decision made by the PDP. Must appear in replies. The specific non-
mandatory decision objects required in a decision to a particular mandatory decision objects required in a decision to a particular
request depend on the type of client. request depend on the type of client.
C-Num = 6 C-Num = 6
C-Type = 1, Decision Flags (Mandatory) C-Type = 1, Decision Flags (Mandatory)
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Command-Code | Flags | | Command-Code | Flags |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Commands: Commands:
0 = NULL Decision (No configuration data available) 0 = NULL Decision (No configuration data available)
1 = Install (Admit request/Install configuration) 1 = Install (Admit request/Install configuration)
skipping to change at page 14, line 43 skipping to change at page 14, line 45
2 = Invalid handle reference 2 = Invalid handle reference
3 = Bad message format (Malformed Message) 3 = Bad message format (Malformed Message)
4 = Unable to process (server gives up on query) 4 = Unable to process (server gives up on query)
5 = Mandatory client-specific info missing 5 = Mandatory client-specific info missing
6 = Unsupported client-type 6 = Unsupported client-type
7 = Mandatory COPS object missing 7 = Mandatory COPS object missing
8 = Client Failure 8 = Client Failure
9 = Communication Failure 9 = Communication Failure
10= Unspecified 10= Unspecified
11= Shutting down 11= Shutting down
12= Redirect to Preferred Server
13= Unknown COPS Object:
Sub-code (octet 2) should contain unknown object's
C-Num and (octet 3) should contain unknown object's
C-Type.
2.2.9 Client Specific Information Object (ClientSI) 2.2.9 Client Specific Information Object (ClientSI)
The various types of this object are required for requests, and used The various types of this object are required for requests, and used
in reports and opens when required. It contains client-type specific in reports and opens when required. It contains client-type specific
information. information.
C-Num = 9, C-Num = 9,
C-Type = 1, Signaled ClientSI. C-Type = 1, Signaled ClientSI.
skipping to change at page 15, line 27 skipping to change at page 15, line 31
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 value of zero implies COPS message must be sent or received. The range of finite timeouts
infinity. is 1 to 65535 seconds represented as an unsigned two-octet integer.
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.
skipping to change at page 16, line 24 skipping to change at page 16, line 28
2 = No Commit : PEP's resource allocation failure 2 = No Commit : PEP's resource allocation failure
3 = Accounting: Accounting update for an installed state 3 = Accounting: Accounting update for an installed state
4 = Installed : Admitted request/Installed configuration 4 = Installed : Admitted request/Installed configuration
5 = Removed : Removed request/Removed configuration 5 = Removed : Removed request/Removed configuration
6 = NotInstall: Request/Configuration was not installed 6 = NotInstall: Request/Configuration was not installed
7 = NotRemoved: Request/Configuration was not removed 7 = NotRemoved: Request/Configuration was not removed
2.2.13 PDP Redirect Address (PDPRedirAddr) 2.2.13 PDP Redirect Address (PDPRedirAddr)
A PDP when closing a PEP session for a particular client-type may A PDP when closing a PEP session for a particular client-type may
optionally use this object to redirect the PEP to another PDP optionally use this object to redirect the PEP to the specified PDP
server: server address and TCP port number:
C-Num = 13, C-Num = 13,
C-Type = 1, IPv4 Address (4 octets) C-Type = 1, IPv4 Address + TCP Port
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| IPv4 Address format | | IPv4 Address format |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
C-Type = 2, IPv6 Address (16 octets) C-Type = 2, IPv6 Address + TCP Port
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| | | |
+ + + +
| | | |
+ IPv6 Address format + + IPv6 Address format +
| | | |
+ + + +
| | | |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
2.2.14 Last PDP Address (LastPDPAddr) 2.2.14 Last PDP Address (LastPDPAddr)
When a PEP sends a Client-Open message for a particular client-type When a PEP sends a Client-Open message for a particular client-type
the PEP should specify the last PDP it has successfully opened the PEP should specify the last PDP it has successfully opened
(meaning it received a Client-Accept) since the PEP last rebooted. (meaning it received a Client-Accept) since the PEP last rebooted.
If no PDP was used since the last reboot, the PEP will simply not If no PDP was used since the last reboot, the PEP will simply not
include this object in the Client-Open message. include this object in the Client-Open message.
C-Num = 14, C-Num = 14,
skipping to change at page 17, line 22 skipping to change at page 17, line 30
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 = 15, C-Num = 15,
C-Type = 1, Accounting timer value C-Type = 1, Accounting timer value
Optional timer value used to determine the minimum interval between Optional timer value used to determine the minimum interval between
periodic accounting type reports. It is used by the PDP to describe periodic accounting type reports. It is used by the PDP to describe
to the PEP an acceptable interval between accounting updates via to the PEP an acceptable interval between unsolicited accounting
Report messages where applicable. The value of zero implies there updates via Report messages where applicable. It provides a method
are no timing constraints on accounting updates. for the PDP to control the amount of accounting traffic seen by the
network. The range of finite time values is 1 to 65535 seconds
represented as an unsigned two-octet integer. A value of zero means
there should be no unsolicited accounting updates.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value | | ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
2.3 Communication 2.3 Communication
The COPS protocol uses a single persistent TCP connection between The COPS protocol uses a single persistent TCP connection between
the PEP and a remote PDP. The remote PDP listens on a well-known the PEP and a remote PDP. One PDP implementation per server must
port number (COPS=3288 [IANA]), and the PEP is responsible for listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP
initiating the connection. The location of the remote PDP can either is responsible for initiating the TCP connection to a PDP. The
be configured, or obtained via a service location mechanism location of the remote PDP can either be configured, or obtained via
[SRVLOC]. Service discovery is outside the scope of this protocol, a service location mechanism [SRVLOC]. Service discovery is outside
however. the scope 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 may support one or more client-types. residing at a given address and port number may support one or more
Given the client-types it supports, a PDP has the ability to either client-types. Given the client-types it supports, a PDP has the
accept or reject each client-type independently. If a client-type is ability to either accept or reject each client-type independently.
rejected, the PDP can redirect the PEP to an alternative PDP for a If a client-type is rejected, the PDP can redirect the PEP to an
given client-type via COPS. Additional provisions for supporting alternative PDP address and TCP port for a given client-type via
multiple client-types (perhaps from independent PDP vendors) on a COPS. Different TCP port numbers can be used to redirect the PEP to
single remote PDP server are not provided by the COPS protocol, but, another PDP implementation running on the same server. Additional
rather, are left to the software architecture of the given server provisions for supporting multiple client-types (perhaps from
platform. independent PDP vendors) on a single remote PDP server are not
provided by the COPS protocol, but, rather, are left to the software
architecture of the given server platform.
It is possible a single PEP may have open connections to multiple It is possible a single PEP may have open connections to multiple
PDPs. This is the case when there are physically different PDPs PDPs. This is the case when there are physically different PDPs
supporting different client-types as shown in figure 2. supporting different client-types as shown in figure 2.
+----------------+ +----------------+
| | | |
| Network Node | Policy Servers | Network Node | Policy Servers
| | | |
| +-----+ | COPS Client Type 1 +-----+ | +-----+ | COPS Client Type 1 +-----+
skipping to change at page 18, line 41 skipping to change at page 18, line 51
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 to the primary PDP (via a <Client-Close> message containing a back to the primary PDP (via a <Client-Close> message containing a
<PDPRedirAddr> object indicating the primary PDP to use for each <PDPRedirAddr> object identifying the primary PDP to use for each
affected client-type). affected client-type). Section 2.5 details synchronization behavior
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. Client The client handle is used to identify a unique request state for a
handles are chosen by the PEP and are opaque to the PDP. The PDP single PEP per client-type. Client handles are chosen by the PEP and
simply uses the request handle to uniquely identify the request are opaque to the PDP. The PDP simply uses the request handle to
state and generically tie its decisions to a corresponding request. uniquely identify the request state for a particular Client-Type
Client handles are initiated in request messages and are then used over a particular TCP connection and generically tie its decisions
by subsequent request, decision, and report messages to reference to a corresponding request. Client handles are initiated in request
the same request state. When the PEP is ready to remove a local messages and are then used by subsequent request, decision, and
request state, it will issue a delete message to the PDP for the report messages to reference the same request state. When the PEP is
corresponding client handle. A handle MUST be explicitly deleted by ready to remove a local request state, it will issue a delete
the PEP before it can be used to identify a new request state. message to the PDP for the corresponding client handle. A handle
Handles referring to different request states must be unique. MUST be explicitly deleted by the PEP before it can be used by the
PEP to identify a new request state. Handles referring to different
request states must be unique within the context of a particular TCP
connection and client-type.
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 notify the PDP of any events that have passed local admission to 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 length of time. Specific rules for such behavior are to appropriate length of time. Specific rules for such behavior are to
be defined in the appropriate COPS client-type extension be defined in 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 of later reconnect. This is accomplished by including the address and
the last PDP for which the PEP is still caching state in the Client- TCP port of the last PDP for which the PEP is still caching state in
Open message. The <LastPDPAddr> object will only be included for the the Client-Open message. The <LastPDPAddr> object will only be
last PDP with which the PEP was completely in sync. If the service included for the last PDP with which the PEP was completely in sync.
interruption was temporary and the PDP still contains the complete If the service interruption was temporary and the PDP still contains
state for the PEP, the PDP may choose not to synchronize all states. the complete state for the PEP, the PDP may choose not to
It is still the responsibility of the PEP to update the PDP of all synchronize all states. It is still the responsibility of the PEP to
state changes that occurred during the disruption of service update the PDP of all state changes that occurred during the
including any states communicated to the previous PDP that had been disruption of service including any states communicated to the
deleted after the connection was lost. These must be explicitly previous PDP that had been deleted after the connection was lost.
deleted after a connection is reestablished. If the PDP issues a These must be explicitly deleted after a connection is
synchronize request the PEP must pass all current states to the PDP reestablished. If the PDP issues a synchronize request the PEP must
followed by a Synchronize State Complete message (thus completing pass all current states to the PDP followed by a Synchronize State
the synchronization process). Complete message (thus completing the synchronization process). If
the PEP crashes and loses all cached state for a client-type, it
will simply not include a <LastPDPAddr> in its Client-Open message.
3. Message Content 3. Message Content
This section describes the basic messages exchanged between a PEP This section describes the basic messages exchanged between a PEP
and a remote PDP as well as their contents. As a convention, object and a remote PDP as well as their contents. As a convention, object
ordering is expected as shown in the BNF for each COPS message ordering is expected as shown in the BNF for each COPS message
unless otherwise noted. Malformed messages are to be silently unless otherwise noted. Malformed messages are to be silently
dropped unless otherwise specified. dropped unless otherwise specified.
3.1 Request (REQ) PEP -> PDP 3.1 Request (REQ) PEP -> PDP
The PEP establishes a request state client handle for which the The PEP establishes a request state client handle for which the
remote PDP may maintain a state. The remote PDP then uses this remote PDP may maintain state. The remote PDP then uses this handle
handle to refer to the exchanged information and decisions. to refer to the exchanged information and decisions communicated
over 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 the PDP's state will be able to accurately mirror the PEP's so the PDP's state will be able to accurately mirror the PEP's
state. state.
The format of the Request message is as follows: The format of the Request message is as follows:
skipping to change at page 21, line 26 skipping to change at page 21, line 29
there was a protocol error an error object is returned instead. there was a protocol error an error object is returned instead.
It is required that the first decision message for a new/updated It is required that the first decision message for a new/updated
request will have the solicited message flag set (value = 1) in the request will have the solicited message flag set (value = 1) in the
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. DEC with the solicited message flag set. The PDP must always issue
decisions for requests on a particular handle in the order they
arrive and all requests must have a corresponding decision.
To avoid deadlock, the client can always timeout after issuing a To avoid deadlock, the PEP can always timeout after issuing a
request. It must then delete the timed-out handle, and possibly try request that does not receive a decision. It must then delete the
again using a different (new) handle. timed-out 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>
<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 are reported in the Error object (e.g. an error with the problems are reported in the Error object (e.g. an error with the
format of the original request, including malformed request format of the original request including malformed request messages,
messages). The applicable Decision object(s) depend on the context unknown COPS objects in the Request, etc.). The applicable Decision
and the type of client. The only ordering requirement for decision object(s) depend on the context and the type of client. The only
objects is that the required Decision Flags object type must proceed ordering requirement for decision objects is that the required
the other Decision object types per context binding. Decision Flags object type must precede the other Decision object
types per context binding.
3.3 Report State (RPT) PEP -> PDP 3.3 Report State (RPT) PEP -> PDP
This message is used by the PEP to communicate a change in the The RPT message is used by the PEP to communicate to the PDP its
status of a previously installed state to the PDP. A commit or no- success or failure in carrying out the PDP's decision, or to report
commit report-type indicates to the PDP that a particular policy a change in state. The Report-Type specifies the kind of report and
directive has or has not been acted upon as is relevant for the optional ClientSI can carry additional information per Client-
accounting purposes. (In RSVP this would mean that a reservation Type.
passed or failed local capacity admission control [RSVP]. For a
configuration decision, it would mean the configuration identified
in the ClientSI either could or could not be installed by the PEP).
The Report State may also be used to provide periodic updates of The Report State may also be used to provide periodic updates of
client specific information for accounting and state monitoring client specific information for accounting and state monitoring
purposes depending on the type of the client. In such cases the purposes depending on the type of the client. In such cases the
accounting report type should be specified utilizing the 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>
skipping to change at page 22, line 52 skipping to change at page 22, line 53
Given the stateful nature of COPS, it is important that when a Given the stateful nature of COPS, it is important that when a
request state is finally removed from the PEP, a DRQ message for request state is finally removed from the PEP, a DRQ message for
this request state is sent to the PDP so the corresponding state may this request state is sent to the PDP so the corresponding state may
likewise be removed on the PDP. Request states not explicitly likewise be removed on the PDP. Request states not explicitly
deleted by the PEP will be maintained by the PDP until either the deleted by the PEP will be maintained by the PDP until either the
client session is closed or the connection is terminated. client session is closed or the connection is terminated.
Malformed Decision messages should trigger a DRQ specifying the Malformed Decision messages should 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,
the PEP must delete its request specifying the Unknown COPS Object
reason code because the PEP will be unable to comply with the
information contained in the unknown object. In any case, after
issuing a DRQ, the PEP may retry the corresponding Request again.
3.5 Synchronize State Request (SSQ) PDP -> PEP 3.5 Synchronize State Request (SSQ) PDP -> PEP
The format of the Synchronize State Query message is as follows: The format of the Synchronize State Query message is as follows:
<Synchronize State> ::= <Common Header> <Synchronize State> ::= <Common Header>
[<Client Handle>] [<Client Handle>]
This message indicates that the remote PDP wishes the client (which This message indicates that the remote PDP wishes the client (which
appears in the common header) to re-send its state. If the optional appears in the common header) to re-send its state. If the optional
skipping to change at page 23, line 41 skipping to change at page 23, line 43
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 and multiple Client-Open messages for the same client-type are time 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>]
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. 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).
Finally, the PEP may provide a Last PDP Address object in its Finally, the PEP may provide a Last PDP Address object in its
Client-Open message specifying the last PDP (for the given client- Client-Open message specifying the last PDP (for the given client-
type) for which it is still caching decisions since its last reboot. type) for which it is still caching decisions since its last reboot.
A PDP can use this information to determine the appropriate A PDP can use this information to determine the appropriate
synchronization behavior (See section 2.5). synchronization behavior (See section 2.5).
If the PEP specifies an unknown COPS object to the PDP via the
Client-Open, the PDP must send back a Client-Close message
specifying the Unknown COPS Object 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 between accounting report messages may be included when interval between accounting report messages may be included when
applicable. applicable.
<Client-Accept> ::= <Common Header> <Client-Accept> ::= <Common Header>
skipping to change at page 24, line 27 skipping to change at page 24, line 34
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 accounting timer allows the PDP to indicate to the PEP The optional ACCT Timer allows the PDP to indicate to the PEP that
that periodic accounting reports should not exceed the specified periodic accounting reports should not exceed the specified timer
timer interval. This allows the PDP to control the rate at which interval per client handle. This allows the PDP to control the rate
accounting reports are sent by the PEP (when applicable). In at which accounting reports are sent by the PEP (when applicable).
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
the rate at which accounting updates are generated.
If the PDP specifies an unknown COPS object to the PEP via the
Client-Accept, the PEP must send back a Client-Close message
specifying the Unknown COPS Object error code. The PEP should then
retry its Client-Open for the client-type again.
3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP
The Client-Close message can be issued by either the PDP or PEP to The Client-Close message can be issued by either the PDP or PEP to
notify the other that a particular type of client is no longer being notify the other that a particular type of client is no longer being
supported. supported.
<Client-Close> ::= <Common Header> <Client-Close> ::= <Common Header>
<Error> <Error>
[<PDPRedirAddr>] [<PDPRedirAddr>]
skipping to change at page 25, line 10 skipping to change at page 25, line 22
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 received CAT messages for the connection. A KA message must be all received CAT messages for the connection. A KA message must be
generated randomly between 1/4 and 3/4 of this minimum TA 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 should always be set to 0 as the Note: The client-type in the header should always be set to 0 as the
KA is used for connection verification (not per client session KA is used for connection verification (not per client session
verification). verification).
<Keep-Alive> ::= <Common Header> <Keep-Alive> ::= <Common Header>
skipping to change at page 26, line 26 skipping to change at page 26, line 26
which the PEP is still caching a complete set of decisions. If no which the PEP is still caching a complete set of decisions. If no
decisions are being cached from the previous PDP the LastPDPAddr decisions are being cached from the previous PDP the LastPDPAddr
object must not be included in the Client-Open message (see Section object must not be included in the Client-Open message (see Section
2.5). Each Client-Open message should at least contain the common 2.5). Each Client-Open message should at least contain the common
header noting one client-type supported by the PEP. The remote PDP header noting one client-type supported by the PEP. The remote PDP
will then respond with separate Client-Accept messages for each of will then respond with separate Client-Accept messages for each of
the client-types requested by the PEP that the PDP can also support. the client-types requested by the 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 supported and will possibly suggest an alternate PDP address. not supported and will possibly suggest an alternate PDP address and
Otherwise, the PDP will send a Client-Accept specifying the timer port. Otherwise, the PDP will send a Client-Accept specifying the
interval between keep-alive messages and the PEP may begin issuing timer interval between keep-alive messages and the PEP may begin
requests to the PDP. issuing requests to the PDP.
4.2 Outsourcing Operations 4.2 Outsourcing Operations
In the outsourcing scenario, when the PEP receives an event that In the outsourcing scenario, when the PEP receives an event that
requires a new policy decision it sends a request message to the requires a new policy decision it sends a request message to the
remote PDP. What specifically qualifies as an event for a particular remote PDP. What specifically qualifies as an event for a particular
client-type should be specified in the specific document for that client-type should be specified in the specific document for that
client-type. The remote PDP then makes a decision and sends a client-type. The remote PDP then makes a decision and sends a
decision message back to the PEP. Since the request is stateful, the decision message back to the PEP. Since the request is stateful, the
request will be remembered, or installed, on the remote PDP. The request will be remembered, or installed, on the remote PDP. The
unique handle, specified in both the request and its corresponding unique handle (unique per TCP connection and client-type), specified
decision identifies this request state. The PEP is responsible for in both the request and its corresponding decision identifies this
deleting this request state once the request is no longer request state. The PEP is responsible for deleting this request
applicable. state 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 expected to make new decisions and send a decision message back then expected to make new decisions and send a decision message back
to the PEP. Likewise, the server may change a previously issued to the PEP. Likewise, the server may change a previously issued
decision on any currently installed request state at any time by decision on any currently installed request state at any time by
issuing another decision message. At all times the PEP module is issuing an unsolicited decision message. At all times the PEP module
expected to abide by the PDP's decisions and notify the PDP of any is expected to abide by the PDP's decisions and notify the PDP of
state changes. any state changes.
4.3 Configuration Operations 4.3 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 data to the PEP. The PEP is expected to install and configuration data to the PEP. The PEP is expected to install and
use the configuration locally. A particular named configuration can use the configuration locally. A particular named configuration can
skipping to change at page 27, line 34 skipping to change at page 27, line 34
The report message is to be used to signify when billing should The report message is to be used to signify when billing should
begin, what actions were taken, or to produce periodic updates for begin, what actions were taken, or to produce periodic updates for
monitoring and accounting purposes depending on the client. This monitoring and accounting purposes depending on the client. This
message can carry client specific information when needed. message can carry client specific information when needed.
4.4 Keep-Alive Operations 4.4 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 client and server is still functioning even when there is no the client and server is still functioning even when there is no
other messaging from the PEP to PDP. The PEP must generate a COPS KA other messaging from the PEP to PDP. The PEP must generate a COPS KA
message randomly within one-fourth to three-fourths the negotiated message randomly within one-fourth to three-fourths the minimum KA
minimum KA Timer interval. On receiving a Keep-Alive message from Timer interval specified by the PDP in the Client-Accept message. On
the PEP, the PDP must then respond to this Keep-Alive message by receiving a Keep-Alive message from the PEP, the PDP must then
echoing a Keep-Alive message back to the PEP. If either side does respond to this Keep-Alive message by echoing a Keep-Alive message
not receive a Keep-Alive or any other COPS message within the back to the PEP. If either side does not receive a Keep-Alive or any
minimum KA Timer interval from the other, the connection should be other COPS message within the minimum KA Timer interval from the
considered lost. other, the connection should be considered lost.
4.5 PEP/PDP Close 4.5 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 specified client-type is no longer supported/active. When the the specified client-type is no longer supported/active. When the
PEP detects a lost connection due to a keep-alive timeout condition PEP detects a lost connection due to a keep-alive timeout condition
it should explicitly send a Client-Close message for each opened it 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 reconnect again or try a backup/alternative PDP. When the PDP is to reconnect again or try a backup/alternative PDP. When the PDP is
shutting down, it should also explicitly send a Client-Close to all 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 5. Security Considerations
The security of RSVP messages is provided by inter-router MD5 The security of RSVP messages is provided by inter-router MD5
authentication [MD5]. This assumes a chain-of-trust model for inter authentication [MD5]. This assumes a chain-of-trust model for inter
PEP authentication. Security between the client (PEP) and server PEP authentication. Security between the client (PEP) and server
(PDP) is provided by IPSEC [IPSEC]. (PDP) is provided by IPSEC [IPSEC].
To ensure the client (PEP) is communicating with the correct policy To ensure the client (PEP) is communicating with the correct policy
server (PDP) involves two issues: authentication of the policy server (PDP) involves two issues: authentication of the policy
client and server using a shared secret, and consistent proof that client and server using a shared secret, and consistent proof that
the connection remains valid. The shared secret requires manual the connection remains valid. The shared secret requires manual
skipping to change at page 30, line 5 skipping to change at page 29, line 24
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-
Type values. IETF Consensus as identified in [IANA-CONSIDERATIONS]
is required to introduce new values for these numbers and,
therefore, new objects into the base COPS protocol.
Additional Context Object R-Types, Reason-Codes, Report-Types,
Decision Object Command-Codes/Flags, and Error-Codes may be defined
for use with future Client-types, but such additions require IETF
Consensus as defined in [IANA-CONSIDERATIONS].
Context Object M-Types, Reason Sub-Codes, and Error Sub-codes may be
defined relative to a particular Client-type following the same IANA
considerations as their respective Client-type.
7. References 7. References
[RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP)
Version 1 - Functional Specification", RFC 2205, September Version 1 - Functional Specification", RFC 2205, September
1997. 1997.
[WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission
Control", Internet-Draft, draft-ietf-rap-framework-01.txt, Control", Internet-Draft, draft-ietf-rap-framework-01.txt,
November 1998. November 1998.
[SRVLOC]Guttman, E. et al., "Service Location Protocol", Internet- [SRVLOC]Guttman, E. et al., "Service Location Protocol , Version 2",
Draft, draft-ietf-svrloc-protocol-v2-01.txt, October 1997. Internet-Draft, draft-ietf-svrloc-protocol-v2-12.txt,
February 1999.
[INSCH] Shenker, S., Wroclawski, J., "General Characterization [INSCH] Shenker, S., Wroclawski, J., "General Characterization
Parameters for Integrated Service Network Elements", RFC Parameters for Integrated Service Network Elements", RFC
2215, September 1997. 2215, September 1997.
[IPSEC] Atkinson, R., "Security Architecture for the Internet [IPSEC] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC1825, August 1995. Protocol", RFC1825, August 1995.
[MD5] Baker, F., "RSVP Cryptographic Authentication", Internet- [MD5] Baker, F., "RSVP Cryptographic Authentication", Internet-
Draft, draft-ietf-rsvp-md5-05.txt, August 1997. Draft, draft-ietf-rsvp-md5-05.txt, August 1997.
 End of changes. 

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