The format for this data is encapsulated in the COPS Named ClientSI
object as follows:
<Named ClientSI: Report> ::= <[<GPERR>] *(<report>)>
<report> ::= <ErrorPRID> <CPERR> *(<PRID><EPD>)
5.3.2. Accounting Report-Type Data Format
Additionally, reports can be used to carry accounting information
when specifying the 'Accounting' Report-Type. This accounting report
message will typically carry statistical or event information related
to the installed configuration for use at the PDP. This information
is encoded as one or more <PRID><EPD> bindings that generally
describe the accounting information being reported from the PEP to
the PDP.
The format for this data is encapsulated in the COPS Named ClientSI
object as follows:
<Named ClientSI: Report> ::= <*(<PRID><EPD>)>
NOTE: RFC2748 defines an optional Accounting-Timer (AcctTimer)
object for use in the COPS Client-Accept message. Periodic
accounting reports for COPS-PR clients are also obligated to be paced
by this timer. Periodic accounting reports SHOULD NOT be generated
by the PEP more frequently than the period specified by the COPS
AcctTimer. Thus, the period between new accounting reports SHOULD be
greater-than or equal-to the period specified (if specified) in the
AcctTimer. If no AcctTimer object is specified by the PDP, then
there are no constraints imposed on the PEP's accounting interval.
6. Common Operation
This section describes, in general, typical exchanges between a PDP
and Policy Provisioning COPS client.
First, a TCP connection is established between the client and server
and the PEP sends a Client-Open message specifying a COPS- PR
client-type (use of the ClientSI object within the Client-Open
message is currently undefined for COPS-PR clients). If the PDP
supports the specified provisioning client-type, the PDP responds
with a Client-Accept (CAT) message. If the client-type is not
supported, a Client-Close (CC) message is returned by the PDP to the
PEP, possibly identifying an alternate server that is known to
support the policy for the provisioning client-type specified.
After receiving the CAT message, the PEP can send requests to the
server. The REQ from a policy provisioning client contains a COPS
'Configuration Request' context object and, optionally, any relevant
named client specific information from the PEP. The information
provided by the PEP should include available client resources (e.g.,
supported classes/attributes) and default policy configuration
information as well as incarnation data on existing policy. The
configuration request message from a provisioning client serves two
purposes. First, it is a request to the PDP for any provisioning
configuration data which the PDP may currently have that is suitable
for the PEP, such as access control filters, etc., given the
information the PEP specified in its REQ. Also, the configuration
request effectively opens a channel that will allow the PDP to
asynchronously send policy data to the PEP, as the PDP decides is
necessary, as long as the PEP keeps its request state open (i.e., as
long as the PEP does not send a DRQ with the request state's Client
Handle). This asynchronous data may be new policy data or an update
to policy data sent previously. Any relevant changes to the PEP's
internal state can be communicated to the PDP by the PEP sending an
updated REQ message. The PEP is free to send such updated REQ
messages at any time after a CAT message to communicate changes in
its local state.
After the PEP sends a REQ, if the PDP has Policy Provisioning policy
configuration information for the client, that information is
returned to the client in a DEC message containing the Policy
Provisioning client policy data within the COPS Named Decision Data
object and specifying an "Install" Command-Code in the Decision Flags
object. If no filters are defined, the DEC message will simply
specify that there are no filters using the "NULL Decision" Command-
Code in the Decision Flags object. As the PEP MUST specify a Client
Handle in the request message, the PDP MUST process the Client Handle
and copy it in the corresponding decision message. A DEC message
MUST be issued by the PDP with the Solicited Message Flag set in the
COPS message header, regardless of whether or not the PDP has any
configuration information for the PEP at the time of the request.
This is to prevent the PEP from timing out the REQ and deleting the
Client Handle.
The PDP can then add new policy data or update/delete existing
configurations by sending subsequent unsolicited DEC message(s) to
the PEP, with the same Client Handle. Previous configurations
installed on the PEP are updated by the PDP by simply re-installing
the same instance of configuration information again (effectively
overwriting the old data). The PEP is responsible for removing the
Client handle when it is no longer needed, for example when an
interface goes down, and informing the PDP that the Client Handle is
to be deleted via the COPS DRQ message.
For Policy Provisioning purposes, access state, and access requests
to the policy server can be initiated by other sources besides the
PEP. Examples of other sources include attached users requesting
network services via a web interface into a central management
application, or H.323 servers requesting resources on behalf of a
user for a video conferencing application. When such a request is
accepted, the edge device affected by the decision (the point where
the flow is to enter the network) needs to be informed of the
decision. Since the PEP in the edge device did not initiate the
request, the specifics of the request, e.g., flowspec, packet filter,
and PHB to apply, needs to be communicated to the PEP by the PDP.
This information is sent to the PEP using the Decision message
containing Policy Provisioning Named Decision Data objects in the
COPS Decision object as specified. Any updates to the state
information, for example in the case of a policy change or call tear
down, is communicated to the PEP by subsequent unsolicited DEC
messages containing the same Client Handle and the updated Policy
Provisioning request state. Updates can specify that policy data is
to be installed, deleted, or updated (re-installed).
PDPs may also command the PEP to open a new Request State or delete
an exiting one by issuing a decision with the Decision Flags object's
Request-State flag set. If the command-code is "install", then the
PDP is commanding the PEP to create a new Request State, and
therefore issue a new REQ message specifying a new Client Handle or
otherwise issue a "Failure" RPT specifying the appropriate error
condition. Each request state represents an independent and
logically non-overlapping namespace, identified by the Client Handle,
on which transactions (a.k.a., configuration installations,
deletions, updates) may be performed. Other existing Request States
will be unaffected by the new request state as they are independent
(thus, no instances of configuration data within one Request State
can be affected by DECs for another Request State as identified by
the Client Handle). If the command-code is "Remove", then the PDP is
commanding the PEP to delete the existing Request-State specified by
the DEC message's Client Handle, thereby causing the PEP to issue a
DRQ message for this Handle.
The PEP MUST acknowledge a DEC message and specify what action was
taken by sending a RPT message with a "Success" or "Failure" Report-
Type object with the Solicited Message Flag set in the COPS message
header. This serves as an indication to the PDP that the requestor
(e.g., H.323 server) can be notified whether the request has been
accepted by the network or not. If the PEP needs to reject the DEC
operation for any reason, a RPT message is sent with a Report-Type
with the value "Failure" and optionally a Client Specific Information
object specifying the policy data that was rejected. Under such
solicited report failure conditions, the PEP MUST always rollback to
its previously installed (good) state as if the DEC never occurred.
The PDP is then free to modify its decision and try again.
The PEP can report to the PDP the current status of any installed
request state when appropriate. This information is sent in a
Report-State (RPT) message with the "Accounting" flag set. The
request state that is being reported is identified via the associated
Client Handle in the report message.
Finally, Client-Close (CC) messages are used to cancel the
corresponding Client-Open message. The CC message informs the other
side that the client-type specified is no longer supported.
7. Fault Tolerance
When communication is lost between PEP and PDP, the PEP attempts to
re-establish the TCP connection with the PDP it was last connected
to. If that server cannot be reached, then the PEP attempts to
connect to a secondary PDP, assumed to be manually configured (or
otherwise known) at the PEP.
When a connection is finally re-established with a PDP, the PEP sends
a OPN message with a <LastPDPAddr> object providing the address of
the most recent PDP for which it is still caching decisions. If no
decisions are being cached on the PEP (due to reboot or TTL timeout
of state) the PEP MUST NOT include the last PDP address information.
Based on this object, the PDP may request the PEP to re-synch its
current state information (by issuing a COPS SSQ message). If, after
re-connecting, the PDP does not request synchronization, the client
can assume the server recognizes it and the current state at the PEP
is correct, so a REQ message need not be sent. Still, any state
changes which occurred at the PEP that the PEP could not communicate
to the PDP due to communication having been lost, MUST be reported to
the PDP via the PEP sending an updated REQ message. Whenever re-
synchronization is requested, the PEP MUST reissue any REQ messages
for all known Request-States and the PDP MUST issue DEC messages to
delete either individual PRIDs or prefixes as appropriate to ensure a
consistent known state at the PEP.
While the PEP is disconnected from the PDP, the active request-state
at the PEP is to be used for policy decisions. If the PEP cannot
re-connect in some pre-specified period of time, all installed
Request-States are to be deleted and their associated Handles
removed. The same holds true for the PDP; upon detecting a failed
TCP connection, the time-out timer is started for all Request-States
associated with the PEP and these states are removed after the
administratively specified period without a connection.
8. Security Considerations
The COPS protocol [COPS], from which this document derives, describes
the mandatory security mechanisms that MUST be supported by all COPS
implementations. These mandatory security mechanisms are used by the
COPS protocol to transfer opaque information from PEP to PDP and vice
versa in an authenticated and secure manner. COPS for Policy
Provisioning simply defines a structure for this opaque information
already carried by the COPS protocol. As such, the security
mechanisms described for the COPS protocol will also be deployed in a
COPS-PR environment, thereby ensuring the integrity of the COPS-PR
information being communicated. Furthermore, in order to fully
describe a practical set of structured data for use with COPS-PR, a
PIB (Policy Information Base) will likely be written in a separate
document. The authors of such a PIB document need to be aware of the
security concerns associated with the specific data they have
defined. These concerns MUST be fully specified in the security
considerations section of the PIB document along with the required
security mechanisms for transporting this newly defined data.
9. IANA Considerations
COPS for Policy Provisioning follows the same IANA considerations for
COPS objects as the base COPS protocol [COPS]. COPS-PR has defined
one additional Decision Flag value of 0x02, extending the COPS base
protocol only by this one value. No new COPS Client- Types are
defined by this document.
COPS-PR also introduces a new object number space with each object
being identified by its S-Num and S-Type value pair. These objects
are encapsulated within the existing COPS Named ClientSI or Named
Decision Data objects [COPS] and, therefore, do not conflict with any
assigned numbers in the COPS base protocol. Additional S-Num and S-
Type pairs can only be added to COPS-PR using the IETF Consensus rule
as defined in [IANA]. These two numbers are always to be treated as
a pair, with one or more S-Types defined per each S-Num. This
document defines the S-Num values 1-6 and the S-Type 1 for each of
these six values (note that the S-Type value of 2 is reserved for
transport of XML encoded data). A listing of all the S-Num and S-
Type pairs defined by this document can be found in sections 4.1-4.6.
Likewise, additional Global Provisioning error codes and Class-
Specific Provisioning error codes defined for COPS-PR can only be
added with IETF Consensus. This document defines the Global
Provisioning error code values 1-11 in section 4.4 for the Global
Provisioning Error Object (GPERR). This document also defines the
Class-Specific error code values 1-13 in section 4.5 for the Class
Provisioning Error Object (CPERR).
10. Acknowledgements
This document has been developed with active involvement from a
number of sources. The authors would specifically like to
acknowledge the valuable input given by Michael Fine, Scott Hahn, and
Carol Bell.
11. References
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC2748, January 2000.
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework
for Policy Based Admission Control", RFC2753, January
2000.
[COPRSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and
A. Sastry, "COPS usage for RSVP", RFC2749, January 2000.
[ASN1] Information processing systems - Open Systems
Interconnection, "Specification of Abstract Syntax Notation
One (ASN.1)", International Organization for
Standardization, International Standard 8824, December
1987.
[BER] Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1), International
Organization for Standardization. International Standard
8825, (December, 1987).
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
W. Weiss, "An Architecture for Differentiated Service," RFC
2475, December 1998.
[SPPI] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
Sahita, R., Smith, A. and F. Reichmeyer, "Structure of
Policy Provisioning Information SPPI", Work in Progress.
[V2SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2(SMIv2)", STD 58, RFC2578, April
1999.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
[IANA] Alvestrand, H. and T. Narten, "Guidelines for writing an
IANA Considerations Section in RFCs", BCP 26, RFC2434,
October 1998.
[URN] Moats, R., "Uniform Resource Names (URN) Syntax", RFC2141,
May 1997.
[XML] World Wide Web Consortium (W3C), "Extensible Markup
Language (XML)," W3C Recommendation, February, 1998,
http://www.w3.org/TR/1998/REC-xml-19980210.
12. Authors' Addresses
Kwok Ho Chan
Nortel Networks, Inc.
600 Technology Park Drive
Billerica, MA 01821
Phone: (978) 288-8175
EMail: khchan@nortelnetworks.com
David Durham
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: (503) 264-6232
Email: david.durham@intel.com
Silvano Gai
Cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134-1706
Phone: (408) 527-2690
EMail: sgai@cisco.com
Shai Herzog
IPHighway Inc.
69 Milk Street, Suite 304
Westborough, MA 01581
Phone: (914) 654-4810
EMail: Herzog@iphighway.com
Keith McCloghrie
Phone: (408) 526-5260
EMail: kzm@cisco.com
Francis Reichmeyer
PFN, Inc.
University Park at MIT
26 Landsdowne Street
Cambridge, MA 02139
Phone: (617) 494 9980
EMail: franr@pfn.com
John Seligson
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95054
Phone: (408) 495-2992
Email: jseligso@nortelnetworks.com
Raj Yavatkar
Phone: (503) 264-9077
EMail: raj.yavatkar@intel.com
Andrew Smith
Allegro Networks
6399 San Ignacio Ave.
San Jose, CA 95119, USA
EMail: andrew@allegronetworks.com
13. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.