draft-ietf-rap-cops-03.txt   draft-ietf-rap-cops-04.txt 
Internet Draft Jim Boyle Internet Draft Jim Boyle
Expiration: April 1999 Level 3 Expiration: May 1999 Level 3
File: draft-ietf-rap-cops-03.txt Ron Cohen File: draft-ietf-rap-cops-04.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: November 18, 1998 Last Updated: December 18, 1998
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at page 1, line 41 skipping to change at page 1, line 41
"working draft" or "work in progress". "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. munnari.oz.au.
A revised version of this draft document will be submitted to the A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community. RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. This Discussion and suggestions for improvement are requested. This
document will expire before April 1999. Distribution of this draft document will expire before May 1999. Distribution of this draft is
is unlimited. unlimited.
Status of this Memo................................................1 Status of this Memo................................................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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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)...............15 2.2.9 Client Specific Information Object (ClientSI)...............15
2.2.10 Keep-Alive Timer Object (KATimer)..........................15 2.2.10 Keep-Alive Timer Object (KATimer)..........................15
2.2.11 PEP Identification Object (PEPID)..........................15 2.2.11 PEP Identification Object (PEPID)..........................15
2.2.12 Report-Type Object (Report-Type)...........................16 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).............................17 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...........................................19 2.4 Client Handle Usage...........................................18
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...................22 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 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................24 3.8 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................24
3.9 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................25 3.9 Client-Close (CC) 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 Shutdown..................................................27 4.5 PEP/PDP Close.................................................27
5. Security.......................................................28 5. Security.......................................................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
skipping to change at page 15, line 52 skipping to change at page 15, line 52
| ////////////// | KA Timer Value | | ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
2.2.11 PEP Identification Object (PEPID) 2.2.11 PEP Identification Object (PEPID)
The PEP Identification Object is used to identify the PEP client to The PEP Identification Object is used to identify the PEP client to
the remote PDP. It is required for Client-Open messages. the remote PDP. It is required for Client-Open messages.
C-Num = 12, C-Type = 1 C-Num = 12, C-Type = 1
Variable-length field configured by local administrators for the Variable-length field. It is a NULL terminated ASCII string that is
PEP. It is a NULL terminated ASCII string that is also zero padded also zero padded to a 32-bit word boundary (so the object length is
to a 32-bit word boundary (so the object length is a multiple of 4 a multiple of 4 octets). The PEPID must contain an ASCII string that
octets). For example, it can be the PEP's main IP address (not to be uniquely identifies the PEP within the policy domain in a manner
confused with the actual IP address used in the persistent TCP that is persistent across PEP reboots. For example, it may be the
connection). It may also be the PEP's DNS name, or any other symbol PEP's statically assigned IP address or DNS name. This identifier
that uniquely identifies each PEP within the policy domain. The may safely be used by a PDP as a handle for identifying the PEP in
choice of configuration bears no significance for the COPS protocol, its policy rules.
but does for policies at the PDP that may need to uniquely identify
individual PEPs. By default, at least the primary IP address of the
PEP represented as a string is expected in the PEPID.
2.2.12 Report-Type Object (Report-Type) 2.2.12 Report-Type Object (Report-Type)
The Type of Report on the request state associated with a handle: The Type of Report on the request state associated with a handle:
C-Num = 13, C-Type = 1 C-Num = 13, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Report-Type | ///////////// | | Report-Type | ///////////// |
skipping to change at page 18, line 5 skipping to change at page 17, line 49
2.3 Communication 2.3 Communication
The COPS protocol uses a single persistent TCP connection between The COPS protocol uses a single persistent TCP connection between
the PEP and a remote PDP. The remote PDP listens on a well-known the PEP and a remote PDP. The remote PDP listens on a well-known
port number (COPS=3288 [IANA]), and the PEP is responsible for port number (COPS=3288 [IANA]), and the PEP is responsible for
initiating the connection. The location of the remote PDP can either initiating the connection. The location of the remote PDP can either
be configured, or obtained via a service location mechanism be configured, or obtained via a service location mechanism
[SRVLOC]. Service discovery is outside the scope of this protocol, [SRVLOC]. Service discovery is outside the scope of this protocol,
however. however.
If a single PEP can support multiple client-types, it will 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. The PDP has the ability to either accept or reject type to a PDP over one or more TCP connections. Likewise, a PDP
each client-type independently. If a client-type is rejected, the residing at a given address may support one or more client-types.
PDP can redirect the PEP to an alternative PDP for a given client- Given the client-types it supports, a PDP has the ability to either
type. accept or reject each client-type independently. If a client-type is
rejected, the PDP can redirect the PEP to an alternative PDP for a
given client-type via COPS. Additional provisions for supporting
multiple client-types (perhaps from 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 19, line 24 skipping to change at page 19, line 18
request state, it will issue a delete message to the PDP for the request state, it will issue a delete message to the PDP for the
corresponding client handle. A handle MUST be explicitly deleted by corresponding client handle. A handle MUST be explicitly deleted by
the PEP before it can be used to identify a new request state. the PEP before it can be used to identify a new request state.
Handles referring to different request states must be unique. Handles referring to different request states must be unique.
2.5 Synchronization Behavior 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. The remote PDP may request that all the PEP's internal control. Additionally, the remote PDP may request that all the PEP's
state be resynchronized (all previously installed requests are to be internal state be resynchronized (all previously installed requests
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 is expected to communicate this fact to any PDP with which it is PDP must communicate this fact to any PDP with which it is able to
able to later reconnect. This is accomplished by including the later reconnect. This is accomplished by including the address of
address of the last PDP for which the PEP is still caching state in the last PDP for which the PEP is still caching state in the Client-
the Client-Open message. The <LastPDPAddr> object may only be Open message. The <LastPDPAddr> object will only be included for the
included for the last PDP with which the PEP was completely in sync. last PDP with which the PEP was completely in sync. If the service
If the service interruption was temporary and the PDP still contains interruption was temporary and the PDP still contains the complete
the complete state for the PEP, the PDP may choose not to state for the PEP, the PDP may choose not to synchronize all states.
synchronize all states. It is still the responsibility of the PEP to It is still the responsibility of the PEP to update the PDP of all
update the PDP of all state changes that occurred during the state changes that occurred during the disruption of service
disruption of service including any states communicated to the including any states communicated to the previous PDP that had been
previous PDP that had been deleted after the connection was lost. deleted after the connection was lost. These must be explicitly
These must be explicitly deleted after a connection is deleted after a connection is reestablished. If the PDP issues a
reestablished. If the PDP issues a synchronize request the PEP must synchronize request the PEP must pass all current states to the PDP
pass all current states to the PDP followed by a Synchronize State followed by a Synchronize State Complete message (thus completing
Complete message (thus completing the synchronization process). the synchronization process).
3. Message Content 3. Message Content
This section describes the basic messages exchanged between a PEP This section describes the basic messages exchanged between a PEP
and a remote PDP as well as their contents. 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
skipping to change at page 22, line 50 skipping to change at page 22, line 50
<Reason> <Reason>
Given the stateful nature of COPS, it is important that when a Given the stateful nature of COPS, it is important that when a
request state is finally removed from the PEP, a DRQ message for request state is finally removed from the PEP, a DRQ message for
this request state is sent to the PDP so the corresponding state may this request state is sent to the PDP so the corresponding state may
likewise be removed on the PDP. Request states not explicitly likewise be removed on the PDP. Request states not explicitly
deleted by the PEP will be maintained by the PDP until either the deleted by the PEP will be maintained by the PDP until either the
client session is closed or the connection is terminated. client session is closed or the connection is terminated.
Malformed Decision messages should trigger a DRQ specifying the Malformed Decision messages should trigger a DRQ specifying the
appropriate error code (Bad Message Format) and local state should appropriate erroneous reason code (Bad Message Format) and any
either be removed or re-requested. associated state on the PEP should either be removed or re-
requested.
3.5 Synchronize State Request (SSQ) PDP -> PEP 3.5 Synchronize State Request (SSQ) PDP -> PEP
The format of the Synchronize State Query message is as follows: The format of the Synchronize State Query message is as follows:
<Synchronize State> ::= <Common Header> <Synchronize State> ::= <Common Header>
[<Client Handle>] [<Client Handle>]
This message indicates that the remote PDP wishes the client (which This message indicates that the remote PDP wishes the client (which
appears in the common header) to re-send its state. If the optional appears in the common header) to re-send its state. If the optional
skipping to change at page 23, line 48 skipping to change at page 23, line 52
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. If the PEP just rebooted (or otherwise synchronization behavior (See section 2.5).
lost its state), the Last PDP Address object must NOT be included,
implying the PEP has lost all state associated with a previous PDP.
Likewise, if there are no longer any cached decisions being used by
the PEP the Last PDP Address object must not be included.
3.7 Client-Accept (CAT) PDP -> PEP 3.7 Client-Accept (CAT) PDP -> PEP
The Client-Accept message is used to positively respond to the The Client-Accept message is used to positively respond to the
Client-Open message. This message will return to the PEP a timer Client-Open message. This message will return to the PEP a timer
object indicating the maximum time interval between keep-alive object indicating the maximum time interval between keep-alive
messages. Optionally, a timer specifying the minimum allowed messages. Optionally, a timer specifying the minimum allowed
interval between accounting report messages may be included when interval between accounting report messages may be included when
applicable. applicable.
skipping to change at page 25, line 6 skipping to change at page 25, line 5
KA is used for connection verification (not per client session KA is used for connection verification (not per client session
verification). verification).
<Keep-Alive> ::= <Common Header> <Keep-Alive> ::= <Common Header>
Both client and server may assume the TCP connection is insufficient Both client and server may assume the TCP connection is insufficient
for the client-type with the minimum time value (specified in the for the client-type with the minimum time value (specified in the
CAT message) if no communication activity is detected for a period CAT message) if no communication activity is detected for a period
exceeding the timer period. For the PEP, such detection implies the exceeding the timer period. For the PEP, such detection implies the
remote PDP or connection is down and the PEP should now attempt to remote PDP or connection is down and the PEP should now attempt to
use an alternative/backup PDP. Before the PEP terminates a timed-out use an alternative/backup PDP.
connection the PEP should explicitly issue a Client-Close message
for each client-type opened for the connection.
3.9 Client-Close (CC) PEP -> PDP, PDP -> PEP 3.9 Client-Close (CC) PEP -> PDP, PDP -> PEP
The Client-Close message can be issued by either the PDP or PEP to The Client-Close message can be issued by either the PDP or PEP to
notify the other that a particular type of client is no longer being notify the other that a particular type of client is no longer being
supported. supported.
<Client-Close> ::= <Common Header> <Client-Close> ::= <Common Header>
[<Error>] <Error>
[<PDPRedirAddr>] [<PDPRedirAddr>]
An Error object is optionally included to describe the reason for The Error object is included to describe the reason for the close
the close due to an error condition (e.g. requested client-type is (e.g. the requested client-type is not supported by the remote PDP
not supported by the remote PDP or client failure). or client failure).
A PDP may optionally include a PDP Redirect Address object in order A PDP may optionally include a PDP Redirect Address object in order
to inform the PEP of the alternate PDP it should use for the client- to inform the PEP of the alternate PDP it should use for the client-
type specified in the common header. type specified in the common header.
When the PEP detects a lost connection due to a keep-alive timeout
condition it should explicitly send a Client-Close message for each
opened client-type specifying a communications failure error code.
This should be done before terminating the TCP connection and moving
on to a backup/alternative PDP.
3.10 Synchronize State Complete (SSC) PEP -> PDP 3.10 Synchronize State Complete (SSC) PEP -> PDP
The Synchronize State Complete is sent by the PEP to the PDP after The Synchronize State Complete is sent by the PEP to the PDP after
the PDP sends a synchronize state request to the PEP and the PEP has the PDP sends a synchronize state request to the PEP and the PEP has
finished synchronization. It is useful so that the PDP will know finished synchronization. It is useful so that the PDP will know
when all the old client state has been successfully re-requested when all the old client state has been successfully re-requested
and, thus, the PEP and PDP are completely synchronized. and, thus, the PEP and PDP are completely synchronized.
<Synchronize State Complete> ::= <Common Header> <Synchronize State Complete> ::= <Common Header>
skipping to change at page 26, line 16 skipping to change at page 26, line 16
This section describes the typical exchanges between remote PDP This section describes the typical exchanges between remote PDP
servers and PEP clients. servers and PEP clients.
4.1 PEP Initialization 4.1 PEP Initialization
Sometime after a connection is established between the PEP and a Sometime after a connection is established between the PEP and a
remote PDP, the PEP will send one or more Client-Open messages to remote PDP, the PEP will send one or more Client-Open messages to
the remote PDP, one for each client-type supported by the PEP. The the remote PDP, one for each client-type supported by the PEP. The
Client-Open message must contain the address of the last PDP with Client-Open message must contain the address of the last PDP with
which the PEP is still caching decisions. If no decisions are being which the PEP is still caching a complete set of decisions. If no
cached from a previous PDP the LastPDPAddr object must not be decisions are being cached from the previous PDP the LastPDPAddr
included in the Client-Open message. Each Client-Open message should object must not be included in the Client-Open message (see Section
at least contain the common header noting one client-type supported 2.5). Each Client-Open message should at least contain the common
by the PEP. The remote PDP will then respond with separate Client- header noting one client-type supported by the PEP. The remote PDP
Accept messages for each of the client-types requested by the PEP will then respond with separate Client-Accept messages for each of
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.
Otherwise, the PDP will send a Client-Accept specifying the timer Otherwise, the PDP will send a Client-Accept specifying the timer
interval between keep-alive messages and the PEP may begin issuing interval between keep-alive messages and the PEP may begin issuing
requests to the PDP. requests to the PDP.
4.2 Outsourcing Operations 4.2 Outsourcing Operations
skipping to change at page 27, line 39 skipping to change at page 27, line 39
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 negotiated
minimum KA Timer interval. On receiving a Keep-Alive message from minimum KA Timer interval. On receiving a Keep-Alive message from
the PEP, the PDP must then respond to this Keep-Alive message by the PEP, the PDP must then respond to this Keep-Alive message by
echoing a Keep-Alive message back to the PEP. If either side does echoing a Keep-Alive message back to the PEP. If either side does
not receive a Keep-Alive or any other COPS message within the not receive a Keep-Alive or any other COPS message within the
negotiated timer interval from the other, the connection should be minimum KA Timer interval from the other, the connection should be
considered lost. considered lost.
4.5 PEP Shutdown 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 a PEP the specified client-type is no longer supported/active. When the
times out a TCP connection due to the keep-alive timer, it should PEP detects a lost connection due to a keep-alive timeout condition
explicitly send a Client-Close message for each client-type opened it should explicitly send a Client-Close message for each opened
on the connection. Then the PEP may proceed to terminate the client-type specifying a communications failure error code. Then the
connection to the PDP and attempt to reconnect again or try a PEP may proceed to terminate the connection to the PDP and attempt
backup/alternative PDP. 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
connected PEPs for each client-type, perhaps specifying an
alternative PDP to use instead.
5. Security 5. Security
The security of RSVP messages is provided by inter-router MD5 The security of RSVP messages is provided by inter-router MD5
authentication [MD5]. This assumes a chain-of-trust model for inter authentication [MD5]. This assumes a chain-of-trust model for inter
PEP authentication. Security between the client (PEP) and server PEP authentication. Security between the client (PEP) and server
(PDP) is provided by IPSEC [IPSEC]. (PDP) is provided by IPSEC [IPSEC].
To ensure the client (PEP) is communicating with the correct policy To ensure the client (PEP) is communicating with the correct policy
server (PDP) involves two issues: authentication of the policy server (PDP) involves two issues: authentication of the policy
client and server using a shared secret, and consistent proof that client and server using a shared secret, and consistent proof that
the connection remains valid. The shared secret requires manual the connection remains valid. The shared secret requires manual
configuration of keys, which is a maintenance issue. IPSEC AH may be configuration of keys, which is a maintenance issue. IPSEC AH may be
used for the validation of the connection; IPSEC ESP may be used to used for the validation of the connection; IPSEC ESP may be used to
provide both validation and secrecy. provide both validation and secrecy.
6. IANA Considerations 6. IANA Considerations
The Client-type identifies the policy client. Interpretation of all The Client-type identifies the policy client application to which a
encapsulated objects is relative to the client-type. Client-types message refers. Client-type values within the range 0x0000-0x3FFF
that set the most significant bit in the common header's client-type are reserved Specification Required status as defined in [IANA-
field are enterprise specific (these are client-types 0x8000 - CONSIDERATIONS]. These values must be registered with IANA and their
0xFFFF). All new client-type values within the range 0x0000-0x7FFF behavior and applicability must be described in a COPS extension
must be registered with IANA and their behavior and applicability document.
should be described in a COPS extensions document.
Client-type values in the range 0x4000 - 0x7FFF are reserved for
Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types
are not tracked by IANA and are not to be used in standards or
general-release products, as their uniqueness cannot be assured.
Client-type values in the range 0x8000 - 0xFFFF are First Come First
Served as defined in [IANA-CONSIDERATIONS]. These Client-types are
tracked by IANA but do not require published documents describing
their use. IANA merely assures their uniqueness.
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-01.txt,
November 1997. November 1998.
[SRVLOC]Guttman, E. et al., "Service Location Protocol", Internet- [SRVLOC]Guttman, E. et al., "Service Location Protocol", Internet-
Draft, draft-ietf-svrloc-protocol-v2-01.txt, October 1997. Draft, draft-ietf-svrloc-protocol-v2-01.txt, October 1997.
[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.
[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.
[IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers [IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
8. Author Information and Acknowledgments 8. Author Information and Acknowledgments
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs,
Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch
Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable
contributions. contributions.
Jim Boyle Ron Cohen Jim Boyle Ron Cohen
Level 3 Communications Cisco Systems Level 3 Communications Cisco Systems
 End of changes. 

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