idnits 2.17.1 draft-ietf-rap-feedback-frwk-03.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 abstract seems to contain references ([RFC2748]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (October 16, 2002) is 7863 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 40, but not defined == Unused Reference: 'RFC2119' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'SIP-AAA-QOS' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'COPS-TLS' is defined on line 369, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2753 ** Downref: Normative reference to an Historic RFC: RFC 3084 == Outdated reference: A later version (-01) exists of draft-gross-sipaq-00 == Outdated reference: A later version (-11) exists of draft-ietf-rap-cops-tls-02 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Diana Rawlins 3 Expiration: March 2003 WorldCom 4 File: draft-ietf-rap-feedback-frwk-03.txt Amol Kulkarni 5 Intel 6 Martin Bokaemper 7 Juniper Networks 8 Kwok Ho Chan 9 Nortel Networks 11 Framework for Policy Usage Feedback for Common Open Policy Service 12 with Policy Provisioning (COPS-PR) 13 Last Updated October 16, 2002 15 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Conventions used in this document 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 38 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 39 in this document are to be interpreted as described in [RFC-2119]. 41 Abstract 42 Common Open Policy Services (COPS) Protocol [RFC2748], defined the 43 capability of reporting information to the PDP. The types of 44 report information are success, failure and accounting of an 45 installed state. This document focuses on the COPS Report Type of 46 Accounting and the necessary framework for the monitoring and 47 reporting of usage feedback for an installed state. 49 Table of Contents 51 Glossary.........................................................3 52 1 Introduction...................................................3 53 2 Overview.......................................................3 54 3 Requirements for Normal Operations.............................4 55 4 Periodic Nature of Policy Usage Feedback.......................4 56 4.1 Reporting Intervals..........................................4 57 5 Suspension, Resumption and Halting of Usage Monitoring and 58 Reporting........................................................5 59 6 Solicited Feedback.............................................5 60 7 Usage reports on shared objects................................6 61 8 Context........................................................6 62 9 Delete Request States..........................................7 63 10 Failover......................................................7 64 11 Security Considerations.......................................7 65 12 Authors' Addresses............................................7 66 13 References....................................................8 67 13.1 Normative References........................................8 68 13.2 Informative References......................................8 70 Glossary 71 COPS - Common Open Policy Service. See [RFC2748]. 72 COPS-PR - COPS Usage for Policy Provisioning. See [RFC3084]. 73 PDP - Policy Decision Point. See [RFC2753]. 74 PEP - Policy Enforcement Point. See [RFC2753]. 75 PIB - Policy Information Base. The database of policy information. 76 PRC - Provisioning Class. A type of policy data. 77 PRI - Provisioning Instance. An instance of a PRC. 78 QoS - Quality of Service. 80 1 Introduction 81 Policy usage reported by the PEP makes a richer set of information 82 available to the PDP for decision-making. This feedback on policy 83 usage can impact future decisions made by the PDP and the 84 resulting policy installed by the PDP at the PEP. For example, a 85 PDP making policy for a SIP signaled multimedia session may need 86 to base the decision in part on usage information related to 87 previously installed QoS policy decisions. Furthermore, the PDP 88 may coordinate this usage information with other external systems 89 to determine the future policy such as the case with the PDP 90 coordinating multimedia session QoS and clearinghouse 91 authorizations [SIP-AAA-QOS.] 93 The scope of this document is to describe the framework for policy 94 usage monitored and reported by the PEP and collected at the PDP. 95 The charging, rating and billing models as well as other 96 accounting or statistics gathering events detectable by the PDP 97 are beyond the scope of this framework. 99 2 Overview 101 There are three main aspects to define policies for usage 102 feedback: 103 - which objects are monitored 104 - the metrics to be monitored and reported for these objects 105 - when the reports are delivered 107 In the framework a selection criteria policy specifies one or more 108 objects that should be monitored � for example a dropper or the 109 instances of an IP Filter for all its interfaces. 111 A usage feedback class is used to specify which metrics are to be 112 collected for a set of objects - instances of the specified class 113 carry the usage information when it is reported. 114 The valid combinations of monitored object classes and usage 115 feedback classes are reported by the PEP as capabilities. 117 Finally selection criteria policy and usage feedback class are 118 bound together in a linkage policy, which also contains the 119 information when reports are generated. Reports are usually sent 120 periodically but more restrictions can be placed on the generation 121 of reports, like thresholds or a change in the data. 123 3 Requirements for Normal Operations 125 Per COPS [RFC2748], the PDP specifies the minimum feedback 126 interval in the Accounting Timer object that is included in the 127 Client Accept message during connection establishment. This 128 specifies the maximum frequency with which the PEP issues 129 unsolicited accounting type report messages. The purpose of this 130 interval is to pace the number of report messages sent to the PDP. 131 It is not the goal of the interval defined by the ACCT Timer value 132 to provide precision synchronization or timing. 134 The selection and the associated usage criteria and intervals for 135 feedback reporting are defined by the PDP. Feedback policies, 136 which define the necessary selection and linkages to usage 137 feedback criteria, are included by the PDP in a Decision message 138 to the PEP. The usage feedback is then periodically reported by 139 the PEP at intervals defined in the linkage policies at a rate no 140 more frequently than specified in the Accounting Timer object. 141 Note that there are exceptions where reports containing feedback 142 are provided prior the Accounting Timer interval (see section 6). 143 The PDP may also solicit usage feedback which is to be reported 144 back immediately by the PEP. Usage information may be cleared upon 145 reporting. This is specified in the usage policy criteria. 147 The PEP monitors and tracks the usage feedback information. The 148 PDP is the collection point for the policy usage feedback 149 information reported by the PEP clients within the administrative 150 domain. The PDP may also collect other accounting event 151 information that is outside the scope of this document. 153 4 Periodic Nature of Policy Usage Feedback 155 Generally the policy usage feedback is periodic in nature and the 156 reporting is unsolicited. The unsolicited reports are supplied per 157 the interval defined by the PDP. The periodic unsolicited reports 158 are dictated by timer intervals and use a deterministic amount of 159 network resources. 161 The PDP informs the PEP of the minimal feedback interval during 162 client connection establishment with the Accounting Timer object. 163 The PDP may specify feedback intervals in the specific usage 164 feedback policies as well. The unsolicited monitoring and 165 reporting by the PEP may be suspended and resumed at the direction 166 of the PDP. 168 4.1 Reporting Intervals 170 The generation of usage feedback by the PEP to the PDP is done 171 under different conditions that include feedback on demand, 172 periodic feedback or feedback when a defined threshold is reached. 174 The periodic feedback for a usage policy can be further defined in 175 terms of providing feedback if there is a change or providing 176 feedback periodically regardless of a change in value. 178 The periodic interval is defined in terms of the Accounting 179 Object, ACCT Timer value. A single interval is equal to the number 180 of seconds specified by the ACCT Timer value. The PDP may define a 181 specific number of intervals, which are to pass before the PEP 182 provides the usage feedback for a specific policy in a report. 183 When the ACCT Timer value is equal to zero there is no unsolicited 184 usage feedback provided by the PEP. However, the PEP still 185 monitors and tracks the usage per the PDP policy and reports it 186 when the PDP solicits the feedback. 188 Reporting may be based on a defined threshold value in the usage 189 PRC that is reached. 191 The PDP may solicit usage feedback in the middle of an interval by 192 sending a COPS decision message. The exact contents of the message 193 are out of the scope of this framework document and need to be 194 defined in a document that actually implements usage feedback 195 using this framework. 197 The PEP, on receiving a solicit decision from the PDP, shall 198 provide the requested usage information and clear the usage 199 information if the usage policy requires that the attribute be 200 cleared after reporting. The PEP should continue to maintain the 201 same interval schedule as defined by the PDP in the Accounting 202 Timer object and established at client connection acceptance. 204 5 Suspension, Resumption and Halting of Usage Monitoring and Reporting 206 The PDP may direct the PEP to suspend usage feedback report 207 messages and then at a later time instruct the PEP to resume the 208 reporting of feedback. The PDP may also instruct the PEP to 209 suspend the monitoring and tracking of usage which also results in 210 the suppression of the feedback reports until the PDP later tells 211 the PEP to resume the monitoring (and reporting). When the PDP 212 suspends monitoring or suspends reporting, it also specifies 213 whether the PEP is to provide an unsolicited feedback report of 214 the current monitored usage of the affected usage policy. The PDP 215 may suspend and resume monitoring and reporting for specific usage 216 policies or for all of the usage feedback policies. 218 6 Solicited Feedback 220 There may be instances when it is useful for the PDP to control 221 the feedback per an on-demand basis rather than a periodic basis. 222 The PDP may solicit the PEP for usage feedback with a Decision. 223 The PDP may solicit usage feedback at any time during the 224 accounting interval defined by the ACCT Timer. The PEP responds 225 immediately and reports the appropriate usage policies and should 226 continue to follow the usage feedback interval schedule 227 established during connection acceptance. 229 7 Usage reports on shared objects 231 While some objects in a context's namespace directly represent 232 unique objects of the PEP's configuration, other COPS objects can 233 be shared between multiple actual assignments in the PEP. 235 Whenever the PEP creates multiple actual configuration instances 236 from the same COPS objects, these assignments can potentially 237 collect their own statistics independently. Since the individual 238 assignments do not have a direct representation as COPS objects, 239 additional information must be provided to uniquely identify the 240 assignment that generates the usage information. As an example, if 241 the PEP needs to create multiple usage objects for an IP address, 242 it may use the port number to uniquely identify each object i.e. 243 the (IP address, port number) combination is now the unique 244 identify of the object. 246 The feedback framework allows this information to be distributed 247 between a selection criteria PRC and the corresponding usage 248 feedback PRC, however both PRCs together always must contain 249 sufficient information for the finest granularity of usage 250 collection supported by the PEP. 252 If all the additional information is not part of the selection 253 criteria PRC, all matching assignments are selected to collect 254 usage information. The necessary data to differentiate these 255 assignments is part of the usage feedback PRC. 257 Implementations based on the feedback framework should always 258 provide a selection criteria PRC that contains a complete set of 259 information to select a unique assignment, while underspecified 260 selection criteria PRCs (together with extended usage feedback 261 PRCs) are optional. 263 8 Context 265 COPS-PR [RFC3084] allows multiple, independent, disjoint instances 266 of policies to be configured on the PEP. Each instance is known as 267 a context, and only one context can be active at any given moment. 268 The PDP directs the PEP to switch between contexts using a single 269 decision message. 271 The monitoring and recording of usage policies is subject to 272 context switches in a manner similar to that of the enforcement 273 policy. Usage policy is monitored, recorded and reported while the 274 associated policy information context is active. When the context 275 is deactivated a report message containing the usage feedback 276 policies for that context is provided to the PDP. The PEP does not 277 perform any monitoring, tracking or reporting of policy usage for 278 a given context while the context is inactive. 280 9 Delete Request States 282 The PEP MUST send any outstanding usage feedback data monitored 283 during the feedback interval to the PDP via an unsolicited report 284 message immediately prior to issuing a Delete Request State. This 285 is also the case when the PDP initiates the Delete Request State. 287 10 Failover 289 In the event the connection is lost between the PEP and PDP, the 290 PEP continues to track usage feedback information as long as it 291 continues to enforce installed (cached) policy. When the locally 292 installed policy at the PEP expires, the usage feedback policy 293 data also expires and is no longer monitored. 295 Upon successful reconnection where the PEP is still caching 296 policy, the PDP indicates deterministically to the PEP that the 297 PEP may resume usage feedback reporting. The PEP reports all 298 cached usage and resumes periodic reporting making any needed 299 adjustment to the interval schedule as specified in the 300 reconnection acceptance ACCT Timer. 302 11 Security Considerations 304 This document provides a framework for policy usage feedback, 305 using COPS-PR as the transport mechanism. As feedback information 306 is sensitive, it MUST be transported in a secured manner. COPS 307 [RFC2748] and COPS-PR [RFC3084] provide for such secured 308 transport, with mandatory and suggested security mechanisms. 310 The usage feedback information themselves MUST be secured, with 311 their security requirement specified in their respective 312 documents. 314 12 Authors' Addresses 316 Diana Rawlins 317 WorldCom 318 901 International Parkway 319 Richardson, Texas 75081 320 Phone: 972-729-1044 321 Email: Diana.Rawlins@wcom.com 323 Amol Kulkarni 324 JF3-206 325 2111 NE 25th Ave 326 Hillsboro, Oregon 97124 327 Phone: 503-712-1168 328 Email: amol.kulkarni@intel.com 330 Kwok Ho Chan 331 Nortel Networks, Inc. 333 600 Technology Park Drive 334 Billerica, MA 01821 USA 335 Phone: 978-288-8175 336 Email: khchan@nortelnetworks.com 338 Martin Bokaemper 339 Juniper Networks 340 700 Silver Seven Road 341 Kanata, ON, K2V 1C3, Canada 342 Phone: 613-591-2735 343 Email: mbokaemper@juniper.net 345 13 References 347 13.1 Normative References 349 [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., 350 and A. Sastry, "The COPS (Common Open Policy Service) Protocol", 351 RFC 2748, January 2000. 353 [RFC2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework 354 for Policy Based Admission Control", RFC 2753, January 2000. 356 [RFC3084] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. 357 Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for 358 Policy Provisioning," RFC 3084, March 2001. 360 13.2 Informative References 362 [RFC2119] S. Bradner, "Key words to use in the RFCs", RFC 2119. Mar 363 1997. 365 [SIP-AAA-QOS] Gross, G., Sinnreich, H. Rawlins D., Havinis, T. "QoS 366 and AAA Usage with SIP Based IP Communications" draft-gross-sipaq- 367 00.txt, November 2000. 369 [COPS-TLS], Walker, J., Kulkarni, A.,"COPS Over TLS", draft-ietf- 370 rap-cops-tls-02.txt, October 2001.