idnits 2.17.1 draft-ietf-rap-feedback-frwk-02.txt: -(320): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 are 4 instances 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 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 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 (March 1, 2002) is 8085 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 39, but not defined == Unused Reference: 'SIP-AAA-QOS' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'COPS-TLS' is defined on line 320, 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' == Outdated reference: A later version (-11) exists of draft-ietf-rap-cops-tls-02 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Diana Rawlins 3 Expiration: September 2002 WorldCom 4 File: draft-ietf-rap-feedback-frwk-02.txt Amol Kulkarni 5 Intel 6 Martin Bokaemper 7 Unisphere Networks 8 Kwok Ho Chan 9 Nortel Networks 11 Framework of COPS-PR Policy Usage Feedback 12 Last Updated March 1, 2002 14 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Conventions used in this document 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 37 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 38 in this document are to be interpreted as described in [RFC-2119]. 40 Abstract 41 Common Open Policy Services Protocol [COPS], RFC 2748, defined the 42 capability of reporting information to the PDP. The types of 43 report information are success, failure and accounting of an 44 installed state. This document focuses on the COPS Report Type of 45 Accounting and the necessary framework for the monitoring and 46 reporting of usage feedback for an installed state. 48 Table of Contents 50 1 Introduction...................................................3 51 2 Overview.......................................................3 52 3 Requirements for Normal Operations.............................3 53 4 Periodic Nature of Policy Usage Feedback.......................4 54 4.1 Reporting Intervals..........................................4 55 5 Suspension, Resumption and Halting of Usage Monitoring and 56 Reporting........................................................5 57 6 Solicited Feedback.............................................5 58 7 Usage reports on shared objects................................5 59 8 Context........................................................6 60 9 Delete Request States..........................................6 61 10 Failover......................................................6 62 11 Security Considerations.......................................6 63 12 Authors' Addresses............................................7 64 13 References....................................................7 66 1 Introduction 67 Policy usage reported by the PEP makes a richer set of information 68 available to the PDP for decision-making. This feedback on policy 69 usage can impact future decisions made by the PDP and the 70 resulting policy installed by the PDP at the PEP. For example, a 71 PDP making policy for a SIP signaled multimedia session may need 72 to base the decision in part on usage information related to 73 previously installed QoS policy decisions. Furthermore, the PDP 74 may coordinate this usage information with other external systems 75 to determine the future policy such as the case with the PDP 76 coordinating multimedia session QoS and clearinghouse 77 authorizations [SIP-AAA-QOS.] 79 The scope of this document is to describe the framework for policy 80 usage monitored and reported by the PEP and collected at the PDP. 81 The charging, rating and billing models as well as other 82 accounting or statistics gathering events detectable by the PDP 83 are beyond the scope of this framework. 85 2 Overview 87 There are three main aspects to define policies for usage 88 feedback: 89 - which objects are monitored 90 - the metrics to be monitored and reported for these objects 91 - when the reports are delivered 93 In the framework a selection criteria policy specifies one or more 94 objects that should be monitored � for example a dropper or the 95 instances of an IP Filter for all its interfaces. 97 A usage feedback class is used to specify which metrics are to be 98 collected for a set of objects - instances of the specified class 99 carry the usage information when it is reported. 100 The valid combinations of monitored object classes and usage 101 feedback classes are reported by the PEP as capabilities. 103 Finally selection criteria policy and usage feedback class are 104 bound together in a linkage policy, which also contains the 105 information when reports are generated. Reports are usually sent 106 periodically but more restrictions can be placed on the generation 107 of reports, like thresholds or a change in the data. 109 3 Requirements for Normal Operations 111 Per [COPS], the PDP specifies the minimum feedback interval in the 112 Accounting Timer object that is included in the Client Accept 113 message during connection establishment. This specifies the 114 maximum frequency with which the PEP issues unsolicited accounting 115 type report messages. The purpose of this interval is to pace the 116 number of report messages sent to the PDP. It is not the goal of 117 the interval defined by the ACCT Timer value to provide precision 118 synchronization or timing. 120 The selection and the associated usage criteria and intervals for 121 feedback reporting are defined by the PDP. Feedback policies, 122 which define the necessary selection and linkages to usage 123 feedback criteria, are included by the PDP in a Decision message 124 to the PEP. The usage feedback is then periodically reported by 125 the PEP at intervals defined in the linkage policies at a rate no 126 more frequently than specified in the Accounting Timer object. 127 Note that there are exceptions where reports containing feedback 128 are provided prior the Accounting Timer interval in several cases 129 described in sections 6 and 7.) The PDP may also solicit usage 130 feedback which is to be reported back immediately by the PEP. 131 Usage information may be cleared upon reporting. This is 132 specified in the usage policy criteria. 134 The PEP monitors and tracks the usage feedback information. The 135 PDP is the collection point for the policy usage feedback 136 information reported by the PEP clients within the administrative 137 domain. The PDP may also collect other accounting event 138 information that is outside the scope of this document. 140 4 Periodic Nature of Policy Usage Feedback 142 Generally the policy usage feedback is periodic in nature and the 143 reporting is unsolicited. The unsolicited reports are supplied per 144 the interval defined by the PDP. The periodic unsolicited reports 145 are dictated by timer intervals and use a deterministic amount of 146 network resources. 148 The PDP informs the PEP of the minimal feedback interval during 149 client connection establishment with the Accounting Timer object. 150 The PDP may specify feedback intervals in the specific usage 151 feedback policies as well. The unsolicited monitoring and 152 reporting by the PEP may be suspended and resumed at the direction 153 of the PDP. 155 4.1 Reporting Intervals 157 The generation of usage feedback by the PEP to the PDP is done 158 under different conditions that include feedback on demand, 159 periodic feedback or feedback when a defined threshold is reached. 160 The periodic feedback for a usage policy can be further defined in 161 terms of providing feedback if there is a change or providing 162 feedback periodically regardless of a change in value. 164 The periodic interval is defined in terms of the Accounting 165 Object, ACCT Timer value. A single interval is equal to the number 166 of seconds specified by the ACCT Timer value. The PDP may define a 167 specific number of intervals, which are to pass before the PEP 168 provides the usage feedback for a specific policy in a report. 169 When the ACCT Timer value is equal to zero there is no unsolicited 170 usage feedback provided by the PEP. However, the PEP still 171 monitors and tracks the usage per the PDP policy and reports it 172 when the PDP solicits the feedback. 174 Reporting may be based on a defined threshold value in the usage 175 PRC that is reached. 177 The PDP may solicit usage feedback in the middle of an interval. 178 The PEP shall provide the requested usage information and clear 179 the usage information if the usage policy requires that the 180 attribute be cleared after reporting. The PEP should continue to 181 maintain the same interval schedule as defined by the PDP in the 182 Accounting Timer object and established at client connection 183 acceptance. 185 5 Suspension, Resumption and Halting of Usage Monitoring and Reporting 187 The PDP may direct the PEP to suspend usage feedback report 188 messages and then at a later time instruct the PEP to resume the 189 reporting of feedback. The PDP may also instruct the PEP to 190 suspend the monitoring and tracking of usage which also results in 191 the suppression of the feedback reports until the PDP later tells 192 the PEP to resume the monitoring (and reporting). When the PDP 193 suspends monitoring or suspends reporting, it also specifies 194 whether the PEP is to provide an unsolicited feedback report of 195 the current monitored usage of the affected usage policy. The PDP 196 may suspend and resume monitoring and reporting for specific usage 197 policies or for all of the usage feedback policies. 199 6 Solicited Feedback 201 There may be instances when it is useful for the PDP to control 202 the feedback per an on-demand basis rather than a periodic basis. 203 The PDP may solicit the PEP for usage feedback with a Decision. 204 The PDP may solicit usage feedback at any time during the 205 accounting interval defined by the ACCT Timer. The PEP responds 206 immediately and reports the appropriate usage policies and should 207 continue to follow the usage feedback interval schedule 208 established during connection acceptance. 210 7 Usage reports on shared objects 212 While some objects in a context�s namespace directly represent 213 unique objects of the PEP�s configuration, other COPS objects can 214 be shared between multiple actual assignments in the PEP. 216 Whenever the PEP creates multiple actual configuration instances 217 from the same COPS objects, these assignments can potentially 218 collect their own statistics independently. Since the individual 219 assignments do not have a direct representation as COPS objects, 220 additional information must be provided to uniquely identify the 221 assignment that generates the usage information. 223 The feedback framework allows this information to be distributed 224 between a selection criteria PRC and the corresponding usage 225 feedback PRC, however both PRCs together always must contain 226 sufficient information for the finest granularity of usage 227 collection supported by the PEP. 229 If all the additional information is not part of the selection 230 criteria PRC, all matching assignments are selected to collect 231 usage information. The necessary data to differentiate these 232 assignments is part of the usage feedback PRC. 234 Implementations based on the feedback framework should always 235 provide a selection criteria PRC that contains a complete set of 236 information to select a unique assignment, while underspecified 237 selection criteria PRCs (together with extended usage feedback 238 PRCs) are optional. 240 8 Context 242 The monitoring and recording of usage policies is subject to 243 context switches in a manner similar to that of the enforcement 244 policy. Usage policy is monitored, recorded and reported while the 245 associated policy information context is active. When the context 246 is deactivated a report message containing the usage feedback 247 policies for that context is provided to the PDP. The PEP does not 248 perform any monitoring, tracking or reporting of policy usage for 249 a given context while the context is inactive. 251 9 Delete Request States 253 The PEP MUST send any outstanding usage feedback data monitored 254 during the feedback interval to the PDP via an unsolicited report 255 message immediately prior to issuing a Delete Request State. This 256 is also the case when the PDP initiates the Delete Request State. 258 10 Failover 260 In the event the connection is lost between the PEP and PDP, the 261 PEP continues to track usage feedback information as long as it 262 continues to enforce installed (cached) policy. When the locally 263 installed policy at the PEP expires, the usage feedback policy 264 data also expires and is no longer monitored. 266 Upon successful reconnection where the PEP is still caching 267 policy, the PDP indicates deterministically to the PEP that the 268 PEP may resume usage feedback reporting. The PEP reports all 269 cached usage and resumes periodic reporting making any needed 270 adjustment to the interval schedule as specified in the 271 reconnection acceptance ACCT Timer. 273 11 Security Considerations 274 The feedback information is sensitive and requires that authorized 275 messaging occur between the PEP and the PDP. This protection can 276 be accomplished with IPSEC between the PEP and the PDP, TLS [COPS 277 TLS] or using the security mechanisms described in the base COPS 278 protocol. 280 12 Authors' Addresses 282 Diana Rawlins 283 WorldCom 284 901 International Parkway 285 Richardson, Texas 75081 286 Phone: 972-729-1044 287 Email: Diana.Rawlins@wcom.com 289 Amol Kulkarni 290 JF3-206 291 2111 NE 25th Ave 292 Hillsboro, Oregon 97124 293 Phone: 503-712-1168 294 Email: amol.kulkarni@intel.com 296 Kwok Ho Chan 297 Nortel Networks, Inc. 298 600 Technology Park Drive 299 Billerica, MA 01821 USA 300 Phone: 978-288-8175 301 Email: khchan@nortelnetworks.com 303 Martin Bokaemper 304 Unisphere Networks 305 700 Silver Seven Road 306 Kanata, ON, K2V 1C3, Canada 307 Phone: 613-591-2735 308 Email: mbokaemper@unispherenetworks.com" 310 13 References 312 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., 313 and A. Sastry, "The COPS (Common Open Policy Service) Protocol" 314 RFC 2748, January 2000. 316 [SIP-AAA-QOS] Gross, G., Sinnreich, H. Rawlins D., Havinis, T. "QoS 317 and AAA Usage with SIP Based IP Communications" draft-gross-sipaq- 318 00.txt, November 2000. 320 [COPS-TLS], Walker, J., Kulkarni, A.,�COPS Over TLS�, draft-ietf- 321 rap-cops-tls-02.txt, October 2001.