doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3483.txt b/doc/rfc/rfc3483.txt
new file mode 100644
index 0000000..e00f684
--- /dev/null
+++ b/doc/rfc/rfc3483.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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
+
+
+  Framework for Policy Usage Feedback for Common Open Policy Service
+                  with Policy Provisioning (COPS-PR)
+
+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 (RFC 2748), 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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rawlins, et al.              Informational                      [Page 1]
+
+RFC 3483                COPS Feedback Framework               March 2003
+
+
+Table of Contents
+
+   Glossary........................................................... 2
+   1  Introduction.................................................... 2
+   2  Overview........................................................ 3
+   3  Requirements for Normal Operations.............................. 3
+   4  Periodic Nature of Policy Usage Feedback........................ 4
+      4.1 Reporting Intervals......................................... 4
+   5  Suspension, Resumption and Halting of Usage Monitoring and
+      Reporting....................................................... 5
+   6  Solicited Feedback.............................................. 5
+   7  Usage reports on shared objects................................. 5
+   8  Context......................................................... 6
+   9  Delete Request States........................................... 7
+   10 Failover........................................................ 7
+   11 Security Considerations......................................... 7
+   12 References...................................................... 8
+      12.1 Normative References....................................... 8
+      12.2 Informative References..................................... 8
+   13 Authors' Addresses.............................................. 9
+   14 Full Copyright Statement........................................10
+
+Glossary
+
+   COPS - Common Open Policy Service.  See [RFC2748].
+   COPS-PR - COPS Usage for Policy Provisioning.  See [RFC3084].
+   PDP - Policy Decision Point.  See [RFC2753].
+   PEP - Policy Enforcement Point.  See [RFC2753].
+   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.
+
+1 Introduction
+
+   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 [SIP-AAA-QOS].
+
+
+
+
+
+
+Rawlins, et al.              Informational                      [Page 2]
+
+RFC 3483                COPS Feedback Framework               March 2003
+
+
+   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.
+
+2 Overview
+
+   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.
+
+3 Requirements for Normal Operations
+
+   Per COPS [RFC2748], 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
+
+
+
+Rawlins, et al.              Informational                      [Page 3]
+
+RFC 3483                COPS Feedback Framework               March 2003
+
+
+   there are exceptions where reports containing feedback are provided
+   prior to the Accounting Timer interval (see section 6).  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.
+
+4 Periodic Nature of Policy Usage Feedback
+
+   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.
+
+4.1 Reporting Intervals
+
+   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.
+
+
+
+
+
+
+Rawlins, et al.              Informational                      [Page 4]
+
+RFC 3483                COPS Feedback Framework               March 2003
+
+
+   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.
+
+5 Suspension, Resumption and Halting of Usage Monitoring and Reporting
+
+   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.
+
+6 Solicited Feedback
+
+   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.
+
+7 Usage reports on shared objects
+
+   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.
+
+
+
+
+
+Rawlins, et al.              Informational                      [Page 5]
+
+RFC 3483                COPS Feedback Framework               March 2003
+
+
+   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.
+
+8 Context
+
+   COPS-PR [RFC3084] 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.
+
+
+
+
+
+
+
+
+Rawlins, et al.              Informational                      [Page 6]
+
+RFC 3483                COPS Feedback Framework               March 2003
+
+
+9 Delete Request States
+
+   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.
+
+10 Failover
+
+   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.
+
+11 Security Considerations
+
+   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
+   [RFC2748] and COPS-PR [RFC3084] 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rawlins, et al.              Informational                      [Page 7]
+
+RFC 3483                COPS Feedback Framework               March 2003
+
+
+12 References
+
+12.1 Normative References
+
+   [RFC2119]     Bradner, S., "Key words to use in the RFCs", BCP 14,
+                 RFC 2119, March 1997.
+
+   [RFC2748]     Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.
+                 and A. Sastry, "The COPS (Common Open Policy Service)
+                 Protocol", RFC 2748, January 2000.
+
+   [RFC2753]     Yavatkar, R., Pendarakis, D. and R. Guerin, "A
+                 Framework for Policy-based Admission Control", RFC
+                 2753, January 2000.
+
+   [RFC3084]     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)", RFC 3084, March 2001.
+
+12.2 Informative References
+
+   [SIP-AAA-QOS] Gross, G., Sinnreich, H. Rawlins D. and T. Havinis,
+                 "QoS and AAA Usage with SIP Based IP Communications",
+                 Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rawlins, et al.              Informational                      [Page 8]
+
+RFC 3483                COPS Feedback Framework               March 2003
+
+
+13 Authors' Addresses
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rawlins, et al.              Informational                      [Page 9]
+
+RFC 3483                COPS Feedback Framework               March 2003
+
+
+14 Full Copyright Statement
+
+   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]
+