<pre>Network Working Group                                         D. Rawlins
Request for Comments: 3483                                      WorldCom
Category: Informational                                      A. Kulkarni
                                                                   Intel
                                                            M. Bokaemper
                                                        Juniper Networks
                                                                 K. Chan
                                                         Nortel Networks
                                                              March 2003


  <span class="h1">Framework for Policy Usage Feedback for Common Open Policy Service</span>
                  <span class="h1">with Policy Provisioning (COPS-PR)</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   Common Open Policy Services (COPS) Protocol (<a href="./rfc2748">RFC 2748</a>), defines the
   capability of reporting information to the Policy Decision Point
   (PDP).  The types of report information are success, failure and
   accounting of an installed state.  This document focuses on the COPS
   Report Type of Accounting and the necessary framework for the
   monitoring and reporting of usage feedback for an installed state.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words to use in the RFCs&quot;">RFC2119</a>].













<span class="grey">Rawlins, et al.              Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3483">RFC 3483</a>                COPS Feedback Framework               March 2003</span>


Table of Contents

   Glossary........................................................... <a href="#page-2">2</a>
   <a href="#section-1">1</a>  Introduction.................................................... <a href="#page-2">2</a>
   <a href="#section-2">2</a>  Overview........................................................ <a href="#page-3">3</a>
   <a href="#section-3">3</a>  Requirements for Normal Operations.............................. <a href="#page-3">3</a>
   <a href="#section-4">4</a>  Periodic Nature of Policy Usage Feedback........................ <a href="#page-4">4</a>
      <a href="#section-4.1">4.1</a> Reporting Intervals......................................... <a href="#page-4">4</a>
   5  Suspension, Resumption and Halting of Usage Monitoring and
      Reporting....................................................... <a href="#page-5">5</a>
   <a href="#section-6">6</a>  Solicited Feedback.............................................. <a href="#page-5">5</a>
   <a href="#section-7">7</a>  Usage reports on shared objects................................. <a href="#page-5">5</a>
   <a href="#section-8">8</a>  Context......................................................... <a href="#page-6">6</a>
   <a href="#section-9">9</a>  Delete Request States........................................... <a href="#page-7">7</a>
   <a href="#section-10">10</a> Failover........................................................ <a href="#page-7">7</a>
   <a href="#section-11">11</a> Security Considerations......................................... <a href="#page-7">7</a>
   <a href="#section-12">12</a> References...................................................... <a href="#page-8">8</a>
      <a href="#section-12.1">12.1</a> Normative References....................................... <a href="#page-8">8</a>
      <a href="#section-12.2">12.2</a> Informative References..................................... <a href="#page-8">8</a>
   <a href="#section-13">13</a> Authors' Addresses.............................................. <a href="#page-9">9</a>
   <a href="#section-14">14</a> Full Copyright Statement........................................<a href="#page-10">10</a>

Glossary

   COPS - Common Open Policy Service.  See [<a href="./rfc2748" title="&quot;The COPS (Common Open Policy Service) Protocol&quot;">RFC2748</a>].
   COPS-PR - COPS Usage for Policy Provisioning.  See [<a href="./rfc3084" title="&quot;COPS Usage for Policy Provisioning (COPS- PR)&quot;">RFC3084</a>].
   PDP - Policy Decision Point.  See [<a href="./rfc2753" title="&quot;A Framework for Policy-based Admission Control&quot;">RFC2753</a>].
   PEP - Policy Enforcement Point.  See [<a href="./rfc2753" title="&quot;A Framework for Policy-based Admission Control&quot;">RFC2753</a>].
   PIB - Policy Information Base.  The database of policy information.
   PRC - Provisioning Class.  A type of policy data.
   PRI - Provisioning Instance.  An instance of a PRC.
   QoS - Quality of Service.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a> Introduction</span>

   Policy usage reported by the PEP makes a richer set of information
   available to the PDP for decision-making.  This feedback on policy
   usage can impact future decisions made by the PDP and the resulting
   policy installed by the PDP at the PEP.  For example, a PDP making
   policy for a SIP signaled multimedia session may need to base the
   decision in part on usage information related to previously installed
   QoS policy decisions.  Furthermore, the PDP may coordinate this usage
   information with other external systems to determine the future
   policy such as the case with the PDP coordinating multimedia session
   QoS and clearinghouse authorizations [<a href="#ref-SIP-AAA-QOS" title="&quot;QoS and AAA Usage with SIP Based IP Communications&quot;">SIP-AAA-QOS</a>].






<span class="grey">Rawlins, et al.              Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3483">RFC 3483</a>                COPS Feedback Framework               March 2003</span>


   The scope of this document is to describe the framework for policy
   usage monitored and reported by the PEP and collected at the PDP.
   The charging, rating and billing models, as well as other accounting
   or statistics gathering events, detectable by the PDP are beyond the
   scope of this framework.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a> Overview</span>

   There are three main aspects to define policies for usage feedback:

   -  which objects are monitored
   -  the metrics to be monitored and reported for these objects
   -  when the reports are delivered

   In the framework, a selection criteria policy specifies one or more
   objects that should be monitored (e.g., a dropper or the instances of
   an IP Filter for all its interfaces).

   A usage feedback class is used to specify which metrics are to be
   collected for a set of objects - instances of the specified class
   carry the usage information when it is reported.  The valid
   combinations of monitored object classes and usage feedback classes
   are reported by the PEP as capabilities.

   Finally, selection criteria policy and usage feedback class are bound
   together in a linkage policy, which also contains the information of
   when reports are generated.  Reports are usually sent periodically,
   but more restrictions can be placed on the generation of reports,
   like thresholds or a change in the data.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a> Requirements for Normal Operations</span>

   Per COPS [<a href="./rfc2748" title="&quot;The COPS (Common Open Policy Service) Protocol&quot;">RFC2748</a>], the PDP specifies the minimum feedback interval
   in the Accounting Timer object that is included in the Client Accept
   message during connection establishment.  This specifies the maximum
   frequency with which the PEP issues unsolicited accounting type
   report messages.  The purpose of this interval is to pace the number
   of report messages sent to the PDP.  It is not the goal of the
   interval defined by the ACCT Timer value to provide precision
   synchronization or timing.

   The selection and the associated usage criteria and intervals for
   feedback reporting are defined by the PDP.  Feedback policies, which
   define the necessary selection and linkages to usage feedback
   criteria, are included by the PDP in a Decision message to the PEP.
   The usage feedback is then periodically reported by the PEP, at
   intervals defined in the linkage policies at a rate no more
   frequently than specified in the Accounting Timer object.  Note that



<span class="grey">Rawlins, et al.              Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3483">RFC 3483</a>                COPS Feedback Framework               March 2003</span>


   there are exceptions where reports containing feedback are provided
   prior to the Accounting Timer interval (see <a href="#section-6">section 6</a>).  The PDP may
   also solicit usage feedback which is to be reported back immediately
   by the PEP.  Usage information may be cleared upon reporting.  This
   is specified in the usage policy criteria.

   The PEP monitors and tracks the usage feedback information.  The PDP
   is the collection point for the policy usage feedback information
   reported by the PEP clients within the administrative domain.  The
   PDP may also collect other accounting event information that is
   outside the scope of this document.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a> Periodic Nature of Policy Usage Feedback</span>

   Generally the policy usage feedback is periodic in nature and the
   reporting is unsolicited.  The unsolicited reports are supplied per
   the interval defined by the PDP.  The periodic unsolicited reports
   are dictated by timer intervals and use a deterministic amount of
   network resources.

   The PDP informs the PEP of the minimal feedback interval during
   client connection establishment with the Accounting Timer object.
   The PDP may specify feedback intervals in the specific usage feedback
   policies as well.  The unsolicited monitoring and reporting by the
   PEP may be suspended and resumed at the direction of the PDP.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Reporting Intervals</span>

   The generation of usage feedback by the PEP to the PDP is done under
   different conditions that include feedback on demand, periodic
   feedback or feedback when a defined threshold is reached.

   The periodic feedback for a usage policy can be further defined in
   terms of providing feedback if there is a change or providing
   feedback periodically regardless of a change in value.

   The periodic interval is defined in terms of the Accounting Object,
   ACCT Timer value.  A single interval is equal to the number of
   seconds specified by the ACCT Timer value.  The PDP may define a
   specific number of intervals, which are to pass before the PEP
   provides the usage feedback for a specific policy in a report.  When
   the ACCT Timer value is equal to zero there is no unsolicited usage
   feedback provided by the PEP.  However, the PEP still monitors and
   tracks the usage per the PDP policy and reports it when the PDP
   solicits the feedback.






<span class="grey">Rawlins, et al.              Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3483">RFC 3483</a>                COPS Feedback Framework               March 2003</span>


   Reporting may be based on reaching a defined threshold value in the
   usage PRC.

   The PDP may solicit usage feedback in the middle of an interval by
   sending a COPS decision message.  The exact contents of the message
   are out of the scope of this framework document and need to be
   defined in a document that actually implements usage feedback using
   this framework.

   The PEP, upon receiving a solicit decision from the PDP, shall
   provide the requested usage information and clear the usage
   information if the usage policy requires that the attribute be
   cleared after reporting.  The PEP should continue to maintain the
   same interval schedule as defined by the PDP in the Accounting Timer
   object and established at client connection acceptance.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a> Suspension, Resumption and Halting of Usage Monitoring and Reporting</span>

   The PDP may direct the PEP to suspend usage feedback report messages
   and then at a later time instruct the PEP to resume the reporting of
   feedback.  The PDP may also instruct the PEP to suspend the
   monitoring and tracking of usage which also results in the
   suppression of the feedback reports until the PDP later tells the PEP
   to resume the monitoring (and reporting).  When the PDP suspends
   monitoring or suspends reporting, it also specifies whether the PEP
   is to provide an unsolicited feedback report of the current monitored
   usage of the affected usage policy.  The PDP may suspend and resume
   monitoring and reporting for specific usage policies or for all of
   the usage feedback policies.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a> Solicited Feedback</span>

   There may be instances when it is useful for the PDP to control the
   feedback per an on-demand basis rather than a periodic basis.  The
   PDP may solicit the PEP for usage feedback with a Decision.  The PDP
   may solicit usage feedback at any time during the accounting interval
   defined by the ACCT Timer.  The PEP responds immediately and reports
   the appropriate usage policies and should continue to follow the
   usage feedback interval schedule established during connection
   acceptance.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a> Usage reports on shared objects</span>

   While some objects in a context's namespace directly represent unique
   objects of the PEP's configuration, other COPS objects can be shared
   between multiple actual assignments in the PEP.





<span class="grey">Rawlins, et al.              Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3483">RFC 3483</a>                COPS Feedback Framework               March 2003</span>


   Whenever the PEP creates multiple actual configuration instances from
   the same COPS objects, these assignments can potentially collect
   their own statistics independently.  Since the individual assignments
   do not have a direct representation as COPS objects, additional
   information must be provided to uniquely identify the assignment that
   generates the usage information.  As an example, if the PEP needs to
   create multiple usage objects for an IP address, it may use the port
   number to uniquely identify each object, i.e., the (IP address, port
   number) combination is now the unique identifier of the object.

   The feedback framework allows this information to be distributed
   between a selection criteria PRC and the corresponding usage feedback
   PRC, however both PRCs together always must contain sufficient
   information for the finest granularity of usage collection supported
   by the PEP.

   If all the additional information is not part of the selection
   criteria PRC, all matching assignments are selected to collect usage
   information.  The necessary data to differentiate these assignments
   is part of the usage feedback PRC.

   Implementations based on the feedback framework should always provide
   a selection criteria PRC that contains a complete set of information
   to select a unique assignment, while underspecified selection
   criteria PRCs (together with extended usage feedback PRCs) are
   optional.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a> Context</span>

   COPS-PR [<a href="./rfc3084" title="&quot;COPS Usage for Policy Provisioning (COPS- PR)&quot;">RFC3084</a>] allows multiple, independent, disjoint instances of
   policies to be configured on the PEP.  Each instance is known as a
   context, and only one context can be active at any given moment.  The
   PDP directs the PEP to switch between contexts using a single
   decision message.

   The monitoring and recording of usage policies is subject to context
   switches in a manner similar to that of the enforcement policy.
   Usage policy is monitored, recorded and reported while the associated
   policy information context is active.  When the context is
   deactivated, a report message containing the usage feedback policies
   for that context is provided to the PDP.  The PEP does not perform
   any monitoring, tracking or reporting of policy usage for a given
   context while the context is inactive.








<span class="grey">Rawlins, et al.              Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3483">RFC 3483</a>                COPS Feedback Framework               March 2003</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a> Delete Request States</span>

   The PEP MUST send any outstanding usage feedback data monitored
   during the feedback interval to the PDP via an unsolicited report
   message immediately prior to issuing a Delete Request State.  This is
   also the case when the PDP initiates the Delete Request State.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a> Failover</span>

   In the event the connection is lost between the PEP and PDP, the PEP
   continues to track usage feedback information as long as it continues
   to enforce installed (cached) policy.  When the locally installed
   policy at the PEP expires, the usage feedback policy data also
   expires and is no longer monitored.

   Upon successful reconnection, where the PEP is still caching policy,
   the PDP indicates deterministically to the PEP that the PEP may
   resume usage feedback reporting.  The PEP reports all cached usage
   and resumes periodic reporting, making any needed adjustment to the
   interval schedule as specified in the reconnection acceptance ACCT
   Timer.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a> Security Considerations</span>

   This document provides a framework for policy usage feedback, using
   COPS-PR as the transport mechanism.  As feedback information is
   sensitive, it MUST be transported in a secured manner.  COPS
   [<a href="./rfc2748" title="&quot;The COPS (Common Open Policy Service) Protocol&quot;">RFC2748</a>] and COPS-PR [<a href="./rfc3084" title="&quot;COPS Usage for Policy Provisioning (COPS- PR)&quot;">RFC3084</a>] provide for such secured transport,
   with mandatory and suggested security mechanisms.

   The usage feedback information themselves MUST be secured, with their
   security requirement specified in their respective documents.



















<span class="grey">Rawlins, et al.              Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3483">RFC 3483</a>                COPS Feedback Framework               March 2003</span>


<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a> References</span>

<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a> Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]     Bradner, S., "Key words to use in the RFCs", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>,
                 <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2748">RFC2748</a>]     Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
                 and A. Sastry, "The COPS (Common Open Policy Service)
                 Protocol", <a href="./rfc2748">RFC 2748</a>, January 2000.

   [<a id="ref-RFC2753">RFC2753</a>]     Yavatkar, R., Pendarakis, D. and R. Guerin, "A
                 Framework for Policy-based Admission Control", <a href="./rfc2753">RFC</a>
                 <a href="./rfc2753">2753</a>, January 2000.

   [<a id="ref-RFC3084">RFC3084</a>]     Chan, K., Durham, D., Gai, S., Herzog, S., McCloghrie,
                 K., Reichmeyer, F., Seligson, J., Smith, A. and R.
                 Yavatkar, "COPS Usage for Policy Provisioning (COPS-
                 PR)", <a href="./rfc3084">RFC 3084</a>, March 2001.

<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a> Informative References</span>

   [<a id="ref-SIP-AAA-QOS">SIP-AAA-QOS</a>] Gross, G., Sinnreich, H. Rawlins D. and T. Havinis,
                 "QoS and AAA Usage with SIP Based IP Communications",
                 Work in Progress.


























<span class="grey">Rawlins, et al.              Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3483">RFC 3483</a>                COPS Feedback Framework               March 2003</span>


<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a> Authors' Addresses</span>

   Diana Rawlins
   WorldCom
   901 International Parkway
   Richardson, Texas 75081

   Phone: 972-729-4071
   EMail: Diana.Rawlins@wcom.com


   Amol Kulkarni
   JF3-206
   2111 NE 25th Ave
   Hillsboro, Oregon 97124

   Phone: 503-712-1168
   EMail: amol.kulkarni@intel.com


   Kwok Ho Chan
   Nortel Networks, Inc.
   600 Technology Park Drive
   Billerica, MA 01821 USA

   Phone: 978-288-8175
   EMail: khchan@nortelnetworks.com


   Martin Bokaemper
   Juniper Networks
   700 Silver Seven Road
   Kanata, ON, K2V 1C3, Canada

   Phone: 613-591-2735
   EMail: mbokaemper@juniper.net















<span class="grey">Rawlins, et al.              Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3483">RFC 3483</a>                COPS Feedback Framework               March 2003</span>


<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a> Full Copyright Statement</span>

   Copyright (C) The Internet Society (2003).  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 RFC Editor function is currently provided by the
   Internet Society.



















Rawlins, et al.              Informational                     [Page 10]
</pre>