draft-ietf-rap-cops-00.txt   draft-ietf-rap-cops-01.txt 
Internet Draft Jim Boyle Internet Draft Jim Boyle
Expiration: July 1998 MCI Expiration: September 1998 MCI
File: draft-ietf-rap-cops-00.txt Ron Cohen File: draft-ietf-rap-cops-01.txt Ron Cohen
Class Data Systems Class Data Systems
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 20, 1998 Last Updated: March 12, 1998
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at page 1, line 41 skipping to change at page 1, line 41
"working draft" or "work in progress". "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. munnari.oz.au.
A revised version of this draft document will be submitted to the A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community. RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire before June 1998. Distribution of this draft is document will expire before September 1998. Distribution of this
unlimited. draft is unlimited.
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 with similar properties policy control over QoS Signaling Protocols with similar properties
as ReSerVation Protocol (RSVP). It is designed to be extensible so as ReSerVation Protocol (RSVP). It is designed to be extensible so
that other kinds of policy clients may be supported in the future. that other kinds of policy clients may be supported in the future.
The model does not make any assumptions about the decision methods The model does not make any assumptions about the decision methods
of the policy server, but is based on the server returning responses of the policy server, but is based on the server returning responses
to policy requests. to policy requests.
skipping to change at page 2, line 32 skipping to change at page 2, line 32
[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 framework document for policy based admission control [WRK]. the framework document for policy based admission control [WRK].
A chief objective of our proposal is to begin with a simple but A chief objective of our proposal is to begin with a simple but
extensible design. The main characteristics of the proposed protocol extensible design. The main characteristics of the proposed protocol
include: include:
1. The protocol employs a client/server model where the PEP 1. The protocol employs a client/server model where the PEP
sends requests, updates, and retractions to the remote PDP and sends requests, updates, and deletes to the remote PDP and the
the PDP returns decisions back to the PEP. PDP 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. Thus, even though the protocol was created specific information. Thus, even though the protocol was created
for the administration and enforcement of policies in for the administration and enforcement of policies in
skipping to change at page 4, line 13 skipping to change at page 4, line 13
Service discovery is outside the scope of this protocol, however. Service discovery is outside the scope of this protocol, however.
The PEP uses the TCP connection to send requests to and receive The PEP uses the TCP connection to send requests to and receive
responses from the remote PDP. Communication between the PEP and responses from the remote PDP. Communication between the PEP and
remote PDP is mainly in the form of a stateful request/response remote PDP is mainly in the form of a stateful request/response
exchange, though the remote PDP may occasionally send an unsolicited exchange, though the remote PDP may occasionally send an unsolicited
response to the PEP to force a change in a previously approved response to the PEP to force a change in a previously approved
request state. The PEP also has the capacity to report to the remote request state. The PEP also has the capacity to report to the remote
PDP that it has committed to an accepted request state for purposes PDP that it has committed to an accepted request state for purposes
of accounting and monitoring. Finally, the PEP is responsible for of accounting and monitoring. Finally, the PEP is responsible for
the deletion (retraction) of a request state that is no longer the deletion of a request state that is no longer applicable or
applicable. updating a request state on the PDP when it likewise changes at the
PEP.
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, and transferring client specific policy decisions, reporting errors, and transferring client specific
information. information.
To distinguish between different kinds of clients, the type of To distinguish between different kinds of clients, the type of
client is identified in each message. Different types of clients may client is identified in each message. Different types of clients may
skipping to change at page 4, line 56 skipping to change at page 5, line 4
the PEP must send its local decision information to the remote PDP the 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 via a LDP decision object. The PEP must then abide by the PDP's
decision as it is absolute. 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
is achieved by having both the PEP and remote PDP constantly verify is achieved by having both the PEP and remote PDP constantly verify
their connection to each other via keep-alive messages. When a their connection to each other via keep-alive messages. When a
failure is detected, the PEP must try to reconnect to the remote PDP failure is detected, the PEP must try to reconnect to the remote PDP
or attempt to connect to an new/alternative PDP. Once a connection or attempt to connect to a new/alternative PDP. Once a connection is
is reestablished, the remote PDP may request that all the PEP's reestablished, 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). After failure and before the new connection is are to be reissued). After failure and before the new connection is
fully functional, disruption of service can be minimized if the PEP fully functional, disruption of service can be minimized if the PEP
caches previously communicated decisions and continues to use them caches previously communicated decisions and continues to use them
for some limited amount of time. (Discussions of specific provisions for some limited amount of time. (Discussions of specific provisions
for such a mechanism are outside of the scope of this draft, and are for such a mechanism are outside of the scope of this draft, and are
left to client specific implementations). left to client specific implementations).
2. The Protocol 2. The Protocol
This section describes the message formats and objects exchanged This section describes the message formats and objects exchanged
between the PEP and remote PDP. between the PEP and remote PDP.
2.1 Common Header 2.1 Common Header
Each COPS message consists of the COPS header followed by a number Each COPS message consists of the COPS header followed by a number
of typed objects. of typed objects.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
|Version|XXXXXX| Op Code | Client Type | |Version| //// | Op Code | Client Type |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Message Length | | Message Length |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
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.
Op Code: 8 bits Op Code: 8 bits
The COPS operations: The COPS operations:
1 = Request (REQ) 1 = Request (REQ)
2 = Response (RES) 2 = Response (RES)
3 = Unsolicited Response (USR) 3 = Unsolicited Response (USR)
4 = Report State (RPT) 4 = Report State (RPT)
5 = Delete Request State (DRQ) 5 = Delete Request State (DRQ)
6 = Synchronize State Req (SSQ) 6 = Synchronize State Req (SSQ)
7 = Client-Open (OPN) 7 = Client-Open (OPN)
8 = Client-Accept (CAT) 8 = Client-Accept (CAT)
9 = Keep Alive (KA) 9 = Keep-Alive (KA)
10= Client-Close (CC)
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. all encapsulated objects is relative to the client type.
(See Appendix A for the RSVPv1 client type ID). (See Appendix A for the RSVPv1 client type ID).
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
skipping to change at page 7, line 39 skipping to change at page 7, line 39
4 = In Interface 4 = In Interface
5 = Out Interface 5 = Out Interface
6 = Reason code 6 = Reason code
7 = Decision 7 = Decision
8 = LDP Decision 8 = LDP Decision
9 = Protocol Error 9 = Protocol Error
10 = Client Specific Info 10 = Client Specific Info
11 = Timer 11 = Timer
12 = PEP Identification 12 = PEP Identification
13 = Report Type 13 = Report Type
14 = PDP Address
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)
Unique value that identifies an installed request state. This Unique value that identifies an installed request state. This
identification is used by most COPS operations. The request state identification is used by most COPS operations. The request state
corresponding to this handle must be explicitly deleted by the corresponding to this handle must be explicitly deleted by the
client when no longer applicable. client when no longer applicable.
skipping to change at page 10, line 19 skipping to change at page 10, line 19
Reason Code: Reason Code:
1 = Unknown 1 = Unknown
2 = Management 2 = Management
3 = Preempted 3 = Preempted
4 = Tear 4 = Tear
5 = Timeout 5 = Timeout
6 = Route Change 6 = Route Change
7 = Insufficient Resources 7 = Insufficient Resources
8 = PDP's Directive 8 = PDP's Directive
9 = Client Specific (details in sub-code) 9 = Client Specific (details in sub-code)
10= Synchronize Handle Unknown
2.2.7 Decision Object (Decision) 2.2.7 Decision Object (Decision)
Decision made by the PDP. Must appear in replies. The specific Decision made by the PDP. Must appear in replies. The specific
decision objects required in a response to a particular request decision objects required in a response to a particular request
depend on the type of client. depend on the type of client.
C-Num = 7 C-Num = 7
CType = 1, Decision Flags (mandatory!) CType = 1, Decision Flags (mandatory!)
A flag bit set to 1 implies a negative decision for that flag.
Flags not applicable to a given request type should be ignored.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Flags | | Flags |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Flags: Flags:
0x01 = Reject Incoming (Reject if set) 0x01 = Reject Incoming (Reject if set)
0x02 = Do Not Allocate Resources (Reject if set) 0x02 = Do Not Allocate Resources (Reject if set)
0x04 = Drop Outgoing (do not forward message if set) 0x04 = Drop Outgoing (do not forward message if set)
0x08 = Trigger Error (Trigger error message if set) 0x08 = Trigger Error (Trigger error message if set)
skipping to change at page 11, line 15 skipping to change at page 11, line 18
Preemption Priority Preemption Priority
Priority is used by PEP to decide which of the flows should be Priority is used by PEP to decide which of the flows should be
preempted, when not enough resources are available on the preempted, when not enough resources are available on the
interface. For RSVP, when preemption is supported, a higher interface. For RSVP, when preemption is supported, a higher
priority reservation can preempt an installed reservation with priority reservation can preempt an installed reservation with
lower priority. lower priority.
CType = 3, Replacement Data (Optional) CType = 3, Replacement Data (Optional)
Format includes a list of client specific data that is to be This object is typically applicable as a response for an
used in place of information specified in the request. Use of outgoing request. Format includes a list of client specific data
this decision type is optional. For RSVP, this decision is used that is to be used in place of information specified in the
to change objects carried in RSVP messages. For example, request. Use of this decision type is optional. For RSVP, this
replacing the policy data objects when forwarding a Resv message decision is used to change objects carried in RSVP messages. For
upstream is possible due to this decision type. If this decision example, replacing the policy data objects when forwarding a
doesn't appear in a response, all objects are passed as if the Resv message upstream is possible due to this decision type. If
PDP was not there. To remove an object the decision should carry this decision doesn't appear in a response, all objects are
an empty object of length 4 (header only). Appendix A specifies passed as if the PDP was not there. To remove an object the
the list of RSVP objects that can be replaced. decision should carry an empty object of length 4 (header only).
Appendix A specifies the list of RSVP objects that can be
replaced.
CType = 4, Client Specific Decision Data (Optional) CType = 4, Client Specific Decision Data (Optional)
Proprietary decision types can be introduced using the Client Proprietary decision types can be introduced using the Client
Data Decision Object. Like the Replacement Data object, client Data Decision Object. Like the Replacement Data object, client
specific information is encapsulated within the Client Data specific information is encapsulated within the Client Data
Object. Object.
2.2.8 LDP Decision Object (LDPDecision) 2.2.8 LDP Decision Object (LDPDecision)
skipping to change at page 11, line 53 skipping to change at page 12, line 4
2.2.9 Error Object (Error) 2.2.9 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.
C-Num 9, C-Type = 1 C-Num 9, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code | | Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Error-Code: Error-Code:
1 = Bad handle 1 = Bad handle
2 = Invalid handle reference 2 = Invalid handle reference
3 = Bad message format 3 = Bad message format
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
9 = Communication Failure
10= Client Specific (details in sub-code)
2.2.10 Client Specific Information Object (ClientSI) 2.2.10 Client Specific Information Object (ClientSI)
All objects specific to a client's signaling protocol must be All objects/attributes specific to a client's signaling protocol
encapsulated within one or more Client Information Objects. must be encapsulated within one or more Client Information Objects.
The various types of this object are required for requests, and used
in reports and opens when required. Additional ClientSI encapsulated
data unknown to the PDP can be safely ignored by the PDP.
Class-Num = 10, C-Type = 1 Class-Num = 10,
C-Type = 1, Request ClientSI.
Variable-length field. The format of the data encapsulated in the Variable-length field. The format of the data encapsulated in the
ClientSI object is determined by the client type. ClientSI object is determined by the client type. Used in request
queries.
C-Type = 2, Report ClientSI.
Variable-length field. The format of the data encapsulated in the
ClientSI object is determined by the client type. Used in COPS
report messages when required.
C-Type = 3, Client-Open ClientSI.
Variable-length field. The format of the data encapsulated in the
ClientSI object is determined by the client type. Used in COPS
clientSI messages for feature negotiation, etc. when required.
2.2.11 Timer Object (Timer) 2.2.11 Timer Object (Timer)
Times are encoded as 32-bit integer values and are in units of Times are encoded as 2 octet integer values and are in units of
seconds. The time value is treated as a delta. seconds. The time value is treated as a delta.
Class-Num = 11, C-Type = 1 (keep-alive timer value) Class-Num = 11, C-Type = 1, Keep-alive timer value
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Timer Value | | ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
2.2.12 PEP Identification Object (PEPID) 2.2.12 PEP Identification Object (PEPID)
The PEP Identification Object is used to identify the PEP client to The PEP Identification Object is used to identify the PEP client to
the remote PDP. It is required for Client-Open messages. the remote PDP. It is required for Client-Open messages.
C-Num = 12, C-Type = 1 C-Num = 12, C-Type = 1
Variable-length field (zero padded ASCII symbolic name) configured Variable-length field (zero padded ASCII symbolic name) configured
skipping to change at page 13, line 9 skipping to change at page 13, line 29
the PEP represented as a string is expected in the PEPID. the PEP represented as a string is expected in the PEPID.
2.2.13 Report-Type Object (Report-Type) 2.2.13 Report-Type Object (Report-Type)
The Type of Report on the request state associated with a handle: The Type of Report on the request state associated with a handle:
C-Num = 13, C-Type = 1 C-Num = 13, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Report-Type | XXXXXXXXXXXXX | | Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Report-Type: Report-Type:
1 = Commit : State was installed on client (PEP) 1 = Commit : PEP's local resources now allocated
2 = Accounting: Accounting update for an installed state 2 = Accounting: Accounting update for an installed state
3 = No Commit : PEP's resource allocation failure
2.2.14 PDP Address (PDPAddr)
A PDP when closing a PEP session for a particular client type may
optionally use this object to redirect the PEP to another PDP server
via this object:
C-Num = 14,
C-Type = 1, IPv4 Address
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
C-Type = 2, IPv6 Address (16 octets, as shown for In-interface)
3. Message Content 3. Message Content
This section describes the basic messages exchanged between a PEP This section describes the basic messages exchanged between a PEP
and a remote PDP as well as their contents. and a remote PDP as well as their contents.
3.1 Request (REQ) PEP -> PDP 3.1 Request (REQ) PEP -> PDP
The PEP establishes a request state handle for which the remote PDP The PEP establishes a request state handle for which the remote PDP
may maintain a state. The remote PDP then uses this handle to refer may maintain a state. The remote PDP then uses this handle to refer
to the exchanged information and decisions. to the exchanged information and decisions.
Once a stateful handle is established for a new request, any Once a stateful handle is established for a new request, any
subsequent modifications of the request can be made using the REQ subsequent modifications of the request can be made using the REQ
message specifying the previously installed handle. message specifying the previously installed handle. The PEP is
responsible for notifying the PDP whenever its local state changes
so the PDP's state will mirror the PEP's state.
The format of the Request message is as follows: The format of the Request message is as follows:
<Request> ::= <Common Header> <Request> ::= <Common Header>
<Handle> <Handle>
<Context> <Context>
[<IN-Int>] [<IN-Int>]
[<OUT-Int>] [<OUT-Int>]
<ClientSI> <ClientSI>
[<list of HandleRefs>] [<list of HandleRefs>]
skipping to change at page 14, line 42 skipping to change at page 14, line 44
the other objects are to be interpreted. It also is used to the other objects are to be interpreted. It also is used to
determine the kind of response to be returned from the policy determine the kind of response to be returned from the policy
server. This response might be related to admission control, server. This response might be related to admission control,
resource allocation, or object forwarding and substitution. resource allocation, or object forwarding and substitution.
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 only used if the client is participating about to be sent. They are only used if the client is participating
along the path of a signaling protocol. along the path of a signaling protocol.
ClientSI, the client specific information object holds the client ClientSI (C-Type = 1), the client specific information object holds
type specific data for which a policy decision needs to be made. the client type specific data for which a policy decision needs to
be made.
The handle reference objects are used to refer to state information The handle reference objects are used to refer to state information
currently installed on the PDP that is associated with the current currently installed on the PDP that is associated with the current
request. request.
Finally, LDPDecision object holds information regarding the local Finally, LDPDecision object holds information regarding the local
decision made by the LDP. decision made by the LDP.
3.2 Response (RES) PDP -> PEP 3.2 Response (RES) PDP -> PEP
skipping to change at page 15, line 18 skipping to change at page 15, line 18
associated handle and the decision. If there was a protocol error an associated handle and the decision. If there was a protocol error an
error object is returned instead. error object is returned instead.
In order to avoid the issue of keeping track of which Request a In order to avoid the issue of keeping track of which Request a
particular response belongs to, it is important that, for a given particular response belongs to, it is important that, for a given
handle, there be at most one outstanding response per query. This handle, there be at most one outstanding response per query. This
essentially means that the PEP should not issue more than one essentially means that the PEP should not issue more than one
REQ(for a given handle) before it receives a corresponding RES. To REQ(for a given handle) before it receives a corresponding RES. To
avoid deadlock, the client can always timeout after issuing a avoid deadlock, the client can always timeout after issuing a
request. It can then delete the timed-out handle, and try again request. It can then delete the timed-out handle, and try again
using a different (new) one. using a different (new) handle.
The format of the Response message is as follows: The format of the Response message is as follows:
<Response> ::= <Common Header> <Response> ::= <Common Header>
<Handle> <Handle>
<Decision(s)> || <Error> <Decision(s)> || <Error>
The response may include either an Error object or decision The response may include either an Error object or one or more
object(s). COPS protocol problems are reported in the Error object decision objects. COPS protocol problems are reported in the Error
(e.g. an error with the format of the original request). Decision object (e.g. an error with the format of the original request).
object(s) depend on the context of the associated request and the Decision object(s) depend on the context of the associated request
type of client. and the type of client.
3.3 Unsolicited Response (USR) PDP -> PEP 3.3 Unsolicited Response (USR) PDP -> PEP
The remote PDP can also send an unsolicited response to a PEP to The remote PDP can also send an unsolicited response to a PEP to
report a different response than the one previously communicated. report a different response than the one previously communicated.
For example, the PDP may admit a new flow and change its mind to For example, the PDP may admit a new flow and change its mind to
reject it sometime later. The change of mind is communicated using reject it sometime later. The change of mind is communicated using
the USR message. the USR message.
The format for an USR is the same as that for a RES and similarly, The format for an USR is the same as that for a RES and similarly,
it dependents on the context of the original request. it dependents on the context of the original request.
3.4 Report State (RPT) PEP -> PDP 3.4 Report State (RPT) PEP -> PDP
This message is used by the PEP to communicate the change in status This message is used by the PEP to communicate a change in the
of a previously installed request state to the server. A commit status of a previously installed request state to the server. A
report indicates to the PDP that a particular policy directive has commit or no commit report indicates to the PDP that a particular
been acted upon. (In RSVP this would mean that the reservation policy directive has or has not been acted upon as is relevant for
successfully passed capacity admission control). accounting purposes. (In RSVP this would mean that a reservation
passed or failed local capacity admission control).
The Report State may also be used to provide periodic updates of The Report State may also be used to provide periodic updates of
client specific information for accounting and state monitoring client specific information for accounting and state monitoring
purposes depending on the type of the client. In such cases the purposes depending on the type of the client. In such cases the
accounting report type should be specified utilizing the client accounting report type should be specified utilizing the client
specific information object. specific information object (C-Type = 2).
<Report State> ::== <Common Header> <Report State> ::== <Common Header>
<Handle> <Handle>
<Report-Type> <Report-Type>
[ <Client Specific Information> ] [ <Client Specific Information> ]
3.5 Delete Request State (DRQ) PEP -> PDP 3.5 Delete Request State (DRQ) PEP -> PDP
This message indicates to the remote PDP that the request state must This message indicates to the remote PDP that the request state is
be deleted. This will be used by the remote PDP to initiate the no longer available in the PEP and must be deleted. This will be
appropriate housekeeping actions. The reason code object is used by the remote PDP to initiate the appropriate housekeeping
interpreted with respect to the client type. actions. The reason code object is interpreted with respect to the
client type.
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>
<Handle> <Handle>
<Reason> <Reason>
Given the stateful nature of COPS, it is important that when a
request state is finally removed from the PEP, a DRQ message for
this request state is sent to the PDP so the corresponding state may
likewise be removed on the PDP. Request states not explicitly
deleted by the PEP will be maintained by the PDP until either the
client session is closed or the connection is terminated.
3.6 Synchronize State Request (SSQ) PDP -> PEP 3.6 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>
[<Handle>] [<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
Handle is present, only the state associated with this handle is Handle is present, only the state associated with this handle is
synchronized. Otherwise, all the client state should be synchronized synchronized. If the client does not recognize the requested handle,
it should immediately send a DRQ message to the PDP for the handle
that was specified in the SSQ message. If no handle is specified in
the SSQ message, all the active client state should be synchronized
with the PDP. with the PDP.
The client performs state synchronization by re-issuing request The client performs state synchronization by re-issuing request
queries of the specified client type for the existing state in the queries of the specified client type for the existing state in the
PEP. PEP.
3.7 Client-Open (OPN) PEP -> PDP 3.7 Client-Open (OPN) PEP -> PDP
The Client-Open message can be used to provide the characteristics The Client-Open message can be used by the PEP to specify to the PDP
of the connection, suggested time intervals for the keep-alive the client types the PEP can support, a *suggested* time interval
messages, and information on the locally known policy elements. for keep-alive messages, or client specific feature negotiation. A
Client-Open message can be sent to the PDP at any time and multiple
Client-Open messages for the same client type are allowed (in case
of global state changes).
<Client-Open> ::= <Common Header> <Client-Open> ::= <Common Header>
<PEPID> <PEPID>
[<Timer>] [<Timer>]
[<ClientSI>]
The PEPID is a symbolic, variable length name that identifies the The PEPID is a symbolic, variable length name that identifies the
specific client to the PDP. Values for the PEPID are configurable by specific client to the PDP. Values for the PEPID are configurable by
administrators of administrative domains and are of direct administrators of administrative domains and are of direct
significance to the COPS protocol. By default, the PEPID specifies significance to the COPS protocol. By default, the PEPID specifies
the primary IP address in the form of a string for the PEP in the primary IP address in the form of a string for the PEP in
question. question.
If included, the timer corresponds to PEP's preference for the If included, the timer corresponds to PEP's preference for the
maximum intermediate time between the generation of messages for maximum intermediate time between the generation of messages for
connection verification. connection verification.
Finally, a ClientSI (C-Type = 3) object can be included for relaying
global information about the PEP to the PDP when required (as
specified in the appropriate extensions document).
3.8 Client-Accept (CAT) PDP -> PEP 3.8 Client-Accept (CAT) PDP -> PEP
The Client-Accept message is used to respond to the Client-Open The Client-Accept message is used to positively respond to the
message. This message will return to the PEP either a timer object Client-Open message. This message will return to the PEP a timer
indicating the expected time interval between keep-alive messages, object indicating the expected time interval between keep-alive
or an error object indicating that an error occurred (e.g. requested messages.
client type is not supported by the remote PDP).
<Client-Accept> ::= <Common Header> <Client-Accept> ::= <Common Header>
<Timer> || <Error> <Timer>
If the PDP refuses the client, it will return an Error object to If the PDP refuses the client, it will instead issue a Client-Close
describe the reason. message.
The timer corresponds to maximum acceptable intermediate time The timer corresponds to maximum acceptable intermediate time
between the generation of messages by the PDP and PEP. The timer between the generation of messages by the PDP and PEP. The timer
value is determined by the PDP taking into account the client's value is determined by the PDP taking into account the client's
preference established with the OPN message. A timer value of preference established with the OPN message. A timer value of 0
0xFFFFFFFF implies no secondary connection verification is implies no secondary connection verification is necessary.
necessary.
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP
The keep-alive message only needs to be transmitted when there has The keep-alive message only needs to be transmitted when there has
been no activity between the client and server for a period been no activity between the client and server for a period
approaching half that of the minimum timer value negotiated with the approaching half that of the minimum of all timer values negotiated
OPN & CAT messages. It is a validation for each side that the other with the OPN & CAT messages. It is a validation for each side that
is still functioning. the connection is still functioning.
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
verification).
<Keep-Alive> ::= <Common Header> <Keep-Alive> ::= <Common Header>
Both client and server may assume the connection is insufficient for Both client and server may assume the connection is insufficient for
the client type with the minimum time value (specified in the CAT the client type with the minimum time value (specified in the 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 Client-Close (CC) PEP -> PDP, PDP -> PEP
The Client-Close message can be issued by either the PDP or PEP to
notify the other that a particular type of client is no longer being
supported.
<Client-Close> ::= <Common Header>
[<Error>]
[<PDPAddr>]
An Error object is optionally included to describe the reason for
the close due to an error condition (e.g. requested client type is
not supported by the remote PDP or client failure).
A PDP may optionally include a PDP-Address object in order to inform
the PEP of the alternate PDP it should use for the client type
specified in the common header.
4. Common Operation 4. Common Operation
This section describes the typical exchanges between remote PDP This section describes the typical exchanges between remote PDP
servers and PEP clients. servers and PEP clients.
After a connection is established between the PEP and a remote PDP, Sometime after a connection is established between the PEP and a
the PEP will send one or more Client-Open messages to the remote remote PDP, the PEP will send one or more Client-Open messages to
PDP, one for each client type supported by the PEP. The open message the remote PDP, at least one for each client type supported by the
should contain the common header noting one client type supported by PEP. The open message should contain the common header noting one
the PEP. The remote PDP will then respond with a Client-Accept client type supported by the PEP. The remote PDP will then respond
message echoing back each of the client types the PEP supports that with a Client-Accept message echoing back each of the client types
it can support as well. If a specific client type is not supported the PEP supports that it can support as well. If a specific client
by the PDP, the corresponding Client-Accept message sent back to the type is not supported by the PDP, the PDP will instead respond with
PEP will include an error object specifying the client type is not a Client-Close specifying the client type is not supported, and
supported. The PDP will include the timer interval between keep- possibly suggesting an alternate PDP address. Otherwise, the PDP
alive messages in its Client-Accept. will specify the timer interval between keep-alive messages in its
Client-Accept and the PEP can begin issuing requests to the PDP.
When the PEP receives an event that requires a new policy decision When the PEP receives an event that requires a new policy decision
it sends a request message to the remote PDP. The remote PDP then it sends a request message to the remote PDP. The remote PDP then
makes a decision and sends a response back to the PEP. Since the makes a decision and sends a response back to the PEP. Since the
request is stateful, the request will be remembered, or installed, request is stateful, the request will be remembered, or installed,
on the remote PDP. The unique handle, specified in both the request on the remote PDP. The unique handle, specified in both the request
and its corresponding response identifies this request state. The and its corresponding response identifies this request state. The
PEP is responsible for deleting this request state once the request PEP is responsible for deleting this request state once the request
is no longer applicable. is no longer applicable.
The PEP may 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 response back to the then expected to make new decisions and send a response back to the
PEP. Likewise, the server may change a previously issued decision on PEP. Likewise, the server may change a previously issued decision on
any currently installed request state at any time by issuing an any currently installed request state at any time by issuing an
asynchronous response. At all times the PEP module is expected to asynchronous response. At all times the PEP module is expected to
abide by the PDP's decisions. abide by the PDP's decisions and notify the PDP on state changes.
The PEP may also notify the remote PDP of the local status of an The PEP may also notify the remote PDP of the local status of an
installed request using the report message where appropriate. The installed request using the report message where appropriate. The
report message is to be used to signify when billing should report message is to be used to signify when billing should
effectively begin, or to produce periodic updates for monitoring and effectively begin, or to produce periodic updates for monitoring and
accounting purposes depending on the client. This message can carry accounting purposes depending on the client. This message can carry
client specific information when needed. client specific information when needed.
Finally, to validate the connection between the client and server is To validate the connection between the client and server is still
still functioning, the keep-alive message is used. If no COPS functioning, the keep-alive message is used. If no COPS message is
message is generated within one half the minimum timer value generated within one half the minimum timer value interval, a keep-
interval, a keep-alive message needs to be generated. Both the PEP alive message needs to be generated. Both the PEP and remote PDP are
and remote PDP are expected to follow this procedure. expected to follow this procedure.
Finally, Client-Close messages are used to negate the affects of the
corresponding Client-Open messages, notifying the other side that
the specified client type is no longer supported/active.
5. Security 5. Security
The security of RSVP messages is provided by inter-router MD5 The security of RSVP messages is provided by inter-router MD5
authentication [MD5]. This assumes a chain-of-trust model for inter authentication [MD5]. This assumes a chain-of-trust model for inter
PEP authentication. Security between the client (PEP) and server PEP authentication. Security between the client (PEP) and server
(PDP) is provided by IPSEC [IPSEC]. (PDP) is provided by IPSEC [IPSEC].
To ensure the client (PEP) is communicating with the correct policy To ensure the client (PEP) is communicating with the correct policy
server (PDP) involves two issues: authentication of the policy server (PDP) involves two issues: authentication of the policy
skipping to change at page 20, line 11 skipping to change at page 21, line 11
configuration of keys, which is a maintenance issue. IPSEC AH may be configuration of keys, which is a maintenance issue. IPSEC AH may be
used for the validation of the connection; IPSEC ESP may be used to used for the validation of the connection; IPSEC ESP may be used to
provide both validation and secrecy. provide both validation and secrecy.
6. Open issues 6. Open issues
6.1 Bi-directional Connection Establishment: 6.1 Bi-directional Connection Establishment:
Currently, only the PEP is supposed to connect with the PDP. It Currently, only the PEP is supposed to connect with the PDP. It
might be useful to have the PDP proactive in establishing might be useful to have the PDP proactive in establishing
connections with its PEPs. Such would potentially simplify PEP connections with its PEPs (via a separate COPS PEP port). Such would
configuration and allow a primary PDP that has failed to notify its potentially simplify PEP configuration and allow a primary PDP that
clients that it is functional again. has failed to notify its clients that it is functional again. Such
functionality will be specified in the appropriate COPS Extensions
6.2 Client Type Close/Redirect: document. In the meantime, PEPs should at least be locally
configured to connect to their appropriate Primary PDP/Backup PDP.
Is there a need for a Close message per client type so the PEP and
PDP can notify each other in case of a capability change? If there
is a close, should the PDP be able to tell the PEP which PDP server
it should now use (redirect)?
6.3 Division of Labor Negotiation:
How can (and is there a need for) the PEP to notify the remote PDP
of its LDP's capabilities (e.g. the LDP can directly authenticate
user information)?
6.4 Group ID:
Is there a need for a Group ID for identifying the group a client
belongs akin to how the PEPID identifies an individual client?
6.5 RSVP Object Replacement: 6.2 RSVP Object Replacement:
Should the PDP be capable of directing the RSVP PEP to replace other Should the PDP be capable of directing the RSVP PEP to replace other
objects than the Policy Data object (e.g. FlowSpec)? If so, for objects than the Policy Data object (e.g. FlowSpec)? If so, which
which request types? RSVP objects and for which request types?
6.6 RSVP Priority Element Definition (other work). 6.3 RSVP Policy Data Priority Element Definition.
The object format of the Policy Data Element for Priority
representation will be described in another document.
7. References 7. References
[RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP)
Version 1 - Functional Specification", RFC 2205, September Version 1 - Functional Specification", RFC 2205, September
1997. 1997.
[WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission
Control", Internet-Draft, draft-ietf-rap-framework-00.txt, Control", Internet-Draft, draft-ietf-rap-framework-00.txt,
November 1997. November 1997.
skipping to change at page 22, line 5 skipping to change at page 22, line 32
[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.
[RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP)
- Version 1 Message Processing Rules", RFC 2209, September - Version 1 Message Processing Rules", RFC 2209, September
1997. 1997.
[UserID]Yadav, S., Pabbati, R., Ford, P., Herzog, S., "User Identity
Representation for RSVP", Internet-Draft, draft-ietf-rap-
user-identity-00.txt, March 1998.
8. Author Information and Acknowledgments 8. Author Information and Acknowledgments
Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar, Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar,
Russell Fenger, Laura Cunningham, Roch Guerin, Ping Pan, and Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan,
Dimitrios Pendarakis for their valuable contributions. and Dimitrios Pendarakis for their valuable contributions.
Jim Boyle Ron Cohen Jim Boyle Ron Cohen
MCI Class Data Systems MCI Class Data Systems
2100 Reston Parkway 13 Hasadna St. 2100 Reston Parkway 13 Hasadna St.
Reston, VA 20191 Ra'anana 43650 Israel Reston, VA 20191 Ra'anana 43650 Israel
703.715.7006 972.9.7462020 703.715.7006 972.9.7462020
jboyle@mci.net ronc@classdata.com jboyle@mci.net ronc@classdata.com
David Durham Raju Rajan David Durham Raju Rajan
Intel IBM T.J. Watson Research Cntr Intel IBM T.J. Watson Research Cntr
skipping to change at page 23, line 30 skipping to change at page 24, line 30
The message type information found in the RSVP message header is The message type information found in the RSVP message header is
represented by the M-Type in the COPS Context Object. represented by the M-Type in the COPS Context Object.
All objects contained within RSVP messaging are expected to be All objects contained within RSVP messaging are expected to be
encapsulated in the Client Specific Information Object without encapsulated in the Client Specific Information Object without
alteration. Multiple RSVP objects may be contained within a single alteration. Multiple RSVP objects may be contained within a single
Client Specific Information Object exchanged between the PEP and Client Specific Information Object exchanged between the PEP and
remote PDP. remote PDP.
In support of the verification integrity of incoming RSVP messages,
the COPS protocol may optionally return a security key in the Client
Specific Decision Data object (C-Type = 4) useful for future
integrity checks by the PEP. Refer to the document on User Identity
Representation for RSVP [UserID] for details on the format and
application of this security key when supported by the PEP.
Finally, for the COPS outgoing message responses, RSVP objects may Finally, for the COPS outgoing message responses, RSVP objects may
be returned to the PEP from the remote PDP via the Replacement Data be returned to the PEP from the remote PDP via the Replacement Data
Decision Object. This object may contain multiple RSVP objects, but Decision Object. This object may contain multiple RSVP objects, but
is primarily concerned with returning the Policy Data object. is primarily concerned with returning the Policy Data object.
Objects included in the Replace Data Decision Object are to replace Objects included in the Replace Data Decision Object are to replace
their corresponding object in the RSVP message (typically for their corresponding object in the RSVP message (typically for
outgoing RSVP messages). outgoing RSVP messages).
A.3. Operation of COPS for Policy Control Over RSVP A.3. Operation of COPS for Policy Control Over RSVP
skipping to change at page 24, line 44 skipping to change at page 25, line 44
M-Type (Message Type) M-Type (Message Type)
The M-Type field in the Context Object may have one of the The M-Type field in the Context Object may have one of the
Following values that correspond to supported RSVP messages Following values that correspond to supported RSVP messages
In COPS: In COPS:
1 = Path 1 = Path
2 = Resv 2 = Resv
3 = PathErr 3 = PathErr
4 = PathErr 4 = ResvErr
Note: At this point, PathTear, ResvTear, and the Resv Confirm Note: The PathTear, ResvTear, and the Resv Confirm message types are
message types are not supported. not supported.
A.3.2 RSVP flows A.3.2 RSVP flows
Policy Control is performed per RSVP flow. An RSVP flow corresponds Policy Control is performed per RSVP flow. An RSVP flow corresponds
to an atomic unit of reservation as identified by RSVP (TC to an atomic unit of reservation as identified by RSVP (TC
reservation). It should be noted that RSVP allows multiple flows to reservation). It should be noted that RSVP allows multiple flows to
be packed (which is different from merged) into a single FF Resv be packed (which is different from merged) into a single FF Resv
message. To support such messages a separate COPS request must be message. To support such messages a separate COPS request must be
issued for each of the packed flows as if they were individual RSVP issued for each of the packed flows as if they were individual RSVP
messages. messages.
skipping to change at page 27, line 12 skipping to change at page 28, line 12
<client info: all objects in outgoing ResvErr message> <client info: all objects in outgoing ResvErr message>
In & Out (unicast combined request), ResvErr In & Out (unicast combined request), ResvErr
<handle><context: in & out, ResvErr><in-interface> <handle><context: in & out, ResvErr><in-interface>
<out-interface> <out-interface>
<client info: all objects in ResvErr message> <client info: all objects in ResvErr message>
A.3.9 Expected Decisions for RSVP Requests A.3.9 Expected Decisions for RSVP Requests
The expected decision information relative to a request for each The expected decision information relative to a request for each
applicable message type and request type combination is outlined applicable message type and request type combination is outlined
below: below ([optional]):
In, Path - In, Path -
<handle><Decision Flags> <handle><Decision Flags>[<Decision Data: Security Key>]
Out, Path - Out, Path -
<handle><Decision Flags><Decision Replacement: policy data> <handle><Decision Flags>[<DecisionReplacement: policy data>]
In & Out (combined request), Path - In & Out (combined request), Path -
<handle><Decision Flags><Decision Replacement: policy data> <handle><Decision Flags>[<DecisionReplacement: policy data>]
[<Decision Data: Security Key>]
In, Resv - In, Resv -
<handle><Decision Flags> <handle><Decision Flags>[<Decision Data: Security Key>]
Merge, Resv - Merge, Resv -
<handle><Decision Flags><Decision Priority> <handle><Decision Flags>[<Decision Priority>]
Out, Resv - Out, Resv -
<handle><Decision Flags><Decision Replacement: policy data> <handle><Decision Flags>[<DecisionReplacement: policy data>]
In & Merge (combined request, PEP can merge), Resv - In & Merge (combined request, PEP can merge), Resv -
<handle><Decision Flags><Decision Priority> <handle><Decision Flags>[<Decision Priority>][<Decision
Data: Security Key>]
In & Merge & Out (unicast combined request), Resv - In & Merge & Out (unicast combined request), Resv -
<handle><Decision Flags><Decision Priority> <handle><Decision Flags>[<Decision Priority>]
<Decision Replacement: policy data> [<DecisionReplacement: policy data>][<Decision Data:
Security Key>]
In, PathErr - In, PathErr -
<handle><Decision Flags> <handle><Decision Flags>
Out, PathErr - Out, PathErr -
<handle><Decision Flags><Decision Replacement: policy data> <handle><Decision Flags>[<DecisionReplacement: policy data>]
In & Out (combined request), PathErr - In & Out (combined request), PathErr -
<handle><Decision Flags><Decision Replacement: policy data> <handle><Decision Flags>[<DecisionReplacement: policy data>]
In, ResvErr - In, ResvErr -
<handle><Decision Flags> <handle><Decision Flags>
Out, ResvErr - Out, ResvErr -
<handle><Decision Flags><Decision Replacement: policy data> <handle><Decision Flags>[<DecisionReplacement: policy data>]
In & Out (combined request), ResvErr - In & Out (combined request), ResvErr -
<handle><Decision Flags><Decision Replacement: policy data> <handle><Decision Flags>[<DecisionReplacement: policy data>]
A.4 Illustrative Examples, Using COPS for RSVP A.4 Illustrative Examples, Using COPS for RSVP
A.4.1 Unicast Flow Example A.4.1 Unicast Flow Example
This section details the steps in using COPS for controlling a This section details the steps in using COPS for controlling a
Unicast RSVP flow. It details the contents of the COPS messages Unicast RSVP flow. It details the contents of the COPS messages
with respect to the following figure. with respect to the following figure.
PEP (router) PEP (router)
 End of changes. 

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