draft-ietf-rap-cops-04.txt   draft-ietf-rap-cops-05.txt 
Internet Draft Jim Boyle Internet Draft Jim Boyle
Expiration: May 1999 Level 3 Expiration: June 1999 Level 3
File: draft-ietf-rap-cops-04.txt Ron Cohen File: draft-ietf-rap-cops-05.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: December 18, 1998 Last Updated: January 18, 1999
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. 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 May 1999. Distribution of this draft is document will expire before June 1999. Distribution of this draft 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
2.2.3 In-Interface Object (IN-Int)................................10 2.2.3 In-Interface Object (IN-Int)................................10
2.2.4 Out-Interface Object (OUT-Int)..............................11 2.2.4 Out-Interface Object (OUT-Int)..............................11
2.2.5 Reason Object (Reason)......................................11 2.2.5 Reason Object (Reason)......................................12
2.2.6 Decision Object (Decision)..................................12 2.2.6 Decision Object (Decision)..................................12
2.2.7 LDP Decision Object (LDPDecision)...........................14 2.2.7 LDP Decision Object (LDPDecision)...........................14
2.2.8 Error Object (Error)........................................14 2.2.8 Error Object (Error)........................................14
2.2.9 Client Specific Information Object (ClientSI)...............15 2.2.9 Client Specific Information Object (ClientSI)...............14
2.2.10 Keep-Alive Timer Object (KATimer)..........................15 2.2.10 Keep-Alive Timer Object (KATimer)..........................15
2.2.11 PEP Identification Object (PEPID)..........................15 2.2.11 PEP Identification Object (PEPID)..........................15
2.2.12 Report-Type Object (Report-Type)...........................16 2.2.12 Report-Type Object (Report-Type)...........................15
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).............................16
2.2.15 Accounting Timer Object (AcctTimer)........................17 2.2.15 Accounting Timer Object (AcctTimer)........................17
2.3 Communication.................................................17 2.3 Communication.................................................17
2.4 Client Handle Usage...........................................18 2.4 Client Handle Usage...........................................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...................23 3.5 Synchronize State Request (SSQ) PDP -> PEP...................23
3.6 Client-Open (OPN) PEP -> PDP.................................23 3.6 Client-Open (OPN) PEP -> PDP.................................23
3.7 Client-Accept (CAT) PDP -> PEP...............................24 3.7 Client-Accept (CAT) PDP -> PEP...............................24
3.8 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................24 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................24
3.9 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................25 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................25
3.10 Synchronize State Complete (SSC) PEP -> PDP..................25 3.10 Synchronize State Complete (SSC) PEP -> PDP..................25
4. Common Operation...............................................26 4. Common Operation...............................................26
4.1 PEP Initialization............................................26 4.1 PEP Initialization............................................26
4.2 Outsourcing Operations........................................26 4.2 Outsourcing Operations........................................26
4.3 Configuration Operations......................................27 4.3 Configuration Operations......................................27
4.4 Keep-Alive Operations.........................................27 4.4 Keep-Alive Operations.........................................27
4.5 PEP/PDP Close.................................................27 4.5 PEP/PDP Close.................................................27
5. Security.......................................................28 5. Security.......................................................28
6. IANA Considerations............................................29 6. IANA Considerations............................................29
7. References.....................................................30 7. References.....................................................30
skipping to change at page 7, line 17 skipping to change at page 7, line 17
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| //// | Op Code | Client-type | |Version| Flags| Op Code | Client-type |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Message Length | | Message Length |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Global note: //// implies field is reserved, set to 0. Global note: //// implies field is reserved, set to 0.
The fields in the header are: The fields in the header are:
Version: 4 bits Version: 4 bits
COPS version number. Current version is 1. COPS version number. Current version is 1.
Flags: 4 bits
Defined flag values (all other flags must be set to 0):
0x1 Solicited Message Flag Bit
This flag is set when the message is solicited by
another COPS message. This flag is NOT to be set
(value=0) unless otherwise specified in section 3.
Op Code: 8 bits Op Code: 8 bits
The COPS operations: The COPS operations:
1 = Request (REQ) 1 = Request (REQ)
2 = Decision (DEC) 2 = Decision (DEC)
4 = Report State (RPT) 3 = Report State (RPT)
5 = Delete Request State (DRQ) 4 = Delete Request State (DRQ)
6 = Synchronize State Req (SSQ) 5 = Synchronize State Req (SSQ)
7 = Client-Open (OPN) 6 = Client-Open (OPN)
8 = Client-Accept (CAT) 7 = Client-Accept (CAT)
8 = Client-Close (CC)
9 = Keep-Alive (KA) 9 = Keep-Alive (KA)
10= Client-Close (CC) 10= Synchronize Complete (SSC)
11= Synchronize Complete (SSC)
Client-type: 16 bits Client-type: 16 bits
The Client-type identifies the policy client. Interpretation of The Client-type identifies the policy client. Interpretation of
all encapsulated objects is relative to the client-type. Client- all encapsulated objects is relative to the client-type. Client-
types that set the most significant bit in the client-type field types that set the most significant bit in the client-type field
are enterprise specific (these are client-types 0x8000 - are enterprise specific (these are client-types 0x8000 -
0xFFFF). (See the specific client usage documents for particular 0xFFFF). (See the specific client usage documents for particular
client-type IDs). For KA Messages, the client-type in the header client-type IDs). For KA Messages, the client-type in the header
should always be set to 0 as the KA is used for connection should always be set to 0 as the KA is used for connection
skipping to change at page 8, line 36 skipping to change at page 8, line 43
rounding up the previous stated object length to the next 32-bit rounding up the previous stated object length to the next 32-bit
boundary. boundary.
Typically, C-Num identifies the class of information contained in Typically, C-Num identifies the class of information contained in
the object, and the C-Type identifies the subtype or version of the the object, and the C-Type identifies the subtype or version of the
information contained in the object. information contained in the object.
C-num: 8 bits C-num: 8 bits
1 = Handle 1 = Handle
3 = Context 2 = Context
4 = In Interface 3 = In Interface
5 = Out Interface 4 = Out Interface
6 = Reason code 5 = Reason code
7 = Decision 6 = Decision
8 = LDP Decision 7 = LDP Decision
9 = Error 8 = Error
10 = Client Specific Info 9 = Client Specific Info
11 = Keep-Alive Timer 10 = Keep-Alive Timer
12 = PEP Identification 11 = PEP Identification
13 = Report Type 12 = Report Type
14 = PDP Redirect Address 13 = PDP Redirect Address
15 = Last PDP Address 14 = Last PDP Address
16 = Accounting Timer 15 = Accounting Timer
C-type: 8 bits C-type: 8 bits
Values defined per C-num. Values defined per C-num.
2.2.1 Handle Object (Handle) 2.2.1 Handle Object (Handle)
The Handle Object encapsulates a unique value that identifies an The Handle Object encapsulates a unique value that identifies an
installed state. This identification is used by most COPS installed state. This identification is used by most COPS
operations. A state corresponding to a handle must be explicitly operations. A state corresponding to a handle must be explicitly
deleted when it is no longer applicable. deleted when it is no longer applicable.
skipping to change at page 9, line 48 skipping to change at page 9, line 50
form useful for setting system attributes on a PEP, or it may be in form useful for setting system attributes on a PEP, or it may be in
the form of policy rules that are to be directly verified by the the form of policy rules that are to be directly verified by the
PEP. PEP.
Multiple flags can be set for the same request. This is only Multiple flags can be set for the same request. This is only
allowed, however, if the set of client specific information in the allowed, however, if the set of client specific information in the
combined request is identical to the client specific information combined request is identical to the client specific information
that would be specified if individual requests were made for each that would be specified if individual requests were made for each
specified flag. specified flag.
C-num = 3, C-Type = 1 C-num = 2, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| R-Type | M-Type | | R-Type | M-Type |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
R-Type (Request Type Flag) R-Type (Request Type Flag)
0x01 = Incoming-Message/Admission Control request 0x01 = Incoming-Message/Admission Control request
0x02 = Resource-Allocation request 0x02 = Resource-Allocation request
0x04 = Outgoing-Message request 0x04 = Outgoing-Message request
skipping to change at page 10, line 30 skipping to change at page 10, line 38
(receiving) interface via its ifindex. The ifindex may be used to (receiving) interface via its ifindex. The ifindex may be used to
differentiate between sub-interfaces and unnumbered interfaces (see differentiate between sub-interfaces and unnumbered interfaces (see
RSVP's LIH for an example). When SNMP is supported by the PEP, this RSVP's LIH for an example). When SNMP is supported by the PEP, this
ifindex integer must correspond to the same integer value for the ifindex integer must correspond to the same integer value for the
interface in the SNMP MIB-II interface index table. interface in the SNMP MIB-II interface index table.
Note: The ifindex specified in the In-Interface is typically Note: The ifindex specified in the In-Interface is typically
relative to the flow of the underlying protocol messages. The relative to the flow of the underlying protocol messages. The
ifindex is the interface on which the protocol message was received. ifindex is the interface on which the protocol message was received.
C-Num = 4 C-Num = 3
C-Type = 1, IPv4 Address + Interface C-Type = 1, IPv4 Address + Interface
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| IPv4 Address format | | IPv4 Address format |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ifindex | | ifindex |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv4 address should For this type of the interface object, the IPv4 address should
skipping to change at page 11, line 29 skipping to change at page 11, line 42
differentiate between sub-interfaces and unnumbered interfaces (see differentiate between sub-interfaces and unnumbered interfaces (see
RSVP's LIH for an example). When SNMP is supported by the PEP, this RSVP's LIH for an example). When SNMP is supported by the PEP, this
ifindex integer must correspond to the same integer value for the ifindex integer must correspond to the same integer value for the
interface in the SNMP MIB-II interface index table. interface in the SNMP MIB-II interface index table.
Note: The ifindex specified in the Out-Interface is typically Note: The ifindex specified in the Out-Interface is typically
relative to the flow of the underlying protocol messages. The relative to the flow of the underlying protocol messages. The
ifindex is the one on which a protocol message is about to be ifindex is the one on which a protocol message is about to be
forwarded. forwarded.
C-Num = 5 C-Num = 4
C-Type = 1, IPv4 Address + Interface C-Type = 1, IPv4 Address + Interface
Same C-Type format as the In-Interface object. The IPv4 address Same C-Type format as the In-Interface object. The IPv4 address
should specify the IP address to which the outgoing message is should specify the IP address to which the outgoing message is
going. The ifindex is used to refer to the MIB-II defined local going. The ifindex is used to refer to the MIB-II defined local
outgoing interface on the PEP. outgoing interface on the PEP.
C-Type = 2, IPv6 Address + Interface C-Type = 2, IPv6 Address + Interface
skipping to change at page 11, line 52 skipping to change at page 12, line 14
which the outgoing message is going. The ifindex is used to refer to which the outgoing message is going. The ifindex is used to refer to
the MIB-II defined local outgoing interface on the PEP. the MIB-II defined local outgoing interface on the PEP.
2.2.5 Reason Object (Reason) 2.2.5 Reason Object (Reason)
This object specifies the reason why the request state was deleted. This object specifies the reason why the request state was deleted.
It should appear in the delete request (DRQ) message. The Reason It should appear in the delete request (DRQ) message. The Reason
Sub-code field is reserved for more detailed client-specific reason Sub-code field is reserved for more detailed client-specific reason
codes defined in the corresponding documents. codes defined in the corresponding documents.
C-Num = 6, C-Type = 1 C-Num = 5, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Reason-Code | Reason Sub-code | | Reason-Code | Reason Sub-code |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Reason Code: Reason Code:
1 = Unspecified 1 = Unspecified
2 = Management 2 = Management
3 = Preempted (Another request state takes precedence) 3 = Preempted (Another request state takes precedence)
4 = Tear (Used to communicate a signaled state removal) 4 = Tear (Used to communicate a signaled state removal)
skipping to change at page 12, line 29 skipping to change at page 12, line 41
10= Synchronize Handle Unknown 10= Synchronize Handle Unknown
11= Transient Handle (stateless event) 11= Transient Handle (stateless event)
12= Malformed Decision (could not recover) 12= Malformed Decision (could not recover)
2.2.6 Decision Object (Decision) 2.2.6 Decision Object (Decision)
Decision made by the PDP. Must appear in replies. The specific non- Decision made by the PDP. Must appear in replies. The specific non-
mandatory decision objects required in a decision to a particular mandatory decision objects required in a decision to a particular
request depend on the type of client. request depend on the type of client.
C-Num = 7 C-Num = 6
C-Type = 1, Decision Flags (Mandatory) C-Type = 1, Decision Flags (Mandatory)
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Flags | | Command-Code | Flags |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Commands:
0 = NULL Decision (No configuration data available)
1 = Install (Admit request/Install configuration)
2 = Remove (Remove request/Remove configuration)
Flags: Flags:
0x01 = Admit Signaled (Reject if set) 0x01 = Trigger Error (Trigger error message if set)
0x08 = Trigger Error (Trigger error message if set) Note: Trigger Error is applicable to client-types that
Note: For the above flags, a flag bit set to 1 are capable of sending error notifications for signaled
implies a negative decision for that flag. Not messages.
setting a flag implies a positive decision.
0x10 = NULL Configuration (No configuration data if set)
0x20 = Install Configuration (Install named data if set)
0x40 = Remove Configuration (Remove named data if set)
Note: If NULL Configuration ignore Install/Remove.
Note: Only one of Install OR Remove may be set in
one decision flags object.
0x200= Solicited Decision
(Initial decision after a new/updated request if set)
Flag values not applicable to a given context's R-Type MUST be
ignored by the PEP. See table below:
Decision Flag : Valid Context R-Type Flag values not applicable to a given context's R-Type or
------------------------------------------------------- client-type MUST be ignored by the PEP.
Admit Signaled : Incoming-Message/Admission Control
Admit Signaled : Resource-Allocation
Admit Signaled : Outgoing-Message
Trigger Error : Any of the above R-Types
NULL Configuration : Configuration
Install Config. : Configuration
Remove Config. : Configuration
Solicited Decision : Any R-Type
C-Type = 2, Resource Allocation Data C-Type = 2, Stateless Data
This type of decision object carries additional stateless This type of decision object carries additional stateless
information that can be applied by the PEP locally. It is a information that can be applied by the PEP locally. It is a
variable length object and its internal format should be variable length object and its internal format should be
specified in the relevant COPS extension document for the given specified in the relevant COPS extension document for the given
client-type. This object is optional in Decision messages and is client-type. This object is optional in Decision messages and is
interpreted relative to a given context. interpreted relative to a given context.
It is expected that even outsourcing PEPs will be able to make It is expected that even outsourcing PEPs will be able to make
some simple stateless policy decisions locally in their LDP. As some simple stateless policy decisions locally in their LDP. As
this set is well known and implemented ubiquitously, PDPs are this set is well known and implemented ubiquitously, PDPs are
aware of it as well (either universally, through configuration, aware of it as well (either universally, through configuration,
or using the Client-Open message). The PDP may also include this or using the Client-Open message). The PDP may also include this
information in its decision, and the PEP should apply it to the information in its decision, and the PEP should apply it to the
resource allocation event that generated the request. resource allocation event that generated the request.
As an example, reservations may be admitted by a PDP contingent
on some type of per-session preemption priority. A RSVP PEP
could have a set of stateless policy rules for when to preempt
other reservations in favor of a new one (e.g. higher-priority
pre-empts any of lower priority). The PDP would need to include
appropriate priority information for each reservation in its
decisions that the PEP can use to apply its rules.
C-Type = 3, Replacement Data C-Type = 3, Replacement Data
This type of decision object carries replacement data that is to This type of decision object carries replacement data that is to
replace existing data in a signaled message. It is a variable replace existing data in a signaled message. It is a variable
length object and its internal format should be specified in the length object and its internal format should be specified in the
relevant COPS extension document for the given client-type. It relevant COPS extension document for the given client-type. It
is optional in Decision messages and is interpreted relative to is optional in Decision messages and is interpreted relative to
a given context. a given context.
C-Type = 4, Client Specific Decision Data C-Type = 4, Client Specific Decision Data
skipping to change at page 14, line 23 skipping to change at page 14, line 11
the given client-type. It is optional in Decision messages and the given client-type. It is optional in Decision messages and
is interpreted relative to both a given context and decision is interpreted relative to both a given context and decision
flags. flags.
2.2.7 LDP Decision Object (LDPDecision) 2.2.7 LDP Decision Object (LDPDecision)
Decision made by the PEP's local decision point (LDP). May appear in Decision made by the PEP's local decision point (LDP). May appear in
requests. These objects correspond to and are formatted the same as requests. These objects correspond to and are formatted the same as
the client specific decision objects defined above. the client specific decision objects defined above.
C-Num = 8 C-Num = 7
C-Type = (same C-Type as for Decision objects) C-Type = (same C-Type as for Decision objects)
2.2.8 Error Object (Error) 2.2.8 Error Object (Error)
This object is used to identify a particular COPS protocol error. This object is used to identify a particular COPS protocol error.
The error sub-code field contains additional detailed client The error sub-code field contains additional detailed client
specific error codes. The appropriate Error Sub-codes for a specific error codes. The appropriate Error Sub-codes for a
particular client-type should be specified in the relevant COPS particular client-type should be specified in the relevant COPS
extensions document. extensions document.
C-Num 9, C-Type = 1 C-Num = 8, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code | | Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Error-Code: Error-Code:
1 = Bad handle 1 = Bad handle
2 = Invalid handle reference 2 = Invalid handle reference
skipping to change at page 15, line 11 skipping to change at page 14, line 50
9 = Communication Failure 9 = Communication Failure
10= Unspecified 10= Unspecified
11= Shutting down 11= Shutting down
2.2.9 Client Specific Information Object (ClientSI) 2.2.9 Client Specific Information Object (ClientSI)
The various types of this object are required for requests, and used The various types of this object are required for requests, and used
in reports and opens when required. It contains client-type specific in reports and opens when required. It contains client-type specific
information. information.
C-Num = 10, C-Num = 9,
C-Type = 1, Signaled ClientSI. C-Type = 1, Signaled ClientSI.
Variable-length field. All objects/attributes specific to a client's Variable-length field. All objects/attributes specific to a client's
signaling protocol or internal state must be encapsulated within one signaling protocol or internal state must be encapsulated within one
or more signaled Client Specific Information Objects. The format of or more signaled Client Specific Information Objects. The format of
the data encapsulated in the ClientSI object is determined by the the data encapsulated in the ClientSI object is determined by the
client-type. client-type.
C-Type = 2, Named ClientSI. C-Type = 2, Named ClientSI.
Variable-length field. Contains named configuration information Variable-length field. Contains named configuration information
useful for relaying specific information about the PEP, a request, useful for relaying specific information about the PEP, a request,
or configured state to the PDP server. or configured state to the PDP server.
2.2.10 Keep-Alive Timer Object (KATimer) 2.2.10 Keep-Alive Timer Object (KATimer)
Times are encoded as 2 octet integer values and are in units of Times are encoded as 2 octet integer values and are in units of
seconds. The timer value is treated as a delta. seconds. The timer value is treated as a delta.
C-Num = 11, C-Num = 10,
C-Type = 1, Keep-alive timer value C-Type = 1, Keep-alive timer value
Timer object used to specify the maximum time interval over which a Timer object used to specify the maximum time interval over which a
COPS message must be sent or received. The value of zero implies COPS message must be sent or received. The value of zero implies
infinity. infinity.
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| ////////////// | KA Timer Value | | ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
2.2.11 PEP Identification Object (PEPID) 2.2.11 PEP Identification Object (PEPID)
The PEP Identification Object is used to identify the PEP client to The PEP Identification Object is used to identify the PEP client to
the remote PDP. It is required for Client-Open messages. the remote PDP. It is required for Client-Open messages.
C-Num = 12, C-Type = 1 C-Num = 11, C-Type = 1
Variable-length field. It is a NULL terminated ASCII string that is Variable-length field. It is a NULL terminated ASCII string that is
also zero padded to a 32-bit word boundary (so the object length is also zero padded to a 32-bit word boundary (so the object length is
a multiple of 4 octets). The PEPID must contain an ASCII string that a multiple of 4 octets). The PEPID must contain an ASCII string that
uniquely identifies the PEP within the policy domain in a manner uniquely identifies the PEP within the policy domain in a manner
that is persistent across PEP reboots. For example, it may be the that is persistent across PEP reboots. For example, it may be the
PEP's statically assigned IP address or DNS name. This identifier PEP's statically assigned IP address or DNS name. This identifier
may safely be used by a PDP as a handle for identifying the PEP in may safely be used by a PDP as a handle for identifying the PEP in
its policy rules. its policy rules.
2.2.12 Report-Type Object (Report-Type) 2.2.12 Report-Type Object (Report-Type)
The Type of Report on the request state associated with a handle: The Type of Report on the request state associated with a handle:
C-Num = 13, C-Type = 1 C-Num = 12, C-Type = 1
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| Report-Type | ///////////// | | Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
Report-Type: Report-Type:
1 = Commit : PEP's local resources now allocated 1 = Commit : PEP's local resources now allocated
2 = Accounting: Accounting update for an installed state 2 = No Commit : PEP's resource allocation failure
3 = No Commit : PEP's resource allocation failure 3 = Accounting: Accounting update for an installed state
4 = Installed : Named configuration installed 4 = Installed : Admitted request/Installed configuration
5 = Removed : Named configuration removed 5 = Removed : Removed request/Removed configuration
6 = NotInstall: Named configuration was not installed 6 = NotInstall: Request/Configuration was not installed
7 = NotRemoved: Named configuration was not removed 7 = NotRemoved: Request/Configuration was not removed
2.2.13 PDP Redirect Address (PDPRedirAddr) 2.2.13 PDP Redirect Address (PDPRedirAddr)
A PDP when closing a PEP session for a particular client-type may A PDP when closing a PEP session for a particular client-type may
optionally use this object to redirect the PEP to another PDP optionally use this object to redirect the PEP to another PDP
server: server:
C-Num = 14, C-Num = 13,
C-Type = 1, IPv4 Address (4 octets) C-Type = 1, IPv4 Address (4 octets)
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
| IPv4 Address format | | IPv4 Address format |
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
C-Type = 2, IPv6 Address (16 octets) C-Type = 2, IPv6 Address (16 octets)
0 1 2 3 0 1 2 3
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
skipping to change at page 17, line 13 skipping to change at page 17, line 5
+--------------+--------------+--------------+--------------+ +--------------+--------------+--------------+--------------+
2.2.14 Last PDP Address (LastPDPAddr) 2.2.14 Last PDP Address (LastPDPAddr)
When a PEP sends a Client-Open message for a particular client-type When a PEP sends a Client-Open message for a particular client-type
the PEP should specify the last PDP it has successfully opened the PEP should specify the last PDP it has successfully opened
(meaning it received a Client-Accept) since the PEP last rebooted. (meaning it received a Client-Accept) since the PEP last rebooted.
If no PDP was used since the last reboot, the PEP will simply not If no PDP was used since the last reboot, the PEP will simply not
include this object in the Client-Open message. include this object in the Client-Open message.
C-Num = 15, C-Num = 14,
C-Type = 1, IPv4 Address (Same format as PDPRedirAddr) C-Type = 1, IPv4 Address (Same format as PDPRedirAddr)
C-Type = 2, IPv6 Address (Same format as PDPRedirAddr) C-Type = 2, IPv6 Address (Same format as PDPRedirAddr)
2.2.15 Accounting Timer Object (AcctTimer) 2.2.15 Accounting Timer Object (AcctTimer)
Times are encoded as 2 octet integer values and are in units of Times are encoded as 2 octet integer values and are in units of
seconds. The timer value is treated as a delta. seconds. The timer value is treated as a delta.
C-Num = 16, C-Num = 15,
C-Type = 1, Accounting timer value C-Type = 1, Accounting timer value
Optional timer value used to determine the minimum interval between Optional timer value used to determine the minimum interval between
periodic accounting type reports. It is used by the PDP to describe periodic accounting type reports. It is used by the PDP to describe
to the PEP an acceptable interval between accounting updates via to the PEP an acceptable interval between accounting updates via
Report messages where applicable. The value of zero implies there Report messages where applicable. The value of zero implies there
are no timing constraints on accounting updates. are no timing constraints on accounting updates.
0 1 2 3 0 1 2 3
skipping to change at page 21, line 18 skipping to change at page 21, line 18
Finally, LDPDecision object holds information regarding the local Finally, LDPDecision object holds information regarding the local
decision made by the LDP. decision made by the LDP.
3.2 Decision (DEC) PDP -> PEP 3.2 Decision (DEC) PDP -> PEP
The PDP responds to the REQ with a DEC message that includes the The PDP responds to the REQ with a DEC message that includes the
associated client handle and one or more decision objects grouped associated client handle and one or more decision objects grouped
relative to a Context object and Decision Flags object type pair. If relative to a Context object and Decision Flags object type pair. If
there was a protocol error an error object is returned instead. there was a protocol error an error object is returned instead.
It is assumed that the first decision for a new/updated request will It is required that the first decision message for a new/updated
set the solicited decision flag in all included Decision Flag object request will have the solicited message flag set (value = 1) in the
types. This avoids the issue of keeping track of which updated COPS header. This avoids the issue of keeping track of which updated
request (that is, a request reissued for the same handle) a request (that is, a request reissued for the same handle) a
particular decision corresponds. It is important that, for a given particular decision corresponds. It is important that, for a given
handle, there be at most one outstanding solicited decision per handle, there be at most one outstanding solicited decision per
request. This essentially means that the PEP should not issue more request. This essentially means that the PEP should not issue more
than one REQ (for a given handle) before it receives a corresponding than one REQ (for a given handle) before it receives a corresponding
DEC with the solicited decision flag set. DEC with the solicited message flag set.
To avoid deadlock, the client can always timeout after issuing a To avoid deadlock, the client can always timeout after issuing a
request. It must then delete the timed-out handle, and possibly try request. It must then delete the timed-out handle, and possibly try
again using a different (new) handle. again using a different (new) handle.
The format of the Decision message is as follows: The format of the Decision message is as follows:
<Decision Message> ::= <Common Header> <Decision Message> ::= <Common Header>
<Client Handle> <Client Handle>
<Decision(s)> | <Error> <Decision(s)> | <Error>
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision> <Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
<Decision> ::= <Context> <Decision> ::= <Context>
<Decision: Flags> <Decision: Flags>
[<Decision: Resource Alloc Data>] [<Decision: Stateless Data>]
[<Decision: Replacement Data>] [<Decision: Replacement Data>]
[<Decision: ClientSI Data>] [<Decision: ClientSI Data>]
[<Decision: Named Data>] [<Decision: Named Data>]
The Decision message may include either an Error object or one or The Decision message may include either an Error object or one or
more context plus associated decision objects. COPS protocol more context plus associated decision objects. COPS protocol
problems are reported in the Error object (e.g. an error with the problems are reported in the Error object (e.g. an error with the
format of the original request, including malformed request format of the original request, including malformed request
messages). The applicable Decision object(s) depend on the context messages). The applicable Decision object(s) depend on the context
and the type of client. The only ordering requirement for decision and the type of client. The only ordering requirement for decision
skipping to change at page 24, line 36 skipping to change at page 24, line 36
The optional accounting timer allows the PDP to indicate to the PEP The optional accounting timer allows the PDP to indicate to the PEP
that periodic accounting reports should not exceed the specified that periodic accounting reports should not exceed the specified
timer interval. This allows the PDP to control the rate at which timer interval. This allows the PDP to control the rate at which
accounting reports are sent by the PEP (when applicable). In accounting reports are sent by the PEP (when applicable). In
general, accounting type Report messages are sent to the PDP when general, accounting type Report messages are sent to the PDP when
determined appropriate by the PEP. The accounting timer merely is determined appropriate by the PEP. The accounting timer merely is
used by the PDP to keep the rate of such updates in check (i.e. used by the PDP to keep the rate of such updates in check (i.e.
Preventing the PEP from blasting the PDP with accounting reports). Preventing the PEP from blasting the PDP with accounting reports).
3.8 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP
The Client-Close message can be issued by either the PDP or PEP to
notify the other that a particular type of client is no longer being
supported.
<Client-Close> ::= <Common Header>
<Error>
[<PDPRedirAddr>]
The Error object is included to describe the reason for the close
(e.g. the requested client-type is not supported by the remote PDP
or client failure).
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-
type specified in the common header.
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP
The keep-alive message must be transmitted by the PEP within the The keep-alive message must be transmitted by the PEP within the
period defined by the minimum of all KA Timer values specified in period defined by the minimum of all KA Timer values specified in
all received CAT messages for the connection. A KA message must be all received CAT messages for the connection. A KA message must be
generated randomly between 1/4 and 3/4 of this minimum TA timer generated randomly between 1/4 and 3/4 of this minimum TA timer
interval. When the PDP receives a keep-alive message from a PEP, it interval. When the PDP receives a keep-alive message from a PEP, it
must echo a keep-alive back to the PEP. This message provides must echo a keep-alive back to the PEP. This message provides
validation for each side that the connection is still functioning validation for each side that the connection is still functioning
even when there is no other messaging. even when there is no other messaging.
skipping to change at page 25, line 7 skipping to change at page 25, line 29
<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. use an alternative/backup PDP.
3.9 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>
[<PDPRedirAddr>]
The Error object is included to describe the reason for the close
(e.g. the requested client-type is not supported by the remote PDP
or client failure).
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-
type specified in the common header.
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 27, line 18 skipping to change at page 27, line 18
PEP will make a configuration request to the PDP for a particular PEP will make a configuration request to the PDP for a particular
interface, module, or functionality that may be specified in the interface, module, or functionality that may be specified in the
named client specific information object. The PDP will then send named client specific information object. The PDP will then send
potentially several decisions containing named units of potentially several decisions containing named units of
configuration data to the PEP. The PEP is expected to install and configuration data to the PEP. The PEP is expected to install and
use the configuration locally. A particular named configuration can use the configuration locally. A particular named configuration can
be updated by simply sending additional decision messages for the be updated by simply sending additional decision messages for the
same named configuration. When the PDP no longer wishes the PEP to same named configuration. When the PDP no longer wishes the PEP to
use a piece of configuration information, it will send a decision use a piece of configuration information, it will send a decision
message specifying the named configuration and a decision flags message specifying the named configuration and a decision flags
object with the remove configuration flag set. The PEP should then object with the remove configuration command. The PEP should then
proceed to remove the corresponding configuration and send a report proceed to remove the corresponding configuration and send a report
message to the PDP that specifies it has been deleted. message to the PDP that specifies it has been deleted.
In all cases, the PEP may notify the remote PDP of the local status In all cases, the PEP may notify the remote PDP of the local status
of an installed state using the report message where appropriate. of an installed state using the report message where appropriate.
The report message is to be used to signify when billing should The report message is to be used to signify when billing should
begin, what actions were taken, or to produce periodic updates for begin, what actions were taken, or to produce periodic updates for
monitoring and accounting purposes depending on the client. This monitoring and accounting purposes depending on the client. This
message can carry client specific information when needed. message can carry client specific information when needed.
 End of changes. 

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