idnits 2.17.1 draft-ietf-rap-feedback-frwk-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([COPS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2001) is 8324 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 36, but not defined == Unused Reference: 'SIP-AAA-QOS' is defined on line 251, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-gross-sipaq-00 -- Possible downref: Normative reference to a draft: ref. 'SIP-AAA-QOS' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Diana Rawlins 3 Expiration: January 2002 WorldCom 4 File: draft-ietf-rap-feedback-frwk-00.txt Amol Kulkarni 5 Intel 7 Framework of COPS-PR Policy Usage Feedback 8 Last Updated July 12, 2001 10 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Conventions used in this document 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 33 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in 35 [RFC-2119]. 37 Abstract 38 Common Open Policy Services Protocol [COPS], RFC 2748, defined the 39 capability of reporting information to the PDP. The types of 40 report information are success, failure and accounting of an 41 installed state. This document focuses on the accounting report 42 type and the necessary framework for the monitoring and reporting 43 of usage feedback for an installed state. 45 Table of Contents 47 1 Introduction.....................................................3 48 2 Overview.........................................................3 49 3 Requirements for Normal Operations...............................3 50 4 Periodic Nature of Policy Usage Feedback.........................4 51 4.1 Reporting Intervals............................................4 52 5 Suspension, Resumption and Halting of Usage Monitoring and 53 Reporting..........................................................4 54 6 Solicited Feedback...............................................5 55 7 Context..........................................................5 56 8 Delete Request States............................................5 57 9 Failover.........................................................5 58 10 Security Considerations.........................................6 59 11 Authors' Addresses..............................................6 60 12 References......................................................6 62 1 Introduction 63 Policy usage reported by the PEP makes a richer set of information 64 available to the PDP for decision-making. This report accounting 65 information can impact future decisions made by the PDP and the 66 resulting policy installed by the PDP at the PEP. For example, a 67 PDP making policy for a SIP signaled multimedia session may need 68 to base the decision in part on usage information related to 69 previously installed QoS policy decisions. Furthermore, the PDP 70 may coordinate this usage information with other external systems 71 to determine the future policy such as the case with the PDP 72 coordinating multimedia session QoS and clearinghouse 73 authorizations [SIP-AAA-QOS.] 75 The scope of this document is to describe the framework for policy 76 usage monitored and reported by the PEP and collected at the PDP. 77 The charging, rating and billing models as well as other 78 accounting or statistics gathering events detectable by the PDP 79 are beyond the scope of this framework. 81 2 Overview 83 There are two aspects to defining policies for usage feedback. One 84 aspect is defining what to monitor and the second is defining what 85 to report. The selection criteria policy specifies the conditions 86 for the monitoring and recording of the associated usage policy. 87 The usage criteria policy class defines what metrics are recorded 88 and reported by the PEP to the PDP in the Report message. For 89 example, a usage policy may be defined to provide counts of 90 packets received. The selection criteria policy may identify the 91 filter on which to base the packet counts. A third policy may be 92 used to associated, or link, the selection and usage policies. 94 3 Requirements for Normal Operations 96 Per [COPS], the PDP specifies the minimum feedback interval in the 97 Accounting Timer object that is included in the Client Accept 98 message during connection establishment. This specifies the 99 maximum frequency with which the PEP issues unsolicited accounting 100 type reports. The purpose of this interval is to pace the number 101 of report messages sent to the PDP. It is not the goal of the 102 interval defined by the ACCT Timer value to provide precision 103 synchronization or timing. 105 The selection and usage criteria for feedback reporting are 106 defined by the PDP. Feedback policies, which define the necessary 107 selection and usage criteria, are included by the PDP in a 108 Decision message to the PEP. The usage is then periodically 109 reported by the PEP at intervals no more frequently than specified 110 in the Accounting Timer object, except as noted in the following 111 sections. (There are exceptions where reports containing feedback 112 are provided prior the interval in several cases described in 113 sections 5, 7 and 8.) The PDP may also solicit usage feedback 114 which is to be reported back immediately by the PEP. Usage 115 information may be cleared upon reporting. This is specified in 116 the usage policy criteria. 118 The PEP monitors and tracks the usage information. The PDP is the 119 collection point for the policy usage information reported by the 120 PEP clients within the administrative domain. The PDP may also 121 collect other accounting event information that is outside the 122 scope of this document. 124 4 Periodic Nature of Policy Usage Feedback 126 Generally the accounting policy is periodic in nature and the 127 reporting is unsolicited. The unsolicited reports are supplied per 128 the interval defined by the PDP. The periodic unsolicited reports 129 are dictated by timer intervals and use a deterministic amount of 130 network resources. 132 The PDP informs the PEP of the minimal feedback interval during 133 client connection establishment with the Accounting Timer object. 134 The PDP may specify feedback intervals in the specific usage 135 policies as well. The unsolicited monitoring and reporting by the 136 PEP may be suspended and resumed at the direction of the PDP. 138 4.1 Reporting Intervals 140 The PEP must provide usage feedback in the report message on an 141 interval basis. The interval is defined in terms of the Accounting 142 Object, ACCT Timer value. A single interval is equal to the number 143 of seconds specified by the ACCT Timer value. The PDP may define a 144 specific number of intervals, which are to pass before the PEP 145 provides the usage feedback for a specific policy in a report. 146 When the ACCT Timer value is equal to zero there is no unsolicited 147 usage feedback provided by the PEP. However, the PEP still 148 monitors and tracks the usage per the PDP policy and reports it 149 when the PDP solicits the feedback. 151 The PDP may solicit usage feedback in the middle of an interval. 152 The PEP shall provide the requested usage information and clear 153 the usage information if the usage policy requires that the 154 attribute be cleared after reporting. The PEP should continue to 155 maintain the same interval schedule as defined by the PDP in the 156 Accounting Timer object and established at client connection 157 acceptance. 159 5 Suspension, Resumption and Halting of Usage Monitoring and Reporting 161 The PDP may direct the PEP to suspend usage feedback report 162 messages and then at a later time instruct the PEP to resume the 163 reporting of feedback. The PDP may also instruct the PEP to 164 suspend the monitoring and tracking of usage which also results in 165 the suppression of the feedback reports until the PDP later tells 166 the PEP to resume the monitoring (and reporting). When the PDP 167 suspends monitoring or suspends reporting, it also specifies 168 whether the PEP is to provide an unsolicited feedback report of 169 the current monitored usage of the affected usage policy. The PDP 170 may suspend and resume monitoring and reporting for specific usage 171 policies or for all usage policies. 173 Halting of usage monitoring and feedback is done by issuing a 174 Decision Remove of the feedback usage policies. The PEP is to stop 175 any monitoring and reporting associated with the policy 176 immediately. 178 6 Solicited Feedback 180 There may be instances when it is useful for the PDP to control 181 the feedback per an on-demand basis rather than a periodic basis. 182 The PDP may solicit the PEP for usage feedback with a Decision. 183 The PDP may solicit usage feedback at any time during the 184 accounting interval defined by the ACCT Timer. The PEP responds 185 immediately and reports the appropriate usage policies and should 186 continue to follow the usage feedback interval schedule 187 established during connection acceptance. 189 7 Context 191 The monitoring and recording of usage policies is subject to 192 context switches in a manner similar to that of the enforcement 193 policy. Usage policy is monitored, recorded and reported while the 194 associated policy information context is active. When the context 195 is deactivated a report containing the usage policies for that 196 context is provided to the PDP. The PEP does not perform any 197 monitoring, tracking or reporting of policy usage for a given 198 context while the context is inactive. 200 8 Delete Request States 202 The PEP must send any outstanding usage data monitored during the 203 feedback interval to the PDP via an unsolicited report immediately 204 prior to issuing a Delete Request State. This is also the case 205 when the PDP initiates the Delete Request State. 207 9 Failover 209 In the event the connection is lost between the PEP and PDP, the 210 PEP continues to track usage information as long as it continues 211 to enforce installed (cached) policy. When the locally installed 212 policy at the PEP expires, the usage policy data also expires and 213 is no longer monitored. 215 Upon successful reconnection where the PEP is still caching 216 policy, the PDP indicates deterministically to the PEP that the 217 PEP may resume usage feedback reporting. The PEP reports all 218 cached usage and resumes periodic reporting making any needed 219 adjustment to the interval schedule as specified in the 220 reconnection acceptance ACCT Timer. 222 10 Security Considerations 224 The feedback information is sensitive and requires that authorized 225 messaging occur between the PEP and the PDP. This protection can 226 be accomplished with IPSEC between the PEP and the PDP or using 227 the security mechanisms described in the base COPS protocol. 229 11 Authors' Addresses 231 Diana Rawlins 232 WorldCom 233 901 International Parkway 234 Richardson, Texas 75081 235 Phone: 972-729-1044 236 Email: Diana.Rawlins@wcom.com 238 Amol Kulkarni 239 JF3-206 240 2111 NE 25th Ave 241 Hillsboro, Oregon 97124 242 Phone: 503-712-1168 243 Email: amol.kulkarni@intel.com 245 12 References 247 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., 248 and A. Sastry, "The COPS (Common Open Policy Service) Protocol" 249 RFC 2748, January 2000. 251 [SIP-AAA-QOS] Gross, G.,Sinnreich, H. Rawlins D., Havinis, T. " QoS 252 and AAA Usage with SIP Based IP Communications" draft-gross-sipaq- 253 00.txt, November 2000.