idnits 2.17.00 (12 Aug 2021) /tmp/idnits56284/draft-lior-radius-prepaid-extensions-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3303. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A PPAQ AVP that contains a Service-Id is associated with that Service. A PPAQ AVP that contains a Rating-Group-Id is associated with that Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a Service-Id. A PPAQ that contains neither a Rating-Group-Id nor a Service-Id applies to the Access Service. -- 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 (February 13, 2006) is 5940 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) -- Looks like a reference, but probably isn't: 'RFC2284' on line 620 -- Looks like a reference, but probably isn't: 'RFC3576' on line 1213 == Missing Reference: '3576' is mentioned on line 1285, but not defined -- Looks like a reference, but probably isn't: 'DIAMETERCC' on line 1453 -- Looks like a reference, but probably isn't: 'RFC2865' on line 1461 == Unused Reference: '4' is defined on line 2567, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2570, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2572, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2576, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2580, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2586, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '6') ** Obsolete normative reference: RFC 3576 (ref. '7') (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4006 (ref. '9') (Obsoleted by RFC 8506) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT A. Lior 3 Internet-Draft Bridgewater Systems 4 Expires: August 17, 2006 P. Yegani 5 Cisco 6 K. Chowdhury 7 Starent Networks 8 H. Tschofenig 9 A. Pashalidis 10 Siemens 11 February 13, 2006 13 Prepaid extensions to Remote Authentication Dial-In User Service 14 (RADIUS) 15 draft-lior-radius-prepaid-extensions-10.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 17, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document describes an extension to the Remote Authentication 49 Dial- In User Service (RADIUS) protocol. This extension makes RADIUS 50 support charging for prepaid services. The extension is based on a 51 number of charging models, in particular based on volume, duration 52 and single (atomic) events. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 58 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 8 60 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 12 61 1.3. A simple use case . . . . . . . . . . . . . . . . . . . . 14 62 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 17 63 2.1. Multiple Concurrent Services . . . . . . . . . . . . . . . 17 64 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 17 65 2.3. Complex Rating Functions . . . . . . . . . . . . . . . . . 19 66 2.4. One-time Charging . . . . . . . . . . . . . . . . . . . . 20 67 2.5. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 20 68 2.6. Support for Roaming . . . . . . . . . . . . . . . . . . . 22 69 2.7. Dynamic Termination . . . . . . . . . . . . . . . . . . . 22 70 2.8. Querying and Rebalancing . . . . . . . . . . . . . . . . . 23 71 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 24 72 3.1. Authentication and Authorization Operation . . . . . . . . 24 73 3.2. Session Start Operation . . . . . . . . . . . . . . . . . 26 74 3.3. Mid-Session Operation . . . . . . . . . . . . . . . . . . 26 75 3.4. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 28 76 3.4.1. Unsolicited Session Termination Operation . . . . . . 28 77 3.4.2. Unsolicited Change of Authorization Operation . . . . 29 78 3.5. Termination Operation . . . . . . . . . . . . . . . . . . 29 79 3.6. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 29 80 3.7. Operation Considerations for Multiple Services . . . . . . 30 81 3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 30 82 3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 31 83 3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 31 84 3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 32 85 3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 32 86 3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 32 87 3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 33 88 3.7.8. Accounting Considerations . . . . . . . . . . . . . . 33 89 3.7.9. Interoperability with Diameter Credit Control 90 Application . . . . . . . . . . . . . . . . . . . . . 33 91 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 34 92 4.1. PPAC Attribute . . . . . . . . . . . . . . . . . . . . . . 34 93 4.2. Session Termination Attribute . . . . . . . . . . . . . . 35 94 4.3. PPAQ Attribute . . . . . . . . . . . . . . . . . . . . . . 36 95 4.3.1. Quota Identifier AVP . . . . . . . . . . . . . . . . . 36 96 4.3.2. VolumeQuota AVP . . . . . . . . . . . . . . . . . . . 37 97 4.3.3. VolumeThreshold AVP . . . . . . . . . . . . . . . . . 37 98 4.3.4. DurationQuota AVP . . . . . . . . . . . . . . . . . . 37 99 4.3.5. DurationThreshold AVP . . . . . . . . . . . . . . . . 37 100 4.3.6. ResourceQuota AVP . . . . . . . . . . . . . . . . . . 38 101 4.3.7. ResourceThreshold AVP . . . . . . . . . . . . . . . . 38 102 4.3.8. Value-Digits AVP . . . . . . . . . . . . . . . . . . . 38 103 4.3.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . 38 104 4.3.10. Update-Reason AVP . . . . . . . . . . . . . . . . . . 38 105 4.3.11. PrepaidServer AVP . . . . . . . . . . . . . . . . . . 39 106 4.3.12. Service-ID AVP . . . . . . . . . . . . . . . . . . . . 39 107 4.3.13. Rating-Group-ID AVP . . . . . . . . . . . . . . . . . 39 108 4.3.14. Termination-Action AVP . . . . . . . . . . . . . . . . 40 109 4.3.15. Pool-ID AVP . . . . . . . . . . . . . . . . . . . . . 40 110 4.3.16. Pool-Multiplier AVP . . . . . . . . . . . . . . . . . 40 111 4.3.17. Requested-Action AVP . . . . . . . . . . . . . . . . . 40 112 4.3.18. Check-Balance-Result AVP . . . . . . . . . . . . . . . 41 113 4.3.19. Cost-Information AVP . . . . . . . . . . . . . . . . . 41 114 4.4. Prepaid Tariff Switching Attribute (PTS) . . . . . . . . . 42 115 4.4.1. VolumeUsedAfterTariffSwitch AVP . . . . . . . . . . . 42 116 4.4.2. TariffSwitchInterval AVP . . . . . . . . . . . . . . . 43 117 4.4.3. TimeIntervalafterTariffSwitchUpdate AVP . . . . . . . 43 118 5. Translation between RADIUS prepaid and Diameter Credit 119 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 120 5.1. Session Identification . . . . . . . . . . . . . . . . . . 45 121 5.2. Translation between RADIUS prepaid client and Diameter 122 Credit Control AAA infrastructure . . . . . . . . . . . . 45 123 5.2.1. PPAC (c<->s) . . . . . . . . . . . . . . . . . . . . . 46 124 5.2.2. Service Termination Attribute (c->s) . . . . . . . . . 46 125 5.2.3. Quota Identifier Attribute (c<->s) . . . . . . . . . . 46 126 5.2.4. Volume Quota Attribute (c<->s) . . . . . . . . . . . . 46 127 5.2.5. Duration Quota Attribute (c<->s) . . . . . . . . . . . 47 128 5.2.6. Resource Quota Attribute (c<->s) . . . . . . . . . . . 47 129 5.2.7. Value Digits Attribute (c<->s) . . . . . . . . . . . . 48 130 5.2.8. Exponent Attribute (c<->s) . . . . . . . . . . . . . . 48 131 5.2.9. Volume/Duration/Resource Threshold Attributes 132 (s->c) . . . . . . . . . . . . . . . . . . . . . . . . 48 133 5.2.10. Update Reason Attribute (c->s) . . . . . . . . . . . . 48 134 5.2.11. PrepaidServer Attribute (s<->c) . . . . . . . . . . . 50 135 5.2.12. Service-ID Attribute (s<->c) . . . . . . . . . . . . . 50 136 5.2.13. Rating-Group-ID Attribute (s<->c) . . . . . . . . . . 50 137 5.2.14. Termination-Action Attribute (s->c) . . . . . . . . . 50 138 5.2.15. Pool-ID Attribute (s<->c) . . . . . . . . . . . . . . 51 139 5.2.16. Multiplier Attribute (s<->c) . . . . . . . . . . . . . 51 140 5.2.17. Requested-Action Attribute (c->s) . . . . . . . . . . 51 141 5.2.18. Check-Balance-Result Attribute (s->c) . . . . . . . . 52 142 5.2.19. Cost-Information Attribute (s->c) . . . . . . . . . . 52 143 5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) . . . . . 52 145 5.3. Translation between Diameter Credit Control client and 146 RADIUS-based AAA infrastructure . . . . . . . . . . . . . 52 147 5.3.1. CC-Correlation-Id Attribute ( ) . . . . . . . . . . . 53 148 5.3.2. CC-Request-Number Attribute (c <-> s) . . . . . . . . 53 149 5.3.3. CC-Request-Type Attribute ( ) . . . . . . . . . . . . 53 150 5.3.4. CC-Session-Failover Attribute ( ) . . . . . . . . . . 53 151 5.3.5. CC-Sub-Session-Id Attribute ( ) . . . . . . . . . . . 53 152 5.3.6. Check-Balance-Result Attribute ( ) . . . . . . . . . . 53 153 5.3.7. Cost-Information Attribute ( ) . . . . . . . . . . . . 53 154 5.3.8. Unit-Value Attribute ( ) . . . . . . . . . . . . . . . 53 155 5.3.9. Exponent Attribute ( ) . . . . . . . . . . . . . . . . 53 156 5.3.10. Value-Digits Attribute ( ) . . . . . . . . . . . . . . 54 157 5.3.11. Currency-Code Attribute ( ) . . . . . . . . . . . . . 54 158 5.3.12. Cost-Unit Attribute ( ) . . . . . . . . . . . . . . . 54 159 5.3.13. Credit-Control Attribute ( ) . . . . . . . . . . . . . 54 160 5.3.14. Credit-Control-Failure-Handling Attribute ( ) . . . . 54 161 5.3.15. Direct-Debiting-Failure-Handling Attribute ( ) . . . . 54 162 5.3.16. Multiple-Services-Credit-Control Attribute ( ) . . . . 54 163 5.3.17. Granted-Service-Unit Attribute ( ) . . . . . . . . . . 54 164 5.3.18. Requested-Service-Unit Attribute ( ) . . . . . . . . . 54 165 5.3.19. Used-Service-Unit Attribute ( ) . . . . . . . . . . . 54 166 5.3.20. Tariff-Time-Change Attribute ( ) . . . . . . . . . . . 54 167 5.3.21. CC-Time Attribute ( ) . . . . . . . . . . . . . . . . 54 168 5.3.22. CC-Money Attribute ( ) . . . . . . . . . . . . . . . . 55 169 5.3.23. CC-Total-Octets Attribute ( ) . . . . . . . . . . . . 55 170 5.3.24. CC-Input-Octets Attribute ( ) . . . . . . . . . . . . 55 171 5.3.25. CC-Output-Octets Attribute ( ) . . . . . . . . . . . . 55 172 5.3.26. CC-Service-Specific-Units Attribute ( ) . . . . . . . 55 173 5.3.27. Tariff-Change-Usage Attribute ( ) . . . . . . . . . . 55 174 5.3.28. Service-Identifier Attribute ( ) . . . . . . . . . . . 55 175 5.3.29. Rating-Group Attribute ( ) . . . . . . . . . . . . . . 55 176 5.3.30. G-S-U-Pool-Reference Attribute ( ) . . . . . . . . . . 55 177 5.3.31. G-S-U-Pool-Identifier Attribute ( ) . . . . . . . . . 55 178 5.3.32. CC-Unit-Type Attribute ( ) . . . . . . . . . . . . . . 55 179 5.3.33. Validity-Time Attribute ( ) . . . . . . . . . . . . . 55 180 5.3.34. Final-Unit-Indication Attribute ( ) . . . . . . . . . 56 181 5.3.35. Final-Unit-Action Attribute ( ) . . . . . . . . . . . 56 182 5.3.36. Restriction-Filter-Rule Attribute ( ) . . . . . . . . 56 183 5.3.37. Redirect-Server Attribute ( ) . . . . . . . . . . . . 56 184 5.3.38. Redirect-Address-Type Attribute ( ) . . . . . . . . . 56 185 5.3.39. Redirect-Server-Address Attribute ( ) . . . . . . . . 56 186 5.3.40. Multiple-Services-Indicator Attribute ( ) . . . . . . 56 187 5.3.41. Requested-Action Attribute ( ) . . . . . . . . . . . . 56 188 5.3.42. Service-Context-Id Attribute ( ) . . . . . . . . . . . 56 189 5.3.43. Service-Parameter-Info Attribute ( ) . . . . . . . . . 56 190 5.3.44. Service-Parameter-Type Attribute ( ) . . . . . . . . . 56 191 5.3.45. Service-Parameter-Value Attribute ( ) . . . . . . . . 56 192 5.3.46. Subscription-Id Attribute ( ) . . . . . . . . . . . . 57 193 5.3.47. Subscription-Id-Type Attribute ( ) . . . . . . . . . . 57 194 5.3.48. Subscription-Id-Data Attribute ( ) . . . . . . . . . . 57 195 5.3.49. User-Equipment-Info Attribute ( ) . . . . . . . . . . 57 196 5.3.50. User-Equipment-Info-Type Attribute ( ) . . . . . . . . 57 197 5.3.51. User-Equipment-Info-Value Attribute ( ) . . . . . . . 57 198 6. Security Considerations . . . . . . . . . . . . . . . . . . . 58 199 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 200 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 60 201 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 202 9.1. Normative References . . . . . . . . . . . . . . . . . . . 61 203 9.2. Informative References . . . . . . . . . . . . . . . . . . 61 204 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 62 205 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 62 206 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 65 207 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 69 208 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 209 Intellectual Property and Copyright Statements . . . . . . . . . . 77 211 1. Introduction 213 This draft describes an extension for the RADIUS protocol. This 214 extension enables service providers to charge their "prepaid 215 subscribers". 217 A prepaid subscriber is a user who maintains a prepaid account with 218 the service provider. Every time the prepaid subscriber requests a 219 service, the service provider must ensure that sufficient funds 220 remain in the subsriber's prepaid account before delivering the 221 service. Only if suffiecient funds are available is the service 222 provided to the subscriber. This is in contrast to post-paid 223 subscribers, where this "on-line" account check is not always 224 necessary. In this document, it is assumed that the prepaid 225 subscriber has a contract with the service provider according to 226 which he will receive a particular set of services for a specified 227 period of time, quantity of data, or number of service requests. 229 The business driver behind the extension defined in this document is 230 to increase participation (i.e. a service provider's subscriber base) 231 and thus to increase revenues. In particular, the extensions were 232 designed with the following goals in mind. 234 o Make use of existing infrastructure as much as possible (including 235 the interworking of RADIUS-based and Diameter-based 236 infrastructures), and thereby limit the amount of necessary 237 capital expenditures, 239 o provide the ability to rate service requests in real-time, 241 o provide the ability to charge the user's account prior to service 242 provision, 244 o protect against revenue loss, i.e. to prevent an end user from 245 obtaining service when the available funds do not suffice, 247 o protect against fraud, and 249 o be deployable over dialup, wired and wireless networks. 251 The architecture between the entities that execute the RADIUS 252 protocol, with the extension defined in this document, assumes that 253 the rating of chargeable events does not occur in the element that 254 provides the service. Instead, the rating is performed at a 255 dedicated server, termed the "prepaid-enabled AAA server" or simply 256 "prepaid server". The rating may, of course, occur in an entity 257 behind this prepaid server. However, for the purposes of exposition, 258 in this document it is assumed that that rating occurs in the prepaid 259 server. Furthermore, business logic may dictate a time-dependent 260 tariff model, for example that the price for a service may switch at 261 20:00 from a high to a low tariff. The extensions defined in this 262 document support such scenarios. 264 This documents assumes an architecture where a "quota server" is 265 available which, through co-ordination with the rating entity and a 266 centralized account balance manager, is able to provide a quota 267 indication for a particular user when requested. This quota server 268 may or may not coexist in the prepaid server. 270 1.1. Terminology 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 274 document are to be interpreted as described in [1]. 276 This document also makes use of the following terms: 278 Network Access Server (NAS): 280 As defined in RADIUS [2]. 282 Prepaid client (PPC): 284 The entity which triggers the RADIUS message exchange, including 285 the prepaid extensions defined in this document. The PPC 286 typically resides in the NAS. 288 Prepaid Server (PPS): 290 The entity that interacts with the PPC using the RADIUS prepaid 291 extensions defined in this document. It also provides the 292 functionality of a rating server and a quota server. This is done 293 either by the PPS itself, or in coordination with dedicated 294 backend servers. For simplicity of exposition, this document 295 assumes that the functionality of both the rating and the quota 296 server is provided by the PPS. 298 Home Network: 300 The network which contains the user profile and the user's prepaid 301 account. 303 RADIUS Prepaid (RPP): 305 The RADIUS base protocol together with the extension defined in 306 this document. 308 Diameter Credit Control (DCC): 310 The Diameter Credit Control Application. 312 1.2. Overview 314 This section provides an overview of the prepaid charging models and 315 architectures, which are supported by the extensions described in 316 this draft. 318 A number of models of how to charge customers for data services in a 319 prepaid manner are supported, as follows. 321 o Volume-based charging: (e.g. 2 Cents/KiloByte). 323 o Duration-based charging: (e.g. 3 Cents/minute). 325 o Subscription-based charging: (e.g. Dollars/month). 327 o Event-based charging: (e.g. 7 Cents/URL or email) . 329 This document assumes that the user maintains a prepaid account with 330 his home network. However, whether this account is a dedicated 331 prepaid account or not (such as a current bank account) is outside 332 the scope of this document. Similarly, the means by which the 333 subscriber obtains funds is also outside the scope of this document. 334 In some scenarios, the subscriber's account may be used to fund 335 multiple services, some of which may use the extensions defined in 336 this documents, and some may use other mechanisms. While the 337 interworking of the mechanisms described in this document with other 338 mechanisms should be possible and straightforward, the specification 339 of how this could be done depends on the external mechanisms and is, 340 as such, outside the scope of this document. 342 1.2.1. Architectural Model 344 The protocol extensions described in this document assumes that the 345 following entities are present in the network architecture. 347 o Service Access Device (SAD): This entity provides a data service 348 to the users, and typically coincides with the Network Access 349 Server (NAS), as this is defined in [2]. The SAD executes the 350 RADIUS client which, for the purposes of this document, is termed 351 the "PrePaid Client" (PPC). When the prepaid service is used, the 352 SAD collects service event information and reports it while or 353 after services are provided to the user. This event information 354 is sent to the PPS using the extensions defined in this document. 356 o The PPS: The RADUIS server that supports the prepaid extensions 357 defined in this document. If real-time credit control is 358 required, the PPC (SAD) contacts the PPS with service event 359 information included before the service is provided. The PPS 360 performs a credit check and allocates a portion of available 361 credit to the service event. 363 o The rating and quota server: This server allocates an amount of 364 credit to the user. This credit is converted into an amount of 365 time or volume, called the "quota". This quota is then returned 366 to the requesting PPC (SAD) (via the PPS). The rating entity may 367 also determine that during service provision a tariff switch will 368 occur. In this case, the rating entity also includes information 369 of when exactly this tariff switch occurs into the message that is 370 sent to the PPS. 372 The requesting SAD (PPC) monitors the provision of the service 373 according to the instructions returned by the PPS. After service 374 completion or on a subsequent request for service, the PPS deducts 375 the amount of credit that corresponds to the consumed service from 376 the user account. When a user terminates an on-going service, the 377 PPC informs the PPS with a suitable indication about the unused 378 portion of the allocated quota. The PPS is then able to refund the 379 user account appropriately. 381 Multiple PPSs may be deployed for reasons of redundancy and load 382 balancing. The system MAY also employ multiple rating servers. 383 Prepaid accounts may be located in a centralized database. The 384 detailed architecture of the system and its interfaces are outside 385 the scope of this specification. 387 accounting 388 +------------+ +-----------+ protocol +--------------+ 389 | User |<---------->| Service | | | 390 | | IEEE 802.1x| Access |<------------>| Accounting | 391 | Device | PANA | Device |<-----+ | Server | 392 +------------+ IKEv2 +-----------+ | +--------------+ 393 ... etc (PPC) | 394 | 395 | +--------------+ 396 +------>| Prepaid | 397 prepaid | Server | 398 extension +--------------+ 400 Figure 1: Basic prepaid architecture 402 The PPS and the accounting server in this architecture are logical 403 entities. The real configuration MAY combine them into a single 404 host. The SAD must be able to meter the consumption of resources 405 (e.g. time or volume) for a prepaid data session. 407 The device running the PPC may also have "Dynamic Session 408 Capabilities" such as the ability to terminate a data session or 409 change the filters associated with a specific data session by 410 processing "Disconnect" messages and "Change of Authorization" 411 messages, as specified in RFC 3576. 413 There exist three types of AAA server, as follows. 415 o The AAA server in the home network (HAAA), which is responsible 416 for authentication of the subscriber. In addition, the HAAA 417 communicates with the PPS using the RADIUS protocol in order to 418 authorize subscribers. 420 o The AAA server in the visited network (VAAA) which exists only in 421 roaming scenarios and is responsible for forwarding the RADIUS 422 messages to the HAAA. The VAAA may also modify the messages. 423 Note that, in certain roaming deployments, the visited network may 424 be connected to the home network via one or more broker networks. 426 o The AAA server in one of the aforementioned broker networks 427 (BAAA), which is responsible for forwarding messages and does not 428 play an active role in the prepaid data service delivery. A BAAA 429 obviously exists only in those roaming deployments where the VAAA 430 and the HAAA are connected via the BAAA server of a broker 431 network. 433 This document assumes that the PPS is used as the HAAA server. Of 434 course, in reality, the PPC may communicates with the HAAA for the 435 purposes of authorisation. As mentioned earlier, the PPS is also 436 assumed to 438 o keep the subscriber's account balance (balance manager), 440 o rate access service requests in real-time (rating server), and 442 o manage quota for a particular prepaid service (quota server). 444 Of course, the balance manager, rating server, and quota server may 445 be separate entities that have an interface with the PPC and that act 446 in coordination with the PPC. 448 Three deployment scenarios are presented in the remainder of this 449 section. The first scenario is depicted in Figure 2. In this 450 scenario, the SAD (which runs the PPC), the HAAA, and the PPS are 451 located in the same administrative domain. 453 The subscriber's device establishes a connection with one of possibly 454 multiple SADs in the network. The selected SAD communicates with a 455 HAAA server (directly or indirectly). 457 The interface between the HAAA and the PPS is implemented using the 458 RADIUS protocol together with the extensions described in this 459 document. However, in cases where the PPS does not implement the 460 RADIUS protocol, the implementation would have to map the 461 requirements defined in this document to a functionally equivalent 462 protocol. 464 +------+ +-----+ 465 | | | | 466 +--------+ +--------+ +--| HAAA |--+--| PPS | 467 | | | | | | | | | | 468 | Subscr.| | Service| | +------+ | +-----+ 469 | |---| Access |--+ | 470 | Device | | Device | | +------+ | +-----+ 471 | | | | | | | | | | 472 +--------+ +--------+ +--| HAAA |--+--| PPS | 473 | | | | 474 +------+ +-----+ 476 Figure 2: Basic prepaid access architecture 478 The second scenario, depicted in Figure 3, is based on a static 479 roaming architecture that is typical of a wholesale scenario for 480 dial-up users or a broker scenario used in dial-up or WLAN roaming 481 scenarios. 483 +----+ +----+ +----+ +-----+ 484 | | | | | | | | 485 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 486 | | | | | | | | | | | | | | | | 487 |Sub | |Service| | +----+ | +----+ | +----+ | +-----+ 488 | |--|Access |-+ | | | 489 |Device| |Device | | +----+ | +----+ | +----+ | +-----+ 490 | | | | | | | | | | | | | | | | 491 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 492 | | | | | | | | 493 +----+ +----+ +----+ +-----+ 495 Figure 3: Static roaming prepaid architecture 497 Like in the basic prepaid architecture, the subscriber device 498 establishes a connection with the SAD. The SAD communicates with the 499 VAAA using the RADIUS protocol. The VAAA, in turn, communicates 500 using the RADIUS protocol with BAAA servers in the broker network. 501 There may be more than one Broker Network between the Visited Network 502 and the Home Network. The Home Network is the same as in the 503 architecture depicted in Figure 2. 505 Broker AAA (BAAA) servers MUST support the Message-Authenticator(80) 506 attribute as defined in RFC 2869. If they are used, they forward the 507 RADIUS packets as usual to the appropriate RADIUS servers. 509 Accounting messages are not needed to deliver a prepaid service. 510 However, accounting messages can be used to keep the PPS up to date 511 as to what is happening with the prepaid data session. Therefore, a 512 BAAA SHOULD deliver RADIUS Accounting messages using the pass through 513 mode described in RFC 2866. 515 1.2.2. Motivation 517 Why not use existing RADIUS attributes to construct a protocol for 518 prepaid charging? This could lead to a solution where no code has to 519 be modified at existing devices. 521 It is indeed possible to construct a solution for prepaid charging 522 scenarios using existing RADIUS attributes. The RADIUS server would 523 send an Access-Accept message containing a Session-Timeout(27) and 524 include a Termination-Action(29) in the RADIUS-request. Upon 525 receiving the Access-Accept message, the NAS would meter the duration 526 of the session and upon termination of the session the NAS would 527 generate an Access-Request message again. The RADIUS server would 528 then re-authenticate the session and reply with an Access-Accept 529 message indicating the amount of additional time in a Session- 530 Timeout(27). Alternatively, it could respond with an Access-Reject 531 message if there were no more resources in the user account. 533 Moreover, if the user terminates the session prematurely, the NAS 534 could indicate this in the accounting stream so that unused funds can 535 be returned into the prepaid user account. 537 Unfortunately, the above "solution" has a number of shortcomings, 538 including the following. 540 o It only supports time-based rating. The solution presented in 541 this document supports both time and volume based prepaid. 543 o Using accounting messages to recoup unused time may be problematic 544 because it is not required that RADIUS accounting messages are 545 delivered in real-time. A RADIUS server may store-and-forward 546 accounting messages in batches. Thus, relying on accounting 547 messages for the purposes of prepaid charging may cause revenue 548 leakage. The solution presented in this document does not rely on 549 Accounting packets at all. It uses Access-Request messages, which 550 are required to flow through the network in real-time. 552 o Session-Timeout(27) is not a mandatory attribute. If a prepaid 553 subscriber is being serviced by a NAS that does not adhere to 554 Session-Timeout then that subscriber may use the service for an 555 undetermined period of time. 557 o Termination-Action(29) presents its own issues. Firstly, the 558 support of Termination-Action(29) is not mandatory. Secondly, 559 according to RFC 2865, Termination-Action fires when the provision 560 of the service has completed. However, service should not be 561 terminated when negotiating additional quota, because this should 562 happen in a manner transparent to the subscriber. Due to the fact 563 that Termination-Action occurs when the service is completed, it 564 is unclear whether or not the user experience would be affected if 565 this attribute would be used as a means to request additional 566 quota in a prepaid charging context. The RADIUS server might even 567 allocate a new IP address to the subscriber device after a 568 Termination-Action. Also, the RADIUS server has no way of telling 569 why a given Access-Request message was generated. The RADIUS 570 server might have to wait for the corresponding accounting packet 571 to determine the reason. Finally, re-authenticating the 572 subscriber may take too long. The solution presented in this 573 document allows quota replenishing to occur without affecting user 574 experience. No re-authentication is required and quotas can be 575 negotiated before the available credit actually runs out. 577 o Due to the fact that the standard RADIUS attributes are not 578 mandatory, the correct prepaid operation is really an act of faith 579 on the part of the RADIUS server. If Session-Timeout(27) and/or 580 Termination-Action(29) are not supported, the prepaid subscriber 581 might be able to obtain the service for free. The solution 582 described in this document requires that a prepaid-aware SAD 583 informs the RADIUS server, regardless of whether or not the latter 584 supports the prepaid extensions. The RADIUS server can then 585 determine whether or not service should be granted. For example, 586 if a prepaid subscriber is connected to a NAS that does not 587 support prepaid, the RADIUS server can either instruct the NAS to 588 tunnel the traffic to another entity in the home network (e.g. the 589 Home Agent) that supports prepaid, or to provide only a restricted 590 service. 592 The solution presented in this document requires the support of two 593 mandatory and one optional attribute. Furthermore, it does not 594 require a great amount of additional code at a NAS that already 595 supports time or volume metering. The solution requires that RADIUS 596 entities advertise their prepaid capabilities in an Access-Request 597 and that they generate an Access-Request packet in order to obtain 598 more quota when or before the currently allocated quota is consumed. 599 It also requires the NAS to send an Access-Request when the session 600 terminates in order to refund the subscriber account. 602 1.3. A simple use case 604 This section describes the sequence of events in a simple RADIUS 605 prepaid transaction. 607 1. When an end host attaches to a network (for example, using PPP or 608 PANA), as usual, the NAS (SAD) that is serving the subscriber 609 uses the AAA infrastructure in order to authenticate and 610 authorize the subscriber (if such network accesss authentication 611 is required). 613 2. The SAD sends a RADIUS Access-Request to the AAA server in order 614 to authenticate and authorise the subscriber with respect to the 615 requested service. The Access-Request contains the subscriber's 616 credentials and may contain the prepaid capabilities of the SAD. 617 Prepaid capabilities MUST be included if the SAD supports them. 619 3. The authentication procedure proceeds. This may involve several 620 message exchanges such as in EAP [RFC2284]. Once the subscriber 621 has been successfully authenticated, the home AAA server 622 determines that the subscriber is a prepaid subscriber and 623 requests authorisation from the PPS. The request MUST include 624 the prepaid capabilities of the serving SAD. 626 4. The PPS validates that the subscriber has a prepaid account and 627 that the account is active. It further validates that the SAD 628 has the appropriate prepaid capabilities. If all is in order, 629 the PPS authorises the subscriber to use the network. Otherwise 630 it rejects the request. The decision is sent to the AAA system. 631 The response includes attributes to indicate the allocation of a 632 portion of the subscriber credit. This portion is called the 633 "initial quota" and is expressed in units of time or volume, and 634 may also include an optional threshold value. Note that only a 635 portion of the user's funds is allocated because the user may be 636 engaged in other services that may draw on the same account. For 637 example, the user may be engaged in a data session and a voice 638 session. Although these two services draw from the same account, 639 they form separate parts of the overall system. If the entire 640 quota was allocated to the data session then the user would have 641 no more funds for a voice session. 643 5. The AAA system incorporates the attributes received from the PPS 644 into an Access-Accept message that it sends to the SAD. Note 645 that the AAA system is responsible for authorizing the service 646 whereas the prepaid system is responsible for prepaid 647 authorization. 649 6. Upon receiving the Access-Response, the SAD starts the prepaid 650 data session and meters the session based on time or volume, as 651 indicated in the message. 653 7. Once the consumption of the service approaches as certain point 654 (e.g. as expressed by the threshold), the SAD will request 655 additional quota. Re-authorization for additional quota flows 656 through the AAA system to the PPS. The PPS revalidates the 657 subscriber account and subtracts the previously allocated quota 658 from the current balance. If there is remaining balance, it 659 authorizes the request with an additional quota allotment. 660 Otherwise, the PPS rejects the request. Note that the 661 replenishment of the quota is a re-authorization procedure and 662 does not require the subscriber to authenticate himself again. 664 8. Upon receiving the new quota, the SAD continues to provide the 665 data service until the new threshold is reached. If the request 666 for additional quota cannot be fulfilled then the SAD lets the 667 subscriber use the remaining quota and terminates the session. 668 Alternatively, instead of terminating the session, the SAD may 669 restrict the data session such that the subscriber can only reach 670 a particular web server. This web server may be used to enable 671 the subscriber to replenish his account. This restriction can 672 also be used to allow new subscribers to set up prepaid accounts 673 in the first place. 675 9. If the subscriber terminates the session before the allocated 676 quota is entirely consumed, the credit that corresponds to the 677 portion of the quota that was not consumed, MUST be refunded into 678 his account. 680 Note that the subscriber may have disconnected while the access 681 device is waiting for the initial quota. The entire allocated quota 682 must be refunded to the subscribers account in this case. Also note 683 that the PPS maintains session state for the subscriber. This state 684 includes how much account balance was allocated during the last quota 685 enquiry and how much is left in the account. Therefore, it is 686 required that all messages about the session reach the same (and 687 correct) PPS. 689 For a simple message flow, along the lines of this use case, see 690 Appendix A. 692 2. Supported Features 694 This section describes the features that are supported by the prepaid 695 extensions defined in this draft. 697 2.1. Multiple Concurrent Services 699 Browsing the web, participating in a VoIP conversation, watching 700 streaming video, and downloading a file are examples of services that 701 the user may wish to use. Some operators may want to distinguish 702 between these services in terms of charging. Some services may have 703 to be charged at different rates, and may have to be metered 704 differently. Therefore, the prepaid solution needs to be able to 705 distinguish services, and allocate quota to the services using 706 different unit types (time, volume) and allow for those quotas to be 707 consumed at different rates. 709 +---------+ 710 | Session | 711 +---------+ 712 | 1 713 V N 714 +--------------+ 1 : 1 +-------+ 715 | Service |------>| Quota | 716 | (service-Id) | +-------+ 717 +--------------+ 719 Figure 4: Multiple services within a single session 721 As shown in Figure 4, a single RADIUS prepaid session may be 722 associated with multiple (N) services. Each service is identified by 723 a service identifier (Service-ID). The format of the Service-ID is 724 not in the scope of this document but it could be expressed as an IP 725 flow using the 5-tuple {Source-IP and Port, Destination-IP and Port, 726 protocol type}. Each service is associated with a quota metric. An 727 example message flow that involves multiple such services within a 728 single session is given in the appendix. 730 2.2. Resource Pools 732 When working with multiple services a new problem arises because one 733 service may consume its quota faster than another service. When the 734 user balance is close to exhaustion, a situation could arise where 735 one service is unable to obtain quota while another service has 736 plenty of quota remaining. Unless the quotas can be rebalanced, the 737 SAD would then have to terminate the former service. Moreover, it is 738 likely that each service generates a certain amount of RADIUS prepaid 739 traffic. In an environment with many users and charged services, 740 this amount of traffic may become a considerable overhead that could 741 lead to inefficiency. 743 One method to circumvent the above situation is to use a so-called 744 "resource pool". Resource pools enable the allocation of resources 745 to multiple services of a session by allocating resources to a pool 746 and have services draw their quota from the pool at a rate 747 appropriate to that service. When the quota that has been allocated 748 to the pool is close to exhaustion, the entire pool (rather than 749 individual services) is replenished. 751 +-----------+ 752 | Service-A |-----+ +--------+ 753 +-----------+ | Ma | | 754 +-------->| | 755 | Pool | 756 +-------->| (1) | 757 +-----------+ | Mb | | 758 | Service-B |-----+ +--------+ 759 +-----------+ 761 Figure 5: Resource pool example 763 As shown in Figure 5, Service-A and Service-B are bound to Pool(1). 764 Ma and Mb are the pool multipliers (that are associated with 765 Service-A and Service-B respectively) that determine the rate at 766 which Service-A and Service-B draw from the pool. 768 The pool is initialized by taking the quota allocated to service n 769 and multiplying it by Mn. Therefore, the amount of resources 770 allocated to a pool is given by Poolr = Ma*Qa + Mb*Qb + . . ., where 771 Qn denotes the amount of quota that is allocated to service n. 772 Further, the pool is considered to be empty if 774 Poolr <= Ca*Ma + Cb*Mb + . . ., 776 Figure 6 778 where Ca and Cb are resources consumed by Service-A and Service-B 779 respectively. 781 Note that the resources assigned to the pool are not associated with 782 a metric. That is, Service-A can be rated at $1 per MB and Service-B 783 can rated at $0.10 per minute. In this case, if $5 worth of 784 resources are allocated for service-A to the pool and if Ma = 10, 785 then 50 units would be placed into the pool. If a further $5 are 786 allocated for service-B to the pool, then M=1 and 50 units are 787 deposited into the pool. The pool would then have a total sum of 100 788 units to be shared between the two services. The PPC would then 789 mater the services such that each Mbyte used by Service-A will draw 790 10 units from the pool and each minute used by Service-B will draw 1 791 unit from the pool. 793 2.3. Complex Rating Functions 795 The rating of a service can be quite complex. While some operators 796 follow linear pricing models, others may wish to apply more complex 797 functions. For example, a service provider may wish to rate a 798 service such that the first N MBytes are free, then the next M Mbytes 799 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 800 per MB. Such a function could be implemented by repeated message 801 exchanges with the prepaid system. 803 To avert the need to exchange many messages while still supporting 804 such complex rating functions, the notion of a "Rating Group" is 805 introduced. A Rating Group are typically configured at the SAD. As 806 shown in Figure 7, a Rating Group is associated with one or more 807 services and defines the rate that the services associated with the 808 Rating Group consume an allocated amount of quota. 810 +--------------+ +--------------+ 811 +-----------+ N 1 | | M 1 | Resource Pool| 812 | Service-A +---------->| Rating Group |------>| or | 813 +-----------+ | | | Quota | 814 +--------------+ +--------------+ 816 Figure 7: Example of a rating group 818 During the usage of a service that is associated with a Rating Group, 819 the PPC sends the ID of the Rating Group to the PPS. The PPS 820 authorises the Rating Group by allocating a quota to it and 821 optionally assigning it to a Resource Pool. When an additional 822 service that belongs to an already authorised Rating Group is 823 instantiated, the PPC does not need to authorize this service. This 824 effectively means that the PPC meters the service such that it draws 825 from the already allocated quota. Therefore, no RADIUS messages need 826 to be exchanged in this case. This limits the amount of traffic 827 between the PPC and the PPS. An example of a flow that uses Rating 828 Groups is given in Appendix A.3 830 2.4. One-time Charging 832 One-time charging is a mode of operation of where the RADIUS prepaid 833 extensions are used for charging of a service that is provided 834 instansteneously, i.e. without an ongoing session. An example of 835 such an event is the purchase of a ring-tone. Subscription based 836 services can also be modeled as a one-time event. In this case the 837 one-time service event is the purchase of a subscription. 839 For a given user, one-time-based charging may occur in parallel with 840 other charging models. For example, the subscriber may access a 841 website which is metered (based on time or volume) while he also 842 purchases the right to use a ring tone (a one-time-based event). 843 Note: it is up to the service providers to decide whether or not the 844 user will be charged for the download of the tone and also be charged 845 for the time and volume required to download the ring-tone. The 846 facilities provided by this document gives the service provider the 847 ability to achieve their service charging business goals. For 848 example, should the service provider choose not to charge for the 849 download volume or time, then they can treat the download IP flow as 850 a separate service that is not subject to charging. 852 The SAD signals one-time-based charging to the PPS with an indication 853 that identifies the service and the units that should be debited from 854 the user account. 856 A SAD may decide to perform one-time-based charging for an event that 857 was triggered by an unauthenticated user. In this case case the SAD 858 will have to authenticate the user before sending the relevant 859 message to the user's home AAA server. 861 Note that one-time-based charging can also be used to credit the 862 prepaid account. For example, the SAD can return resources to the 863 subscriber by issuing a one-time charge request that includes the 864 amount of resources to be credited into the account. 866 2.5. Tariff Switching 868 The PPC and the PPS may support tariff switching. For example, as 869 shown in Figure 8, traffic before 18:00 may be rated at rate r1 and 870 traffic after 18:00 is rated at rate r2. The PPC reports two 871 indications about the consumed quota: one before and one after the 872 tariff switch occurred. 874 18:00 875 ------------------+----------------- 876 r1 | r2 877 ------------------+----------------- 878 ^ ^ 879 |<----TSI---> | 880 | | 881 Access-Accept Access-Request 882 (quota allocated) (quota consumed) 884 Figure 8: Example of tariff switching 886 The PPC it indicates support for tariff switching by setting the 887 appropriate bit in the PPAC. If the PPS needs to signal a tariff 888 switch time it will send a PTS attribute which indicates the point in 889 time when the switch will occur. This indication represents the 890 number of seconds from current time (TarrifSwitchInterval TSI). 892 At some point after the tariff switch the PPC sends another Access- 893 Request, as a result of either the user having logged off or the 894 volume threshold being reached. The PPC reports how much volume was 895 used using the PPAQ in total and how much volume was used after the 896 tariff switch using the PTS VUATS subtype. 898 In situations with multiple tariff switches, the PPS must specify the 899 length of the tariff switch period using the 900 TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute as 901 shown below. 903 18:00 23:30 904 ------------------+---------------------+-------------- 905 r1 | r2 | r3 906 ------------------+---------------------+-------------- 907 ^ ^ ^ 908 |<----TSI---><-----------|-------->|TITSU 909 | | 910 Access-Accept Access-Request 912 Figure 9: Multiple tariff switches 914 When a TITSU is specified in the PTS, the PPC MUST generate an 915 Access-Request within the time after TSI and before TITSU expires. 916 Note that, typically, the PPC will be triggered by the Volume 917 Threshold. However, it is possible that, during period r2, resources 918 are not entirely consumed and, thus, the threshold is not reached. 919 Even in this case PPC MUST generate an Access-Request in good time. 920 Also note that separate services flows may have individual tariff 921 periods. 923 Note that it makes no sense to use this tariff switching mechanism 924 for services that are charged based on time, and that are consumed 925 continuously (i.e. without interruption). This is because the PPS 926 can rate these services without the help of the PPC, i.e. it can 927 calculate how much of the service was consumed in each tariff period 928 based on its local clock. 930 2.6. Support for Roaming 932 In certain networks it is essential for prepaid data services to be 933 available to roaming subscribers. Support for both static and 934 dynamic roaming models is needed. In a static roaming scenario the 935 subscriber connects to a foreign network which has a roaming 936 agreement either directly with the home network, or through a broker 937 network. When the subscriber logs into another foreign network, a 938 new login procedure has to be executed. 940 In a dynamic roaming scenario the subscriber may move between 941 networks while maintaining his connection. In such a scenario the 942 data session is seamlessly handed off between the networks. 944 In both roaming scenarios, the subscriber always authenticates 945 himself to the home network. Authorization for the prepaid session 946 and quota replenishing occurs at the home network and more 947 specifically at the PPS where state is being maintained. 949 Dynamic roaming is challenging because a subscriber who established a 950 prepaid data session may move to another Access Device that does not 951 support the prepaid extensions. Even in this case the system should 952 be able to continue the prepaid session. 954 2.7. Dynamic Termination 956 When fraud or an error is detected, either only the affected session, 957 or all sessions of the affected subscriber should be immediately 958 terminated. It may further happen that the prepaid system enters a 959 state where it is unclear whether or not the data session is in 960 progress. Under certain conditions, the system may wish to terminate 961 the session in order to ensure that the user is not charged for this 962 potential inactivity. 964 Certain handoff procedures used in dynamic roaming scenarios require 965 that the system terminates the subscribers prepaid data session at a 966 SAD. This is the case, for example, when time-based prepaid is used 967 and the mobile subscriber performs a dormant handoff. 969 2.8. Querying and Rebalancing 971 It should be possible for the PPS to query the current resource 972 consumption at a SAD and adjust the user account balance. For 973 example, a request to the PPS is made (e.g. a one-time charging 974 event), the account is depleted and resources have been allocated to 975 the SAD. The PPS should have the ability to query the SAD and if it 976 has the spare resources to reassign the quotas to the SAD and to the 977 pending request. Note that the PPS does not know resource usage 978 until the SAD request for more resources. This can be a long time. 980 In the absence of this capability the PPS can minimize the effect of 981 this phenomenon by allocating small quotas, a practice that results 982 in more message exchanges. 984 3. Operations 986 This section describes the operations that are implemented by a 987 prepaid-enabled NAS (SAD). 989 3.1. Authentication and Authorization Operation 991 The SAD initiates the authentication and authorization procedure by 992 sending a RADIUS Access-Request to the HAAA. Since the SAD has PPC 993 capabilities, it MUST include a PPAC attribute in the RADIUS Access- 994 Request. The PPAC attribute indicates to the PPS which prepaid 995 capabilities are possessed by the SAD. These are required in order 996 to complete the prepaid authorization procedure. Moreover, if the 997 SAD supports the Disconnect-Message or the Change-of-Authorization 998 capabilities, then it SHOULD include the Dynamic-Capabilities 999 attribute. 1001 In certain deployments, there may be other ways to terminate a data 1002 session, or change authorization of an active session. For example, 1003 some SADs provide a session termination service via Telnet or SNMP. 1004 In these cases, the AAA server MAY add the Dynamic-Capabilities 1005 message to the Access-Request. Upon receiving the Change-of- 1006 Authorization message, the AAA server would then be responsible for 1007 terminating the session using the means that are supported by the 1008 device. 1010 If the authentication procedure involves multiple message exchanges 1011 (as in EAP), the SAD MUST include the PPAC(TBD) attribute and the 1012 Dynamic-Capabilities attribute (if used) in at least the last Access- 1013 Request of the authentication procedure. 1015 The Access-Request is sent as usual to the HAAA, possibly through one 1016 or more BAAA. 1018 Once the Access-Request arrives at the HAAA, the HAAA authenticates 1019 the subscriber. If this fails, the HAAA sends an Access-Reject 1020 message to the client. If authentication succeeds, the HAAA 1021 determines whether or not the subscriber is a prepaid subscriber. 1022 (How this is done is beyond the scope of this document.) If the 1023 subscriber is not a prepaid subscriber, then the HAAA responds as 1024 usual with an Access-Accept or an Access-Reject message. If the 1025 subscriber is a prepaid subscriber then the HAAA SHALL forward the 1026 Access-Request to the PPS for further authorization. 1028 The Access-Request contains the PPAC(TBD) attribute and the Dynamic- 1029 Capabilities attribute if one was included. The User-Name(1) 1030 attribute MAY be set to a value that identifies the subscriber. This 1031 attribute is used by the PPS to locate his account. For added 1032 security, the HAAA MAY also set the User-Password(2) attribute to the 1033 password used between the HAAA and the PPS. 1035 The PPS locates the subscriber account and authorizes him. During 1036 this procedure, the PPS takes into consideration the SAD PPC 1037 Capabilities. Upon successful authorization, the PPS generates an 1038 Access-Accept containing an PPAC attribute and an PPAQ attribute. 1039 The PPAC attribute returned to the client indicates the type of 1040 prepaid service to be provided for the session. The PPAQ attribute 1041 includes the following information. 1043 o The QUOTA-ID, which is set by the PPS to a unique value that is 1044 used to correlate subsequent quota requests. 1046 o Volume and/or Time quota, which is set to a value representing a 1047 portion of the subscriber's credit. 1049 o It MAY contain a Time or Volume Threshold that indicates when the 1050 SAD should request additional quota. 1052 o The IP address of the Serving PPS and one or more alternative 1053 PPSs. This is used by the HAAA to route subsequent quota 1054 replenishing messages to the appropriate PPS(s). 1056 Note: The Idle-Timeout(28) attribute can be used to trigger the 1057 premature termination of a prepaid service, for example as a result 1058 of inactivity. 1060 Depending on site policies, after failed authorization, the PPS may 1061 generate an Access-Reject in order to terminate the session 1062 immediately. Alternatively, the PPS may generate an Access-Accept 1063 blocking some or all of the traffic and/or redirect some or all of 1064 the traffic to a location to a fixed server. (This feature could be 1065 used, for example, to prompt the user to replenish their account.) 1066 Blocking of traffic is achieved by either Filter-ID(11) or NAS- 1067 Filter-Rule(see Redirect I-d). Redirection is achieved by sending 1068 Redirect-Id or Redirect-Rule, HTTP Redirection defined in the 1069 Redirect I-d. The time period before the session is blocked/ 1070 redirected is specified by the Session-Timeout(27) attribute. 1072 Upon receiving an Access-Accept from the PPS, the HAAA appends the 1073 usual service attributes and forward the packet to the SAD. The HAAA 1074 SHOULD NOT overwrite any attributes already set by the PPS. If the 1075 HAAA receives an Access-Reject message, it will simply forward the 1076 packet to its client. Depending on site policies, if the HAAA does 1077 not receive an Access-Accept or an Access-Reject message from the PPS 1078 it MAY do nothing or send an Access-Reject or an Access- Accept 1079 message back to the PPC. 1081 3.2. Session Start Operation 1083 A session is deemed to be 'active' at the home AAA server once the 1084 authentication process has been successfully completed. The arrival 1085 of an Access Request at the PPS means that authentication has 1086 successfully completed because otherwise the home AAA server would 1087 not forward it to the PPS. A session being active, however, does not 1088 necessarily mean that the user has actually started using the 1089 service. 1091 The PPS may deduce that the user has actually consumed some service 1092 (i.e. consumed some of the allocated quota) by either the reception 1093 of an Accounting-Request(Start) packet, or the reception of an Access 1094 Request message that asks for quota replenishment. The Accounting- 1095 Request (Start) MAY be routed to the PPS such that it can confirm 1096 that the user has started consuming the initial quota. Note, 1097 however, that the role of the PPS is not to record accounting 1098 messages and therefore it SHOULD NOT respond with an Accounting 1099 Response packet. 1101 If the PPS does not receive any of the above two indications that the 1102 user has started consuming the service, it SHOULD, after some 1103 configurable time, terminate the session. If the SAD supports 1104 termination capabilities, the PPS SHOULD send a Disconnect Message to 1105 the SAD as a measure to ensure that the session is indeed dead. 1107 3.3. Mid-Session Operation 1109 During the lifetime of a prepaid data session the SAD may request the 1110 replenishment of the quotas using a 'mid-session' prepaid-specific 1111 Access-Request message. Such a message MUST include NAS identifiers, 1112 a Session identifier attribute, and at least one PPAQ attribute. The 1113 home AAA server or the PPS that receives such a message classifies it 1114 as 'mid-session' if it refers to an active session, i.e. the NAS 1115 identifier, session identifier, and possibly other AVPs match those 1116 of an active session. Which exactly AVPs are required to match in 1117 order to map a message to a session depends on the deployment 1118 scenario and applicable policies. Certain AVPs are also used to 1119 route the message through proxies. For example, if the User-Name(1) 1120 attribute was used in the initial Access-Request, it MUST be included 1121 any subsequent Access-Requests, especially if the User-Name(1) 1122 attribute is used to route the Access-Request to the Home AAA server. 1124 The mid-session Access-Request MUST NOT include a User Password and 1125 MUST NOT include a Chap Password. In order to enable the receiver to 1126 authenticate the message, the SAD MUST include a Message- 1127 Authenticator(80) attribute. The SAD computes the value for the 1128 Message-Authenticator according to RFC 2869. 1130 When the HAAA receives an Access-Request that contains a PPAQ(TBD), 1131 it SHALL validate the message using the Message-Authenticator(80), 1132 according to RFC 2869. If the HAAA receives an Access-Request that 1133 contains a PPAQ(TBD) and either no or an invalid Message- 1134 Authenticator(80) it SHALL silently discard the message. A mid- 1135 session Access-Request message that does not contain a PPAQ(TBD) is 1136 either erroneous or belongs to another application (for example, a 1137 Change of Authorization message [RFC3576]). In this case the Access- 1138 Request message is either silently discarded or handled by another 1139 application. 1141 Once the mid-session Access-Request message is validated, the HAAA 1142 SHALL forward it to the appropriate PPS. The HAAA MUST forward the 1143 Access-Request to the PPS specified in the PPAQ(TBD). The HAAA MUST 1144 add a Message-Authenticator(80) to the message, according to RFC 1145 2869. As with the initial Access-Request message, the HAAA MAY 1146 modify the User-Name(1) attribute such that it identifies the user to 1147 the PPS. Note that the PPS may also use the Quota-ID sub-attribute 1148 contained within the PPAQ(TBD) to locate the user account. 1150 Upon receiving an Access-Request containing a PPAQ(TBD) attribute, 1151 the PPS MUST validate the Message-Authenticator(80) as described in 1152 RFC 2869. If validation fails, the PPS MUST silently discard the 1153 message. If it receives a mid-session Access-Request message that 1154 does not contain a PPAQ(TBD), it MUST silently discard the message. 1156 The PPS locates the prepaid session state using the Quota Id 1157 contained within the PPAQ(TBD). The PPS takes the most recently 1158 allocated quota and subtracts it from the user balance. If 1159 sufficient balance remains, the PPS authorizes the PPS and allocates 1160 additional quota. The PPS may also calculate a new threshold value. 1161 Upon successful re-authorization, the PPS generates an Access-Accept 1162 containing the PPAQ(TBD) attribute. The Access-Accept message MAY 1163 contain a Message-Authenticator(80). 1165 Depending on site policies, upon unsuccessful authorization, the PPS 1166 generates an Access-Reject or an Access-Accept with Filter-Id(11) or 1167 Ascend-Data-Filter (if supported) attribute and the Session- 1168 Timeout(27) attribute such that the subscriber can get access to a 1169 restricted set of locations for a short period of time. This feature 1170 could be used to enable users to replenish their accounts, create new 1171 accounts, or to browse free content. 1173 Upon receiving the Access-Accept from the PPS, the HAAA SHALL return 1174 the packet to its client. If the HAAA receives an Access-Reject 1175 message, it forwards the packet. Depending on site policies, if the 1176 HAAA does not receive an Access-Accept or an Access-Reject message 1177 from the PPS it MAY do nothing or it MAY send an Access-Reject 1178 message back to its client. 1180 Upon receiving an Access-Accept, the SAD SHALL update its quotas and 1181 threshold parameters with the values contained in the PPAQ(TBD) 1182 attribute. Note that the PPS MAY update the PrePaidServer 1183 attribute(s) and these may have to be saved as well. If the Access- 1184 Accept message contains a Filter-Id(11), an Ascend-Data-Filter 1185 attribute, or Session Timeout(27), the SAD SHALL restrict the 1186 subscriber session accordingly. 1188 3.4. Dynamic Operations 1190 The PPS may take advantage of the dynamic capabilities that are 1191 supported by the SAD as advertised in the Dynamic-Capabilities 1192 attribute during the initial Access-Request. There are two types of 1193 action that the PPS may perform. Firstly, it may request the session 1194 to be terminated. Secondly, it may request the attributes associated 1195 with the session to be modified. More specifically, it may modify a 1196 previously sent PPAQ(TBD). 1198 Both of these actions require that the session be uniquely identified 1199 at the SAD. As a minimum, the PPS MUST provide 1201 1. either the NAS-IP-Address(4) or the NAS-Identifier(32), and 1203 2. at least one session identifier such as User-Name(1), Framed-IP- 1204 Address(), the Accounting-Session-Id(44). 1206 Other attributes could also be used to uniquely identify a prepaid 1207 data session. 1209 3.4.1. Unsolicited Session Termination Operation 1211 At anytime during a session the PPS may send a Disconnect Message in 1212 order to terminate a session. This capability is described in detail 1213 in [RFC3576]. The PPS sends a Disconnect Message that MUST contain 1214 identifiers that uniquely identify the data session and the SAD 1215 servicing that session. 1217 If the SAD receives a Disconnect-Message, it responds with either a 1218 Disconnect-ACK message (if it is able to terminate the session) or 1219 with a Disconnect-NAK packet (otherwise). Upon successful 1220 termination of a session, the SAD MUST return any unused quota to the 1221 PPS by issuing an Access-Request containing a PPAQ attribute which 1222 contains any unused Quota and the Update-Reason set to "Remote Forced 1223 Disconnection". 1225 3.4.2. Unsolicited Change of Authorization Operation 1227 At any time during the session the PPC may receive a Change of 1228 Authorization (CoA) message. A PPS may send a new Quota to either 1229 add or to remove quota that is allocated to the service. If the 1230 Change of Authorization contains a PPAQ then that PPAQ overrides a 1231 previously received PPAQ. The PPS MUST NOT change the units used in 1232 the PPAQ. 1234 If the newly received PPAQ reduces the amount of allocated quota 1235 beyond what is already used then the SAD accepts the new PPAQ and act 1236 as it normally would when the quota is used up. For example, if the 1237 threshold is reached then is request a quota update . 1239 3.5. Termination Operation 1241 The termination phase is initiated when (i) the subscriber logs off, 1242 (ii) the subscriber balance is exhausted, or (iii) when the SAD 1243 receives a Disconnect Message. 1245 In case the user logged off, or the SAD receives a Disconnect 1246 Message, the SAD sends an Access-Request message with a PPAQ and 1247 Update-Reason attribute set to either "Client Service Termination" or 1248 "Remote Forced Disconnect". This message indicates the amount of 1249 consumed quota. 1251 In case the currently allocated quota is exhausted, if the PPAQ 1252 contained the Termination-Action field, the SAD follows the specified 1253 action (which would be to immediately terminate the service, request 1254 more quota, or redirect/filter the service). 1256 3.6. Mobile IP Operations 1258 In roaming scenarios with Mobile IP, the prepaid data session should 1259 be maintained transparently if the HA is acting as the SAD. As the 1260 subscriber device associates with a new SAD (AP or PDSN that supports 1261 PPC capability), the SAD sends a RADIUS Access-Request and the 1262 subscriber is re-authenticated and reauthorized. The SAD MUST 1263 include the PPAC attribute in the RADIUS Access-Request. In this 1264 manner, the procedure follows the Authentication and Authorization 1265 procedure described earlier. 1267 If the HA was acting as the SAD before handoff, the prepaid session 1268 does not undergo any change after the handoff because the Mobile IP 1269 session is anchored at the HA and the user's Home IP address does not 1270 change. 1272 In the case of a wireless access point or PDSN acting as the SAD, it 1273 is likely that the user's (care-of) IP address will change. The 1274 prepaid session will be affected by this. In this scenario the SAD 1275 shall send an Access-Request message which is routed to the home 1276 network and MUST reach the PPS that is serving this session. The PPS 1277 correlates the new authorization request with the existing active 1278 session and assigns a quota to the new request. Any outstanding 1279 quota at the old SAD MUST be returned to the PPS if the Mobile IP 1280 nodes (HA and FA) support registration revocation (Mobile IPv4 only). 1281 Specifically, the quota SHOULD be returned when the SAD sends an 1282 Access-Request with PPAQ Update-Reason set to either "Remote Forced 1283 Disconnect" or "Client Service Termination". In order to trigger the 1284 sending of this last Access-Request, the PPS may issue a Disconnect 1285 Message [3576] to the SAD. 1287 Even if the subscriber moves to a SAD that does not have prepaid 1288 capabilities the prepaid data service can continue. This can be done 1289 by requesting the Home Agent (assuming it has such capabilities) to 1290 take over the responsibilities of the SAD (i.e. metering). This 1291 scenario will be discussed in detail in a later version of this 1292 document. 1294 3.7. Operation Considerations for Multiple Services 1296 This section describes the support for multiple prepaid services on a 1297 single SAD. Message flows illustrating the various interactions are 1298 presented in Appendix A. 1300 A SAD that supports prepaid operations for multi-services SHOULD set 1301 the "Multi-Services Supported" bit in the PPAC. When working with 1302 multiple services, it is necessary to differentiate these services. 1303 A Service-Id attribute is used in the PPAQ for this purpose. The 1304 exact definition of the Service-Id attribute is outside the scope of 1305 this document. 1307 A PPAQ AVP that contains a Service-Id is associated with that 1308 Service. A PPAQ AVP that contains a Rating-Group-Id is associated 1309 with that Rating-Group. A PPAQ MUST not contain both a 1310 Rating-Group-Id and a Service-Id. A PPAQ that contains neither a 1311 Rating-Group-Id nor a Service-Id applies to the Access Service. 1313 3.7.1. Initial Quota Request 1315 When operations with multi-services is desired, the SAD requests the 1316 initial quota for the Service by sending a PPAQ containing the 1317 Service-Id for that Service in an Access-Request packet. Similarly, 1318 if the SAD supports Rating-Groups then it may request a quota for the 1319 Rating-Group by sending a PPAQ containing the Rating-Group-Id. In 1320 both cases the Update-Reason is set to "Initial-Request". 1322 The Access-Request message may contain more than one PPAQ, and MUST 1323 include one or more attributes that serve to identify the session so 1324 that it can be linked to the original authentication. Which Session 1325 Identifiers are included is up to specific deployments. The message 1326 must contain the Message-Authenticator(80) attribute for integrity 1327 protection. 1329 Upon receiving an Access-Accept message containing one or more PPAQs, 1330 the PPS allocates resources to each PPAQ. Each PPAQ is assigned a 1331 unique QID that MUST appear in subsequent PPAQ updates for that 1332 service or rating-group. Additionally, the PPAQ MUST contain the 1333 Service-ID or Group-ID, unless the PPAQ is the generic "Access 1334 Service". 1336 3.7.2. Quota Update 1338 Once the services start to utilize their allotted quota they will 1339 eventually need to replenish their quotas (either the threshold is 1340 reached or no more quota remains). In order to replenish the quota, 1341 the PPC sends an Access-Request message containing one or more PPAQs. 1342 Each PPAQ MUST contain the appropriate QID, Service-ID or Group-ID 1343 (or neither the Service-ID or Group-Id if the quota replenishment is 1344 for the "Access Service"). The Update-Reason filed indicates either 1345 "Threshold reached"(3), or "Quota reached"(4). The message must 1346 contain session identifiers. 1348 Upon receiving an Access-Request packet with one or more PPAQs the 1349 PPS responds with a new PPAQ for that service. The PPAQ contains a 1350 new QID, the Service-Id or Rating-Group-Id, a new Quota. If the PPS 1351 does not grant additional quota to the service it MUST include the 1352 Termination-Action subfield in the PPAQ that will instruct the SAD 1353 what to do with the service. 1355 3.7.3. Termination 1357 When the allotted quota for a service is exhausted, the SAD shall act 1358 in accordance to the Termination-Action field set in the Quota. If 1359 the Termination-Action field is absent then the service MUST be 1360 terminated. If the service is to be terminated, then the SAD shall 1361 send a PPAQ with the appropriate QID, the Service-Id, the used quota, 1362 and the Update-Reason set to "Client Service Termination". 1364 If the �Access Service� has terminated, then all other 1365 services must be terminated as well. In this case the SAD MUST 1366 report on all issued quotas for the various services. The Update- 1367 Reason field should be set to "Access Service Terminated". 1369 3.7.4. Dynamic Operations 1371 Dynamic operations for multi-services are similar to dynamic 1372 operations described for single service operations. The prepaid 1373 system may send a COA message containing a PPAQ for an existing 1374 service instance. The SAD matches the PPAQ with the service using 1375 the Service-ID attribute. The new quota could differ from the 1376 previously allocated value. The SAD must react to the new value 1377 accordingly. 1379 A disconnect message terminates the "Access Service". As such the 1380 SAD MUST report all unused quotas by sending an Access Request 1381 message containing a PPAQ for each active service. The Update-Reason 1382 shall indicate that the reason for the update. 1384 3.7.5. Support for Resource Pools 1386 If the PPC supports pools as indicated by setting the "Pools 1387 supported" bit in the PPAC(TBD) then the PPS may associate a Quota 1388 with a Pool by including the Pool-Id and the Pool-Multiplier in the 1389 PPAQ(TBD). When Resource Pools are used, the PPAQ must not use the 1390 threshold field. 1392 3.7.6. One-time Charging 1394 To initiate a One-Time charge the PPC includes the PPAQ attribute in 1395 an Access-Request packet. The Access Request packet MUST include a 1396 Message-Authenticator(80) and an Event-Timestamp(55) attribute. The 1397 Service Id field of the PPAQ identifies the prepaid service. The 1398 amount to be charged is specified using the Resource Quota and 1399 Resource Quota overflow subtypes. If the value specified is negative 1400 then the resources are credited to the user account. 1402 The QID field MUST be set to a unique value and is used by the PPS to 1403 detect duplicates. The Update Reason field MUST be set to One-Time 1404 Charging. Upon receiving a One-Time charge PPAQ, the RADIUS server 1405 authenticates the user and, if successful, passes the PPAQ to the 1406 PPS. The PPS locates the account and debits or credits it 1407 accordingly. The PPS MUST respond to the PPS with an Access-Accept 1408 message if successful, or an Access-Reject message otherwise. 1410 The RADIUS server shall respond to the SAD with an Access Accept 1411 message. Since this is a one-time charge the SAD must not allow the 1412 session to continue. Therefore, the RADIUS server should include in 1413 the Access-Accept a Session-Timeout set to 0. Upon receiving an 1414 Access-Accept response the SAD shall generate an Accounting Stop 1415 message. 1417 A PPAQ used for One-Time charging may appear in an Access Request. 1418 This is the case when the session already exists. The PPS responds 1419 with an Access-Accept to indicate that the user account has been 1420 debited or an Access-Reject otherwise. 1422 3.7.7. Error Handling 1424 If the PPS receives a PPAQ with an invalid QID it MUST ignore that 1425 PPAQ. 1427 If the PPS receives a PPAQ containing a Service-Id, or a Rating- 1428 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1430 If the PPC receives a PPAQ containing a Service-Id, or a Rating- 1431 Group-Id that it does not recognize, then it must ignore that PPAQ. 1433 If the PPC receives a PPAQ that contains a Pool-Id without a Pool- 1434 Multiplier or a Pool-Multiplier without a Pool-Id it must ignore that 1435 PPAQ. 1437 3.7.8. Accounting Considerations 1439 Although typically generated, accounting messages are not required to 1440 deliver a prepaid data service. When generated, accounting messages 1441 are used for auditing purposes and for billing. Accounting messages 1442 associated with prepaid data sessions should include the PPAQ(TBD) 1443 attribute. 1445 3.7.9. Interoperability with Diameter Credit Control Application 1447 The RADIUS prepaid extensions need to interoperate with the Diameter 1448 protocol. Two interoperability scenarios exist, as follows. Either 1449 the AAA infrastructure is Diameter based and the SAD are RADIUS 1450 based, or the SAD is Diameter based and the AAA infrastructure is 1451 RADIUS based. 1453 The Diameter Credit Control Application [DIAMETERCC] describes how to 1454 implement a prepaid accounting system using a Diameter based 1455 infrastructure. 1457 4. Attributes 1459 This section specifies the attributes that implement the RADIUS 1460 extensions for prepaid. The namespace for these attributes is the 1461 one specified in the RADIUS base protocol [RFC2865]. 1463 4.1. PPAC Attribute 1465 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1466 Access-Request message by a prepaid capable NAS and is used to 1467 describe the prepaid capabilities of the NAS. The PPAC is also 1468 present in an Access-Accept message by the PPS in order to indicate 1469 the type of metering that is to be applied to this session. 1471 0 1 2 3 1472 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | TYPE | LENGTH | SUBtype 1 | LENGTH | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | AvailableInClient (AiC) | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 TYPE : value of PPAC 1480 LENGTH: 8 1481 VALUE : String 1483 The value MUST be encoded as follows: 1485 Subtype (=1) : Subtype for AvailableInClient attribute 1486 Length : Length of AvailableInClient attribute 1487 (= 6 octets) 1488 AvailableInClient (AiC): 1490 The optional AvailableInClient Subtype, generated by the PPC, 1491 indicates the metering capabilities of the NAS and shall be bitmap 1492 encoded. The possible values are as follows. 1494 0x00000001 Volume metering supported. 1495 0x00000002 Duration metering supported. 1496 0x00000004 Resource metering supported. 1497 0x00000008 Pools supported 1498 0x00000010 Rating groups supported 1499 0x00000020 Multi-Services supported. 1500 0x00000040 Tariff Switch supported. 1502 Others Reserved 1504 Figure 10: PPAC Attribute 1506 4.2. Session Termination Attribute 1508 The value shall be bitmap encoded rather than a raw integer. This 1509 attribute shall be included RADIUS Access-Request message to the 1510 RADIUS server and indicates whether or not the NAS supports Dynamic 1511 Authorization. 1513 0 1 2 3 1514 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | TYPE | LENGTH | String | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 Type : value of Session Termination Capability 1520 Length: = 4 1521 String encoded as follows: 1523 0x00000001 Dynamic Authorization Extensions (rfc3576) is 1524 supported. 1526 Figure 11: Session Termination Attribute 1528 4.3. PPAQ Attribute 1530 One or more PPAQ attributes are sent in an Access Request, Access- 1531 Request and Access-Accept message. In an Access Request message, the 1532 PPAQ attribute is used to facilitate One-Time charging transactions. 1533 In Access-Request messages it is used for One-Time charging, report 1534 usage and the request for further quota. It is also used in order to 1535 request prepaid quota for a new service instance. In an Access- 1536 Accept message it is used in order to allocate the (initial and 1537 subsequent) quotas. 1539 When multiple services are supported, a PPAQ is associated with a 1540 specific service as indicated by the presence of a Service-Id, a 1541 Rating-Group-Id, or the "Access Service" (as indicated by the absence 1542 of a Service-Id and a Rating-Group-Id). 1544 The attribute has type TBD (one octet), a variable length (greater 1545 than 8, encoded into one octet), and consists of a variable number of 1546 subtypes. Unused subtypes are omitted from the message. In the 1547 following subsections the various subtypes of the PPAQ attribute are 1548 specified. 1550 4.3.1. Quota Identifier AVP 1552 The type of the QuotaIDentifier attribute is TBD and its length is 6 1553 octets. This AVP is generated by the PPS together with the 1554 allocation of new quota. The on-line quota update RADIUS Access- 1555 Request message that is sent from the SAD to the PPS shall include a 1556 previously received QuotaIdentifier. 1558 4.3.2. VolumeQuota AVP 1560 The type of the VolumeQuota attribute is TBD and its length is 12 or 1561 18 octets. This AVP is only present if volume-based charging is 1562 used. In a RADIUS Access-Accept message (PPS to SAD direction), it 1563 indicates the volume (in octets) allocated for the session by the 1564 PPS. In an RADIUS Access-Request message (SAD to PPS direction), it 1565 indicates the total used volume (in octets) for both inbound and 1566 outbound traffic. The attribute consists of a Value-Digits AVP and 1567 optionally an Exponent AVP (as indicated in the length field). The 1568 Exponent AVP, if present, MUST NOT encode a negative number or zero. 1570 4.3.3. VolumeThreshold AVP 1572 The type of the VolumeThreshold attribute is TBD and its length is 12 1573 or 18 octets. This AVP shall optionally be present if VolumeQuota is 1574 present in a RADIUS Access-Accept message (PPS to SAD direction). It 1575 is generated by the PPS and indicates the volume (in octets) that 1576 shall be consumed before a new quota should be requested. This 1577 threshold should not be larger than the VolumeQuota. The attribute 1578 consists of a Value-Digits AVP and optionally an Exponent AVP (as 1579 indicated by the length field). The Exponent AVP, if present, MUST 1580 NOT encode a negative number or zero. 1582 4.3.4. DurationQuota AVP 1584 The type of the DurationQuota attribute is TBD and its length is 6 1585 octets. This optional AVP is only present if duration-based charging 1586 is used. In RADIUS Access-Accept message (PPS to SAD direction), it 1587 indicates the duration (in seconds) allocated for the session by the 1588 PPS. It is encoded as an 32 bit unsigned value, in network byte 1589 order. In an on-line RADIUS Access-Accept message (PPC to PPS 1590 direction), it indicates the total duration (in seconds) since the 1591 start of the accounting session related to the QuotaID of the PPAQ 1592 AVP in which it occurs. 1594 4.3.5. DurationThreshold AVP 1596 The type of the DurationThreshold attribute is TBD and its length is 1597 6 octets. This AVP shall optionally be present if DurationQuota is 1598 present in a RADIUS Access-Accept message (PPS to PPC direction). It 1599 represents the duration (in seconds) after which new quota should be 1600 requested. This threshold should not be larger than the 1601 DurationQuota. It is encoded as a 32 bit unsigned value, in network 1602 byte order. 1604 4.3.6. ResourceQuota AVP 1606 The type of the ResourceQuota attribute is TBD and its length is 12 1607 or 18 octets. This optional AVP is only present if resource-based or 1608 one-time charging is used. In the RADIUS Access-Accept message (PPS 1609 to SAD direction) it indicates the resources allocated for the 1610 session by the PPS. In a RADIUS Access-Request message (SAD to PPS 1611 direction), it indicates the resources used in total, including both 1612 incoming and outgoing chargeable traffic. In one-time charging 1613 scenarios, the subtype represents the number of units to charge or 1614 credit the user. The attribute consists of a Value-Digits AVP and 1615 optionally an Exponent AVP (as indicated by the length field). 1617 4.3.7. ResourceThreshold AVP 1619 The type of the ResourceThreshold AVP is TBD and its length is 12 or 1620 18 octets. The semantics of this AVP follow those of the 1621 VolumeThreshold and DurationThreshold AVPs. It consists of a Value- 1622 Digits AVP and optionally an Exponent AVP. 1624 4.3.8. Value-Digits AVP 1626 The type of the Value-Digits AVP is TBD and its length is 10 octets. 1627 This AVP encodes the most significant digits of a number, encoded as 1628 a 64 unsigned integer, in network byte order. If decimal values are 1629 needed to present the number, the scaling MUST be indicated with a 1630 related Exponent AVP. For example, the decimal number 0.05 is 1631 encoded by a Value-Digits AVP set to 5, and a scaling that is 1632 indicated with the Exponent AVP set to -2. 1634 4.3.9. Exponent AVP 1636 The type of the Exponent AVP is TBD and its length is 6 octets. This 1637 AVP contains the exponent value that is to be applied to the 1638 accompanying Value-Digit AVP. It contains a 32 bit signed value, in 1639 network byte order. 1641 4.3.10. Update-Reason AVP 1643 The type of the Update-Reason AVP is TBD and its length is 4 octets. 1644 This AVP shall be present in the on-line RADIUS Access-Request 1645 message (PPC to PPS direction). It indicates the reason for 1646 initiating the on-line quota update operation. Update reasons 6, 7, 1647 8 and 9 indicate that the associated resources are released at the 1648 client side, and that therefore the PPS shall not allocate a new 1649 quota in the RADIUS Access Accept message. 1651 1. Pre-initialization 1653 2. Initial Request 1655 3. Threshold Reached 1657 4. Quota Reached 1659 5. TITSU Approaching 1661 6. Remote Forced Disconnect 1663 7. Client Service Termination 1665 8. "Access Service" Terminated 1667 9. Service not established 1669 10. One-Time Charging 1671 4.3.11. PrepaidServer AVP 1673 The type of the PrepaidServer AVP is TBD and its length is 6 or 18 1674 octets, for IPv4 and IPv6 addresses respectively. This optional AVP 1675 indicates the address of the serving PPS. If present, the Home 1676 RADIUS server uses this address to route the message to the serving 1677 PPS. The attribute may be sent by the Home RADIUS server. Multiple 1678 instances of this subtype MAY be present in a single PPAQ AVP. 1680 If present in the incoming RADIUS Access-Accept message, the SAD 1681 shall send this attribute back without modifying it in the subsequent 1682 RADIUS Access-Request message, except for the first one. If multiple 1683 values are present, the SAD shall not change their order. 1685 4.3.12. Service-ID AVP 1687 The type of the Service-ID AVP is TBD and its length is undefined. 1688 This AVP encodes an opaque string that uniquely describes the service 1689 instance to which prepaid metering should be applied. A Service-Id 1690 could be an IP 5-tuple (source address, source port, destination 1691 address, destination port, protocol). If a Service-ID AVP is present 1692 in the PPAQ, the entire PPAQ refers to that service. If a PPAQ does 1693 not contain a Service-Id or Rating-Group-ID, then the PPAQ refers to 1694 the Access Service. 1696 4.3.13. Rating-Group-ID AVP 1698 The type of the Rating-Group-ID is TBD and its length is 6 octets. 1700 This AVP indicates that this PPAQ is associated with resources 1701 allocated to a Rating Group with the corresponding ID. This AVP is 1702 encoded as a 32 bit unsigned value, in network byte order. A PPAQ 1703 MUST NOT contain more than one Rating-Group-ID. 1705 4.3.14. Termination-Action AVP 1707 The type of the Termination-Action AVP is TBD and its length is 3 1708 octets. This AVP contains an enumeration of the action to take when 1709 the PPS does not grant additional quota. Valid actions are as 1710 follows. (Note that the value 0 is reserved.) 1712 1. Terminate 1714 2. Request More Quota 1716 3. Redirect/Filter 1718 4.3.15. Pool-ID AVP 1720 The type of the Pool-ID) AVP is TBD and its length is 6 octets. This 1721 AVP identifies the resource pool that the quota included in this PPAQ 1722 is associated with. It is encoded as a 32 bit unsigned value, in 1723 network byte order. 1725 4.3.16. Pool-Multiplier AVP 1727 The type of the Pool-Multiplier AVP is TBD and its length is 12 or 18 1728 octets. The pool-multiplier determines the weight that resources are 1729 inserted into the pool that is identified by the accompanying Pool-ID 1730 AVP, and the rate at which resources are taken out of the pool by the 1731 relevant Service or Rating-Group. The attribute consists of a Value- 1732 Digits AVP and optionally an Exponent AVP (as indicated by the length 1733 field). 1735 4.3.17. Requested-Action AVP 1737 The type of the Requested-Action AVP is TBD and its length is 3 1738 octets. This AVP can only be present in messages sent from the PPC 1739 to the PPS. It indicates that the user or the PPC desires the PPS to 1740 perform the indicated action and to return the result. The PPAQ in 1741 which a Requested-Action AVP occurs MUST NOT contain a QID, and MUST 1742 contain a Service-Identifier that, possibly in combination with other 1743 AVPS, can be used by the PPS to uniquely identify the service for 1744 which the indicated action is requested. The following actions may 1745 be requested. 1747 1. Balance Check 1749 2. Price Enquiry 1751 4.3.18. Check-Balance-Result AVP 1753 The type of the Check-Balance-Result AVP is TBD and its length is 3 1754 octets. This AVP can only be present in messages sent from the PPS 1755 to the PPC. It indicates the balance check decision of the PPS about 1756 a previously received Balance Check Request (as indicated in a 1757 Requested-Action AVP). Possible values are 0 for "success" and 1 for 1758 "failure" and mean that sufficient funds are available (resp. are not 1759 available) in the user's prepaid account. The PPAQ in which a Check- 1760 Balance-Result occurs MUST NOT include a QID, because no quota is 1761 reserved by the PPS. 1763 4.3.19. Cost-Information AVP 1765 The type of the Cost-Information AVP is TBD and its length is 1766 variable. This AVP is used in order to return the cost information 1767 of a service, which the PPC can transfer transparently to the end 1768 user. This AVP is sent from the PPS to the PPC as a response to a 1769 "Price Enquiry", as indicated by the Requested-Action AVP. This AVP 1770 consists of four further AVPs, as follows. 1772 1. Value-Digits ASP: this encodes the most significant digits of the 1773 monetery value that represents the cost in question. 1775 2. Exponent AVP: this encodes the exponent that applies to the 1776 Value-Digits AVP. 1778 3. Currency-Code AVP: the type of this AVP is TBD, and its length is 1779 4 octets. It encodes the currency code, as defined in the ISO 1780 4217 standard. 1782 4. Cost-Unit AVP: the type of this AVP is TBD and its length is 1783 variable. It carries a UTF8String encoded human readable string 1784 that can be displayed to the end user. It specifies the 1785 applicable unit to the Cost-Information when the service cost is 1786 a cost per unit (e.g., cost of the service is $1 per minute). 1787 The Cost-Unit can be minutes, hours, days, kilobytes, megabytes, 1788 etc. 1790 Example: the cost of 7.75 Malawi kwacha per hour would be encoded as 1791 follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, and 1792 Cost-Unit = "hour". 1794 The PPAQ in which a Cost-Information occurs MUST NOT include a QID, 1795 because no quota is actually reserved by the PPS. 1797 NOTES: Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear 1798 in the PPAQ attribute. A PPAQ MUST NOT contain more than one 1799 Service-Id, MUST NOT contain more than one Rating-Group-Id, and MUST 1800 NOT contain both a Service-Id and a Rating-Group-Id. A PPAQ that 1801 does not contain a Service-ID or a Rating-Group-Id refers to the 1802 "Access Service". A PPAQ MUST NOT contain more than one Pool-Id. A 1803 PPAQ that contains a Pool-Id MUST also contain a Pool-Multiplier AVP. 1805 4.4. Prepaid Tariff Switching Attribute (PTS) 1807 This specification defines the PTS attribute which allows for 1808 changeovers from one rate to another during service provision. 1809 Support for tariff switching is optional for both the PPC and the 1810 PPS. PPCs use the flag "Tariff Switching supported" of the 1811 AvailableInClient subtype of the PPAC attribute in order to indicate 1812 support for tariff switching. PPSs employ the PTS attribute in order 1813 to announce their support for tariff switching. Details of this will 1814 be specified after the format of the PTS attribute has been defined. 1816 If a RADIUS message contains a PTS attribute, it MUST also contain at 1817 least one PPAQ attribute. If a RADIUS Access-Request message 1818 contains a PTS attribute or a "Tariff Switching supported" flag, it 1819 MUST also contain an Event-Timestamp RADIUS attribute (see [3]). 1821 The type of the PTS attribute is TBD and its lengh is variable. It 1822 contains one or more subtypes, as follows. Every PTS AVP MUST 1823 include a QuotaIdentifier AVP as specified in Section 4.3.1. In an 1824 online RADIUS Access-Request message sent from the PPC to the PPS, 1825 the QuotaIdentifier AVP must contain a quota identifier that was 1826 previously received from the PPS and MUST be the same as a quota 1827 identifier of one of the PPAQ attributes included the same RADIUS 1828 message. 1830 A PPAQ attribute that is transported along with a PTS attribute and 1831 has the same quota identifier value as the PTS attribute in its own 1832 QID subfield shall be referred to as the "accompanying PPAQ 1833 attribute". If a PPS receives an Access-Request message from a PPC, 1834 it associates a unique quota identifier to this request. Thus, a 1835 quota identifier also identifies a particular service. 1837 The PTS AVP contains a number of other subtype AVPs which are 1838 specified in the following subsections. 1840 4.4.1. VolumeUsedAfterTariffSwitch AVP 1842 The type of the VolumeUsedAfterTariffSwitch attribute is TBD and its 1843 length is 12 or 18 octets. The VolumeUsedAfterTariffSwitch subtype 1844 SHALL be used in online RADIUS Access-Request messages (PPC to PPS 1845 direction). It indicates the volume (in octets) used during a 1846 session after the last tariff switch for the service specified via 1847 the QID subfield and the accompanying PPAQ attribute. The attribute 1848 consists of a Value-Digits AVP and optionally an Exponent AVP (as 1849 indicated in the length field). 1851 4.4.2. TariffSwitchInterval AVP 1853 The type of the TariffSwitchInterval is TBD and its length 6 octets. 1854 This AVP MUST be present in each PTS attribute that is part of a 1855 RADIUS Access-Accept message (PPS to PPC direction). It indicates 1856 the interval (in seconds) between the value of Event-Timestamp RADIUS 1857 attribute (see [3]) of the corresponding RADIUS Access-Request 1858 message and the next tariff switch condition. 1860 4.4.3. TimeIntervalafterTariffSwitchUpdate AVP 1862 The type of the TimeIntervalafterTariffSwitchUpdate (TITSU) AVP is 1863 TBD and its length is 6 octets. The PPS MUST include this AVP if 1864 there is another tariff switch period after the period that ends as 1865 indicated by the TSI attribute. The TITSU attribute encodes the 1866 number seconds of the tariff period that begins immediately after the 1867 period that ends as indicated by the TSI attribute. If the TITSU 1868 attribute is zero or omitted, the PPC assumes that the tariff period 1869 which ends as indicated by the TSI attribute lasts until further 1870 notice. If TITSU is specified, the PPC MUST send a quota update 1871 before the point in time specified by the TITSU attribute (see 1872 Figure 9). 1874 If a RADIUS message contains a PTS attribute, it MUST also contain at 1875 least one PPAQ attribute. The PTS is associated with the PPAQ by the 1876 QID. If multiple services are supported and if the PPAQ is 1877 associated with a service as indicated by the Service-ID AVP, then 1878 the PTS refers to the tariff switch for that service. If the PPAQ 1879 does not have a Service-ID, then the PTS refers to tariff switch for 1880 the Access-Service. 1882 If a PPC supports tariff switching then it MUST set the 0x00000040 1883 (Tariff switching supported) flag of the AvailableInClient subtype of 1884 the PPAC attribute that is contained in the Access-Request packet 1885 starting the session. 1887 5. Translation between RADIUS prepaid and Diameter Credit Control 1889 In scenarios where the service metering device uses the "RADIUS 1890 prepaid" (RPP) protocol for accounting and prepaid charging while the 1891 AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, 1892 a translation agent that enables the interoperation of both systems, 1893 is desirable. This also applies vice versa, i.e. in scenarios where 1894 the AAA infrastructure uses RADIUS and the service metering device 1895 uses Diameter. 1897 The idea of such a translation agent would be to convert incoming RPP 1898 (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It 1899 would be, in principle, desirable for the translation agent to be 1900 stateless. That is, the agent should not be required to internally 1901 maintain information about each ongoing RADIUS or Diameter session. 1902 However, under the current specification of RPP and DCC, this appears 1903 to be impossible due to a number of reasons. These include the 1904 following. 1906 1. The transport mechanism for DCC is TCP, which requires per- 1907 session state to be maintained at both endpoints of the 1908 communication. Note, however, that, in principle, each DCC 1909 message could be sent over a dedicated TCP connection which is 1910 torn down as soon as the message is sent. This, however, is 1911 likely to be unacceptable in terms of efficiency. 1913 2. While RPP messages encode the cumulative amount of consumed/ 1914 requested resources, DCC messages carry the difference from the 1915 previous message. This means that the translation agent has to 1916 maintain the current amount of consumed/requested resources in 1917 order to be able to calculate the correct amount to be put into 1918 an outgoing message. 1920 The translator maps each incoming RPP (resp. DCC) message into an 1921 outgoing DCC (resp. RPP) message, and possibly establishes or updates 1922 local state that is associated with the session. The translated 1923 (i.e. outgoing) message is a function of the incoming message as well 1924 as existing state that is associated with the current session. 1926 Translation occurs on an attribute-by-attribute basis. In this 1927 document, the translation of only RPP and DCC attributes is 1928 considered. In reality, this translation has to be performed in 1929 coordination and orchestration with the translation of the attributes 1930 of the base RADIUS and Diameter. Certain attributes are translated 1931 without consideration of local per-session state. Other attributes, 1932 namely those that are bound to a particular session, require such 1933 consideration. The translation agent has to identify the session 1934 (and possibly subsession) an incoming message belongs to in order to 1935 consult the appropriate local per-session state. 1937 Note that certain DCC attributes cannot be translated due to their 1938 semantics not being present in RPP, and vice versa. This may result 1939 in the messages, in which these attributes occur, not being delivered 1940 to their intended destination. Whenever this would lead to a failure 1941 at the destination, it is desirable to inform the originator about 1942 this failure and terminate the session in both directions. 1944 In each of the two scenarios (namely RPP client / DCC AAA 1945 infrastructure and DCC client / RPP AAA infrastructure), the 1946 translator operates in two directions, namely RPP to DCC and vice 1947 versa. In the following sections, the notation c->s means that the 1948 attribute in question may occur only in the direction from the client 1949 to the server. The notation s->c denotes the converse and the 1950 notation c<->s denotes that the attribute may occur in messages that 1951 are directed in either direction. 1953 5.1. Session Identification 1955 The translation agent has to keep per-session state in order to 1956 perform its task. A session may be identified based on the RPP 1957 identifier or the DCC session identifier. That is, the translation 1958 agent should always maintain a pair of (RPP, DCC) session identifiers 1959 and maintain the per-session state in association with that pair. 1960 This per-session state must be addressable by either of these two 1961 identifiers. Moreover, an RPP session identifier must uniquely 1962 correspond to a DCC identifier. (If this holds, the converse also 1963 holds.) Each subsession identifier within an RPP session must also 1964 uniquely correspond to a subsession identifier within its 1965 corresponding DCC session. (If this holds the converse also holds.) 1967 5.2. Translation between RADIUS prepaid client and Diameter Credit 1968 Control AAA infrastructure 1970 This section describes the translator in the "RPP client / DCC AAA 1971 infrastructure" case. In other words, in this section it is assumed 1972 that the client "talks" RPP and the AAA inftrastructure "talks" DCC. 1973 The translator is assumed to sit somewhere in the middle and to 1974 mediate between client and server. 1976 For each RPP AVP (i.e. AVP that is specified in the present 1977 document), the transformation into a semantically equivalent DCC AVP 1978 (if such an AVP exists), along with what per-session state the 1979 translator has to create or consult, is described. For clarity of 1980 exposition, each RPP AVP is addressed in a separate subsection. 1981 Since, in this scenario, the PPC is typically the initiator a 1982 session, the focus is on the RPP AVPs. 1984 5.2.1. PPAC (c<->s) 1986 A DCC client is assumed to always support Volume metering, Duration 1987 metering, Resource metering, Pools, Rating groups, and Tariff 1988 Switching. Thus, if a PPAQ that indicates any of the above is sent 1989 client->server, the translator does the following: It lets message go 1990 through but remembers what exactly the client supports. If the 1991 server later requests (servier -> client direction) an unsupported 1992 metering to be performed, send failure to server and cause the 1993 session to be terminated at the client. 1995 If a PPAC indicates support for multiple services (0x00000020), the 1996 translator maps this onto a DCC Multiple-Services- Indicator AVP. 1998 5.2.2. Service Termination Attribute (c->s) 2000 The Diameter base protocol assumes that the client always supports 2001 dynamic session termination. If this AVP is present, the translator 2002 does not need to do anything, i.e. there exists no DCC AVP that this 2003 AVP can be mapped to. If this AVP is absent, the message in which it 2004 appears should either be discarded and originator should be informed 2005 of a failure, or the message can be passed on (without this AVP being 2006 mapped onto a DCC AVP). However, in the latter case, the translator 2007 has to remember that the client does not support dynamic termination. 2008 Thus, the translatior has to initiate the normal session termination 2009 procedure with the client when (if) dynamic termination is later 2010 initiated by the server. 2012 5.2.3. Quota Identifier Attribute (c<->s) 2014 When quota is allocated for the first time by the DCC server, the 2015 translator has to create a QID AVP, as required by this 2016 specification. The translator later uses a QID AVP that is sent in 2017 the client-to-server direction in order to identify the corresponding 2018 DCC session. The QID has to be saved in the translator's per session 2019 state. 2021 5.2.4. Volume Quota Attribute (c<->s) 2023 If this AVP occurs in a message that is sent in the server-to-client 2024 direction, it is translated into a Granted-Service-Unit AVP with an 2025 embedded CC-Total-Octets AVP. [editor's note: this sentence belongs 2026 to the other translation type, i.e. AAA = RPP and client = DCC.] 2028 If this AVP occurs in a message that is sent in the client-to-server 2029 direction, then it is translated into a Used-Service-Unit AVP with an 2030 embedded CC-Total-Octets AVP. Note that only the difference between 2031 current cumulative quota for the (sub)session and the quota in 2032 incoming messages is indicated in the translated DCC message. Local 2033 state is updated with cumulative consumed resources. 2035 Conversely, if the server grants quota using the DCC Granted-Service- 2036 Unit AVP with an embedded CC-Total-Octets AVP, then the translation 2037 agent must translate this into a Volume Quota Attribute. Again, 2038 local state must be consulted so that the cumulative amount of octets 2039 is indicated in the Volume Quota attribute. 2041 5.2.5. Duration Quota Attribute (c<->s) 2043 If this AVP occurs in a message that is sent in the server-to-client 2044 direction, it is translated into a Granted-Service-Unit AVP with an 2045 embedded CC-Time AVP. [editor's note: this sentence belongs to the 2046 other translation type, i.e. AAA = RPP and client = DCC.] 2048 If this AVP occurs in a message that is sent in the client-to-server 2049 direction, then it is translated into a Used-Service-Unit AVP with an 2050 embedded CC-Time AVP. Note that only the difference between current 2051 cumulative quota for the (sub)session and the quota in incoming 2052 messages is indicated in the translated DCC message. Local state is 2053 updated with cumulative consumed resources (i.e. time). 2055 Conversely, if the server grants quota using the DCC Granted-Service- 2056 Unit AVP with an embedded CC-Time AVP, then the translation agent 2057 must translate this into a Duration Quota attribute. Again, local 2058 state must be consulted so that the cumulative amount of seconds is 2059 indicated in the Duaration Quota attribute. 2061 5.2.6. Resource Quota Attribute (c<->s) 2063 If this AVP occurs in a message that is sent in the server-to-client 2064 direction, it is translated into a Granted-Service-Unit AVP with an 2065 embedded CC-Service-Specific-Units AVP. [editor's note: this sentence 2066 belongs to the other translation type, i.e. AAA = RPP and client = 2067 DCC.] 2069 If this AVP occurs in a message that is sent in the client-to-server 2070 direction, then it is translated into a Used-Service-Unit AVP with an 2071 embedded CC-Service-Specific-Units AVP. Note that only the 2072 difference between current cumulative quota for the (sub)session and 2073 the quota in incoming messages is indicated in the translated DCC 2074 message. Local state is updated with cumulative consumed resources 2075 (i.e. resources). 2077 Conversely, if the server grants quota using the DCC Granted-Service- 2078 Unit AVP with an embedded CC-Service-Specific-Units AVP, then the 2079 translation agent must translate this into a Resource Quota 2080 attribute. Again, local state must be consulted so that the 2081 cumulative amount of resource units is indicated in the Resource 2082 Quota attribute. 2084 Note that the "resource" type is application dependent. This means 2085 that a DCC application unit corresponds to n RPP application units, 2086 where n may be any real number. If n is not 1, then the RPP/DCC 2087 translator must be aware of that and translate resource units 2088 accordingly. 2090 5.2.7. Value Digits Attribute (c<->s) 2092 The encoding of this AVP is similar in RPP and DCC, and the value it 2093 holds may have to be evaluated in conjunction with an acommpanying 2094 "Exponent" AVP. It should be kept in mind that, in RPP the 2095 cumulative amount of granted/consumed quota is typically encoded into 2096 an AVP of this type, while in DCC only the difference from a previous 2097 message. 2099 5.2.8. Exponent Attribute (c<->s) 2101 The encoding of this AVP is similar in RPP and DCC, and the value it 2102 holds may have to be evaluated in conjunction with an acommpanying 2103 "Value Digits" AVP. It should be kept in mind that, in RPP the 2104 cumulative amount of granted/consumed quota is typically encoded into 2105 a related "Value Digits" and "Exponent" AVP pair, while in DCC only 2106 the difference from a previous message is encoded into such a pair. 2108 5.2.9. Volume/Duration/Resource Threshold Attributes (s->c) 2110 In DCC the concept of "threshold" does not exist. Instead, the DCC 2111 client is assumed to ask for the replenishment of quota in good time. 2112 In RPP, on the other hand, the server may optionally include a 2113 threshold AVP, as an indication to the PPC about when to ask for 2114 quota replenishment. 2116 Thus, in this scenario, there is no need for the translator to ever 2117 include a threshold attribute into the messages that it sends to the 2118 PPC. If, however, there is a need for a threshold attribute to be 2119 present in order to avoid a possible service provision 2121 5.2.10. Update Reason Attribute (c->s) 2123 The DCC AVP that is semantically closer to the Update Reason AVP than 2124 any other AVP is the CC-Request-Type AVP. This AVP indicates whether 2125 the message is which it appears is intended to indicate an "initial", 2126 an "intermediate" or a "final interrogation". Morever, in case of 2127 the session being terminated at the client, it indicates the reason 2128 for this termination. 2130 The following list lists the possible values of an "Update Reason" 2131 attribute, along with corresponding values for the CC-Request-Type 2132 AVP. 2134 o Pre-initialization: No action/value defined. 2136 o Initial Request: Typically an "intial interrogation" is triggered 2137 as a result of the reception of the message that contains this 2138 Update Reason AVP. Hence, CC-Request-Type AVP indicates 2139 "INITIAL_REQUEST". 2141 o Threshold Reached: The reception of the message containing this 2142 Update Reason AVP typically triggers an "intermediate 2143 interrogation". Hence, CC-Request-Type AVP indicates 2144 "UPDATE_REQUEST". 2146 o Quota Reached: The reception of the message containing this Update 2147 Reason AVP typically triggers an "intermediate interrogation". 2148 Hence, CC-Request-Type AVP indicates "UPDATE_REQUEST". 2150 o TITSU Approaching: The reception of the message containing this 2151 Update Reason AVP typically triggers an "intermediate 2152 interrogation". Hence, CC-Request-Type AVP indicates 2153 "UPDATE_REQUEST". 2155 o Remote Forced Disconnect: Reception of such an Update Reason 2156 indicates that the client has terminated the session. The 2157 corresponding value for the CC-Request-Type AVP is 2158 "TERMINATION_REQUEST". 2160 o Client Service Termination: Reception of such an Update Reason 2161 indicates that the client has terminated the session. The 2162 corresponding value for the CC-Request-Type AVP is 2163 "TERMINATION_REQUEST". 2165 o "Access Service" Terminated: Reception of such an Update Reason 2166 indicates that the client has terminated the session. The 2167 corresponding value for the CC-Request-Type AVP is 2168 "TERMINATION_REQUEST". 2170 o Service not established: Reception of such an Update Reason 2171 indicates that the client has terminated the session. The 2172 corresponding value for the CC-Request-Type AVP is 2173 "TERMINATION_REQUEST". 2175 o One-Time Charging: Such an Update Reason indicates that a one-time 2176 charging event is initiated by the client. The corresponding 2177 value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a 2178 "Requested-Action: AVP MUST also be included in the outgoing DCC 2179 message. Typically, this would be of the type "DIRECT_DEBITING", 2180 or "REFUND_ACCOUNT", depending on other AVPs present in the 2181 message. 2183 5.2.11. PrepaidServer Attribute (s<->c) 2185 The PPC typically never sets the value of a PrepaidServer attribute. 2186 Instead, it repeats those values that it receives from the AAA 2187 infrastructure, in this scenario from the translator. This attribute 2188 is therefore not used in a translation scenario. Nevertheless, the 2189 translator must make sure that messages about the same RPP session 2190 are forwarded to the same DCC server, throughout the whole session. 2191 This may be easy to guarantee since the transport of Diameter is TCP. 2193 5.2.12. Service-ID Attribute (s<->c) 2195 The DCC equivalent of a RPP "Service-ID" AVP is the combination of 2196 Service-Context-Id and Service-Identifier AVPs. The translator must 2197 keep a static equivalence table of the RPP Service-ID and the 2198 corresponding DCC combination in order to correctly translate an RPP 2199 service identifier into DCC and back. 2201 5.2.13. Rating-Group-ID Attribute (s<->c) 2203 The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a 2204 "Rating-Group-ID". Depending on the configuration, this AVP may 2205 contain the same value on both the RPP and the DCC side of the 2206 communication. If, however, static rating groups are configured 2207 between the RCC client and the translator, and different rating 2208 groups between the DCC server and the translator, then the translator 2209 has to maintain a static translation table for the rating group 2210 identifier. In any case, the translation of a rating group AVP, is 2211 not a function of the translator's local per-session state. 2213 5.2.14. Termination-Action Attribute (s->c) 2215 The DCC equivalent of the "Termination-Action" AVP is called the 2216 "Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA 2217 infrastructure), a DCC "Final-Unit-Action" AVP is translated into a 2218 "Termination-Action" AVP. The following list contains the possible 2219 "Final-Unit-Action" values along with their "Termination-Action" 2220 equivalent. 2222 o TERMINATE (DCC): This value has a direct equivalent in RPP, also 2223 called "Terminate". 2225 o REDIRECT (DCC): If this value appears in a "Final-Unit-Action" 2226 AVP, then a "Redirect-Server-Address" AVP must also appear in the 2227 same DCC message. The translator translates these two AVPs into a 2228 "Termination-Action" with value "Redirect/Filter" and an 2229 eqiovalent NAS-Filter-Rule attribute (specified in http:// 2230 www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt). 2232 o RESTRICT_ACCESS (DCC): If this value appears in a "Final-Unit- 2233 Action" AVP, then a "Restriction-Filter-Rule" AVP must also appear 2234 in the same DCC message. The translator translates these two AVPs 2235 into a "Termination-Action" with value "Redirect/Filter" and an 2236 eqiovalent Filter-ID attribute (specified in http://www.ietf.org/ 2237 internet-drafts/draft-ietf-radext-ieee802-00.txt). 2239 o In the absence of a "Final-Unit-Action" AVP, the DCC server 2240 assumes that the DCC client will ask for replenishment of quota at 2241 some suitable time. In RPP, this is explicitly conveyed via a 2242 "Termination-Action" AVP with the value "Request More Quota". 2243 Thus, in the absence of a "Final-Unit-Action" AVP, the translator 2244 in this scenario appends such an AVP into the outgoing RPP 2245 message. 2247 5.2.15. Pool-ID Attribute (s<->c) 2249 The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID". 2250 Typically, no translation needs to be done to the "Pool-ID" 2251 attribute. 2253 5.2.16. Multiplier Attribute (s<->c) 2255 The multiplier attribute, which is a pair of "Value-Digits" and 2256 "Exponent" AVPs, typically needs no translation, since the value it 2257 carries (inside a "Value-Digits" and an "Exponent" AVP) represents 2258 the rating of the service or rating group to which it refers, with 2259 respect to abstract units. As such, the same multiplier value would 2260 typically applyt be conveyed from a DCC server to an PPC, and vice 2261 versa. 2263 5.2.17. Requested-Action Attribute (c->s) 2265 The "Requested Action" AVP can be directly translated into its DCC 2266 equivalent, which carries the same name. 2268 1. Balance Check (PCC): CHECK_BALANCE (DCC) 2270 2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC) 2272 5.2.18. Check-Balance-Result Attribute (s->c) 2274 This attribute carries only a binary value. Hence, its translation 2275 is straightforward. 2277 5.2.19. Cost-Information Attribute (s->c) 2279 This attribute consists of a Value-Digits AVP, an Exponent AVP, a 2280 Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise 2281 exist in DCC, and carry identical semantics in the context of the 2282 "Cost-Information" AVP. Thus, the translation of this attribute is 2283 straightforward. 2285 5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) 2287 This attribute carries the amount of octets that were consumed after 2288 a tariff change. It always appears in a message with an accompanying 2289 PPAQ attribute in which the total amount of octets (i.e. those that 2290 were consumed both before and after the tariff switch) is reported. 2291 Thus, the translation agent can compute the amount of octets that 2292 were consumed before the tariff change. 2294 In DCC, the two amounts, i.e. the octets that were consumed before a 2295 tariff change and those that were consumed afterwards, are reported 2296 in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs 2297 have an embedded CC-Total-Octets AVP that indicates the appropriate 2298 amount of octets. Furthermore, the Used-Service-Unit AVP that 2299 carries the amount that was consumed before the tariff switch also 2300 carries an embedded Tariff-Change-Usage AVP with the value 2301 UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP 2302 that carries the amount that was consumed after the tariff switch 2303 also carries an embedded Tariff-Change-Usage AVP with the value 2304 UNIT_AFTER_TARIFF_CHANGE (1). 2306 5.3. Translation between Diameter Credit Control client and RADIUS- 2307 based AAA infrastructure 2309 This section describes the translator in the "DCC client / RPP AAA 2310 infrastructure" case. In other words, in this section it is assumed 2311 that the client "talks" DCC and the AAA inftrastructure "talks" RPP. 2312 The translator is assumed to sit somewhere in the middle and to 2313 mediate between client and server. 2315 For each DCC AVP (i.e. AVP that is specified in RFC 4006), the 2316 transformation into a semantically equivalent RPP AVP (if such an AVP 2317 exists), along with what per-session state the translator has to 2318 create or consult, is described. For clarity of exposition, each DCC 2319 AVP is addressed in a separate subsection. Since, in this scenario, 2320 the client is typically the initiator a session, the focus is on the 2321 DCC AVPs. 2323 5.3.1. CC-Correlation-Id Attribute ( ) 2325 [semantics not clear]. 2327 5.3.2. CC-Request-Number Attribute (c <-> s) 2329 This attribute is used to correlate DCC requests and answers. In 2330 RPP, this correlation is achieved by means of the QID. This 2331 attribute is therefore not translated. However, the translation 2332 agent must use it in accordance with the DCC specification. 2334 5.3.3. CC-Request-Type Attribute ( ) 2336 Although the CC-Request-Type attribute is not translated, the 2337 translation agent has to include it into the messages it exchanges 2338 with the client, as specified in the DCC specification. 2340 5.3.4. CC-Session-Failover Attribute ( ) 2342 TBD. 2344 5.3.5. CC-Sub-Session-Id Attribute ( ) 2346 TBD. 2348 5.3.6. Check-Balance-Result Attribute ( ) 2350 TBD. 2352 5.3.7. Cost-Information Attribute ( ) 2354 TBD. 2356 5.3.8. Unit-Value Attribute ( ) 2358 TBD. 2360 5.3.9. Exponent Attribute ( ) 2362 TBD. 2364 5.3.10. Value-Digits Attribute ( ) 2366 TBD. 2368 5.3.11. Currency-Code Attribute ( ) 2370 TBD. 2372 5.3.12. Cost-Unit Attribute ( ) 2374 TBD. 2376 5.3.13. Credit-Control Attribute ( ) 2378 TBD. 2380 5.3.14. Credit-Control-Failure-Handling Attribute ( ) 2382 TBD. 2384 5.3.15. Direct-Debiting-Failure-Handling Attribute ( ) 2386 TBD. 2388 5.3.16. Multiple-Services-Credit-Control Attribute ( ) 2390 TBD. 2392 5.3.17. Granted-Service-Unit Attribute ( ) 2394 TBD. 2396 5.3.18. Requested-Service-Unit Attribute ( ) 2398 TBD. 2400 5.3.19. Used-Service-Unit Attribute ( ) 2402 TBD. 2404 5.3.20. Tariff-Time-Change Attribute ( ) 2406 TBD. 2408 5.3.21. CC-Time Attribute ( ) 2410 TBD. 2412 5.3.22. CC-Money Attribute ( ) 2414 TBD. 2416 5.3.23. CC-Total-Octets Attribute ( ) 2418 TBD. 2420 5.3.24. CC-Input-Octets Attribute ( ) 2422 TBD. 2424 5.3.25. CC-Output-Octets Attribute ( ) 2426 TBD. 2428 5.3.26. CC-Service-Specific-Units Attribute ( ) 2430 TBD. 2432 5.3.27. Tariff-Change-Usage Attribute ( ) 2434 TBD. 2436 5.3.28. Service-Identifier Attribute ( ) 2438 TBD. 2440 5.3.29. Rating-Group Attribute ( ) 2442 TBD. 2444 5.3.30. G-S-U-Pool-Reference Attribute ( ) 2446 TBD. 2448 5.3.31. G-S-U-Pool-Identifier Attribute ( ) 2450 TBD. 2452 5.3.32. CC-Unit-Type Attribute ( ) 2454 TBD. 2456 5.3.33. Validity-Time Attribute ( ) 2458 TBD. 2460 5.3.34. Final-Unit-Indication Attribute ( ) 2462 TBD. 2464 5.3.35. Final-Unit-Action Attribute ( ) 2466 TBD. 2468 5.3.36. Restriction-Filter-Rule Attribute ( ) 2470 TBD. 2472 5.3.37. Redirect-Server Attribute ( ) 2474 TBD. 2476 5.3.38. Redirect-Address-Type Attribute ( ) 2478 TBD. 2480 5.3.39. Redirect-Server-Address Attribute ( ) 2482 TBD. 2484 5.3.40. Multiple-Services-Indicator Attribute ( ) 2486 TBD. 2488 5.3.41. Requested-Action Attribute ( ) 2490 TBD. 2492 5.3.42. Service-Context-Id Attribute ( ) 2494 TBD. 2496 5.3.43. Service-Parameter-Info Attribute ( ) 2498 TBD. 2500 5.3.44. Service-Parameter-Type Attribute ( ) 2502 TBD. 2504 5.3.45. Service-Parameter-Value Attribute ( ) 2506 TBD. 2508 5.3.46. Subscription-Id Attribute ( ) 2510 TBD. 2512 5.3.47. Subscription-Id-Type Attribute ( ) 2514 TBD. 2516 5.3.48. Subscription-Id-Data Attribute ( ) 2518 TBD. 2520 5.3.49. User-Equipment-Info Attribute ( ) 2522 TBD. 2524 5.3.50. User-Equipment-Info-Type Attribute ( ) 2526 TBD. 2528 5.3.51. User-Equipment-Info-Value Attribute ( ) 2530 TBD. 2532 6. Security Considerations 2534 [Editor's Note: A future version of this document will provide a 2535 description of the security threats and the countermeasures.] 2537 7. IANA Considerations 2539 This document requires the assignment of new Radius attributes type 2540 numbers for the following attributes: Prepaid-Accounting-Capability 2541 (PPAC), AvailableInClient, Prepaid-Accounting-Operation (PPAQ), 2542 QuotaIdentifier, (QID), VolumeQuota (VQ), VolumeTreshold (VT), 2543 DurationQuota (DQ), DurationTreshold (DT), UpdateReason (UR), 2544 PrePaidServer (PPS), ServiceID (SID), Rating-Group-ID (RGID), 2545 TerminationAction (TA), PoolID (PID), PoolMultiplier (PM), Cost- 2546 Information (COST), Session-Termination-Capability (STC), 2547 PrepaidTariffSwitch (PTS) and TariffSwitchInterval (TSI). 2549 8. Contributors 2551 The authors would like to thank Christian Guenther and Yong Li for 2552 their contribution to earlier draft versions. 2554 9. References 2556 9.1. Normative References 2558 [1] Bradner, S., "RFC 2119: Key words for use in RFCs to Indicate 2559 Requirement Levels", March 1997. 2561 [2] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2865: 2562 Remote Authentication Dial In User Server (RADIUS)", June 2000. 2564 [3] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS 2565 Extensions", June 2000. 2567 [4] Bradner, S., "RFC 2026: The Internet Standards Process -- 2568 Revision 3", October 1996. 2570 [5] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. 2572 [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and 2573 I. Goyret, "RFC 2868: RADIUS Attributes for Tunnel Protocol 2574 Support", June 2000. 2576 [7] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Adoba, 2577 "RFC 3576: Dynamic Authorization Extensions to Remote 2578 Authentication Dial-In User Service (RADIUS)", February 2003. 2580 [8] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2581 Levkowetz, "RFC 3748: Extensible Authentication Protocol", 2582 June 2004. 2584 9.2. Informative References 2586 [9] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 2587 Loughney, "RFC 4006: Diameter Credit Control Application", 2588 August 2005. 2590 Appendix A. Example flows 2592 This section presents certain example flows that involve the RADIUS 2593 prepaid extensions. By no means is the intent of this section to 2594 specify or recommend business logic, rating strategies, and 2595 application-level behaviour. The intent of this section is purely to 2596 illustrate some fictive scenarios and the RADIUS prepaid message 2597 flows that could be associated with these scenarios. The contents of 2598 this section should be regarded as a collection of informative 2599 examples that aim to provide guidance to implementors. 2601 A.1. A simple flow 2603 End user PPC AAA Server PPS 2605 user logs on 2606 ------(1)---------> 2608 Access Request 2609 {RADIUS BASE AVPS, 2610 PPAC=00...00011} 2611 -------(2)--------> 2613 RADIUS authentication 2614 <--------------(3)----------------------> 2616 Access Request 2617 {RADIUS BASE AVPS, 2618 PPAC=00...00011} 2619 ------(4)---------> 2621 [allocates 2622 5MB quota] 2624 Access Response 2625 {RADIUS BASE AVPS, 2626 PPAQ={QID=5, VQ = 5MB, 2627 VTH = 4.5 MB}} 2628 <-------(5)-------- 2629 forwards message 2630 <-----(6)----------- 2632 service provision/metering 2633 -------(7)---------> 2635 4.5 MB consumed 2636 Access Request 2637 {RADIUS BASE AVPS, 2638 PPAQ={QID=5, VQ=4.5MB, 2639 REASON=THRESHOLD REACHED}} 2640 -------(8)---------> 2642 forwards message 2643 -------(9)-------> 2645 [allocates another 7MB 2646 to the access service] 2648 Access Response 2649 {RADIUS BASE AVPS, 2650 PPAQ={QID=8, VQ=12MB, 2651 VTH = 11.5 MB}} 2652 <----------(10)-------------- 2653 forwards message 2654 <------(11)-------- 2656 user logs off 2657 ------(12)------- 2659 Access Request 2660 {RADIUS BASE AVPS, 2661 PPAQ={QID=8, VQ=7 MB, 2662 REASON=ACCESS SERV TERMINATED}} 2663 -------(13)---------> 2665 forwards message 2666 -------(14)-------> 2668 [reimburses 2669 user account] 2671 AA Response 2672 {RADIUS BASE AVPS} 2673 <------(15)-------- 2674 AA Response 2675 {RADIUS BASE AVPS} 2676 <------(16)-------- 2678 Figure 12: A simple example message flow 2680 The user logs on (1). The PPC sends a RADIUS Access Request message 2681 to the home AAA server (2), and includes the prepaid-specific PPAC 2682 AVP. This AVP indicates that both duration-based and volume-based 2683 metering is supported. However, it also indicated that multiple 2684 services, rating groups and resource pools are not supported. Note 2685 that no PPAQ AVP with Update Reason="initial request" is included 2686 (see Section 3.7.1). The home AAA server then authenticates the user 2687 and authorizes the access service, as is usual in RADIUS (3). Note 2688 that the PPAC AVP is appended by the PPC in at least the last message 2689 that is sent to the home AAA server during this possibly multiple- 2690 round exchange. 2692 If authentication and authorization is successful (in this example 2693 this is assumed), the home AAA server forwards the final Access 2694 Request to the PPS (4). The PPS identifies the user's prepaid 2695 account from the included base RADIUS AVPs, and determines the 2696 capabilities of the PPC from the PPAC attribute. Assuming that 2697 sufficient funds are available in the user's prepaid account, the PPS 2698 reserves some of these and rates the service. In this example, the 2699 PPS reserves, say, 2 Euros and determines that the access service is 2700 rated at 0.4 Euro per MB. This results in 5 MB of quota being 2701 granted. The PPS also determines that the PPC should ask for this 2702 quota to be replenished once 4.5 MB have been consumed. Thus, it 2703 creates an Access Accept message with a Volume-Threshold indication 2704 of 4.5MB. It further associates the QuotaIdentifier QID=5 to this 2705 quota reservation. This identifier can be used to later uniquely 2706 identify the prepaid session, user, account, etc. The resulting 2707 Access Accept message is sent to the home AAA server (5) and 2708 forwarded to the PPC (6). 2710 Upon reception of message (6), the PPC provides the access service to 2711 the user and meters it accordingly. 2713 At some point in time, the threshold is reached, i.e. 4.5MB of 2714 "access service" have been consumed by the user. At that point, the 2715 PPC generates an Access Request that contains the usual RADIUS 2716 attributes and a PPAQ AVP that reports the amount of consumed quota, 2717 and the request for replenishment, i.e. the Update-Reason= THRESHOLD 2718 REACHED (8). Note that the QID in this message is the same as the 2719 one previously received from the user's home AAA server. This 2720 message is forwarded to the PPS (9). 2722 Upon reception of message (9), the PPS identifies the user and his 2723 account from the QID. In also determines that a prepaid session is 2724 ongoing, and that enough credit remains in the prepaid account in 2725 order for the access service to continue being provided. Since 4.5 2726 MB have been consumed, the PPS subtracts 1.8 Euros from the user's 2727 prepaid account. The PPS decides to reserve another 2.8 euros from 2728 the user's account. (This results in 3 euros being reserved in total 2729 at this point in time.) As the access service is rated at 0.4 euros 2730 per MB, the PPS determines that another 7 MB of quota should be 2731 granted. This results in a total cumulative quota allocation of 12 2732 MB for the access service. The PPS further calculates the new 2733 threshold value of 11.5 MB. Since this is a new quota reservation, 2734 the PPS also allocates a new QuotaIdentifier to it, in this example 2735 QID=8. The resulting RADIUS message is sent to the home AAA server 2736 (10) and forwarded to the PPC (11). 2738 Upon reception of message (11), the PPC updates its records and 2739 continues provisioning access to the user. At some point the user 2740 logs off (12). The PPC must then report how many resources were 2741 consumed, so that the PPC can subtract the appropriate monetary 2742 amount from the user's prepaid account. To this end the PPC 2743 constructs an Access Request message with a PPAQ AVP for the access 2744 service. In this example, 7 MB were consumed by the access service 2745 in total. The PPC reports 7 MB its final message (13). This is 2746 forwarded to the PPS (14) which correlates the report, using the QID, 2747 to the previous session state. It determines, from the previous 2748 records, that the access service had consumed another 4.5 MB before 2749 (as indicated in message (9)). This means that, of the 7 MB, only 2750 3.5 MB have not yet been subtracted from the user's account. Thus, 2751 the PPS subtracts another 1.4 euros from the user's account and, 2752 since the session is to be terminated (REASON=ACCESS SERVICE 2753 TERMINATED), releases any reserved monetary amount. 2755 The PPS responds with an Access Response as required by the RADIUS 2756 base specification (15). So does the home AAA server (16). 2758 A.2. A flow with prepaid tariff switching 2760 End user PPC AAA Server PPS 2762 user logs on 2763 ------(1)---------> 2765 Access Request 2766 {RADIUS BASE AVPS, 2767 PPAC=00...00111} 2768 -------(2)--------> 2770 RADIUS authentication 2771 <--------------(3)----------------------> 2773 Access Request 2774 {RADIUS BASE AVPS, 2775 PPAC=00...00011} 2776 ------(4)---------> 2778 [allocates 2779 20MB quota] 2781 Access Response 2782 {RADIUS BASE AVPS, 2783 PPAQ={QID=5, VQ = 20MB, 2784 VTH = 18 MB}, PTS={ 2785 QID=5, PTS{TSI=300sec, 2786 TITSU=6000sec}} 2787 <-------(5)-------- 2788 forwards message 2789 <-----(6)----------- 2791 service provision/metering 2792 -------(7)---------> 2794 5900 seconds have passed 2796 Access Request 2797 {RADIUS BASE AVPS, 2798 PPAQ={QID=5, VQ=14MB, 2799 REASON=TITSU APPROACH.}, 2800 TSI={QID=5, VUATS=11MB}} 2801 -------(8)---------> 2803 forwards message 2804 -------(9)-------> 2806 [allocates another 10MB 2807 to the access service] 2809 Access Response 2810 {RADIUS BASE AVPS, 2811 PPAQ={QID=8, VQ=30MB, 2812 VTH = 28 MB},PTS={ 2813 QUD=8, PTS=95 sec}} 2814 <----------(10)-------------- 2815 forwards message 2816 <------(11)-------- 2818 user logs off 2819 ------(12)------- 2821 Access Request 2822 {RADIUS BASE AVPS, 2823 PPAQ={QID=8, VQ=17 MB, 2824 REASON=ACCESS SERV TERMINATED}, 2825 PTS={QID=8, VUATS=2.5 MB} 2826 -------(13)---------> 2828 forwards message 2829 -------(14)-------> 2831 [reimburses 2832 user account] 2834 AA Response 2835 {RADIUS BASE AVPS} 2836 <------(15)-------- 2837 AA Response 2838 {RADIUS BASE AVPS} 2839 <------(16)-------- 2841 Figure 13: Example message flow with Tariff Switch 2843 The user logs on (1). The PPC sends a RADIUS Access Request message 2844 to the home AAA server (2), and includes the prepaid-specific PPAC 2845 AVP. This AVP indicates that both duration-based and volume-based 2846 metering is supported, as well as tariff switching. The home AAA 2847 server then authenticates and user and authorizes the access service, 2848 as is usual in RADIUS (3). Note that the PPAC AVP is appended by the 2849 PPC in at least the last message that is sent to the home AAA server 2850 during this possibly multiple-round exchange. 2852 If authentication and authorization is successful (in this example 2853 this is assumed), the home AAA server forwards the final Access 2854 Request to the PPS (4). The PPS identifies the user's prepaid 2855 account from the included base RADIUS AVPs, and determines the 2856 capabilities of the PPC from the PPAC attribute. In this example, it 2857 is assumed that a tariff switch is about to occur in 300 seconds from 2858 the current time. Suppose that the access service is currently rated 2859 at 0.5 euros per MB and in the next tariff period it is rated at 0.6 2860 euros per MB. Suppose further that a third tariff period is about to 2861 start in 6000 seconds from current time and that that access service 2862 is rated at 0.8 euros per MB in that period. The PPS then decides to 2863 reserve 12 euros from the user's account. Since it is conceivable 2864 that the user may consume all allocated quota in the (more expensive) 2865 "0.6-euro" period, the PPS reserves 20 MB of quota, and determines a 2866 threshold value of 18 MB. It constructs a Radius Access Accept 2867 message with a PPAQ attribute that reflects these choices, and 2868 carries a QuotaIdentifier QID=5. It further adds a PTS AVP in the 2869 message which is linked to the PPAQ via the common QID value. The 2870 PTS AVP contains a TSI attribute indicating that a tariff switch will 2871 occur in 300 seconds. It also includes a TITSU attribute with the 2872 value of 6000 seconds. This is included in order to make sure that 2873 the PPC will report the consumed quota before the "2-euro" tariff 2874 period will start. The message is sent to the AAA server (5) and 2875 forwarded to the PPC (6). 2877 Upon reception of message (6), the PPC provides the access service to 2878 the user and meters it accordingly (7). It also keeps track of time. 2879 That is, it remembers how many octets are consumed before and how 2880 many after the tariff switch that will take place in 300 seconds. 2882 In this example it is assumed that the user consumes the allocated 2883 quota rather slowly. In particular, nearly 6000 seconds (the value 2884 indicated by TITSU) pass without the threshold of 18 MB being 2885 reached. The PPC notices this and must therefore report usage and 2886 request the quota to be replenished despite the fact that the 2887 threshold has not been reached. In this example, it decides to do so 2888 100 seconds before the 6000 seconds are reached. To this end, it 2889 constructs an Authorization Access Request message including a PPAQ 2890 that indicates that 14 MB have been consumed up to now. It also 2891 includes a PTS AVP in order to indicate, using the VUATS AVP, that 11 2892 MB of these were consumed after the tariff switch. The message is 2893 sent to the AAA server (8) and forwarded to the PPS (9). 2895 The PPS can link the message to previous session state via the QID. 2896 It now rates the consumed volume as follows. The 11 MB that were 2897 consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros 2898 and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS 2899 subtracts the amount of 6.6+1.5=8.1 euros from the user's account, 2900 which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved. 2902 The PPS now determines that message (9) was sent in order to 2903 replenish the quota for this prepaid session. This can be deduced 2904 from the UPDATE REASON field, which indicates that the PPC sent this 2905 message because the time indicated by the TITSU AVP is approacing. 2906 The PPS now determines that enough credit remains in the user's 2907 prepaid account in order for the access service to continue being 2908 provided and decides to reserve another 8.9 euros from the user's 2909 account. Since it is conceivable that the user will consume the 6 2910 unused MB of quota from the previous allocation, as well as the 2911 entire quota that is to be allocated now, entirely in the "0.8-euro" 2912 period, the quota that should now be granted in addition to the 2913 previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros 2914 are being reserved in order to "cover the worst case scenario". The 2915 fact that 0.9 euros are reserved for this purpose is due to the fact 2916 that the unused 6 MB from the previous allocation correspond to 4.8 2917 euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more 2918 than the amount of funds that are still "reserved" from the previous 2919 allocation. (After this reservation, the total amount of reserved 2920 money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB 2921 being consumed in the "0.8-euro" period.) 2923 Since quotas are encoded in a cumulative way in RADIUS, the PPS 2924 includes a VolumeQuota of 30 MB into the Access Accept message (10). 2925 The PPS further calculates the new threshold value of 28 MB. Since 2926 this is a new quota reservation, the PPS also allocates a new 2927 QuotaIdentifier to it, in this example QID=8. The resulting RADIUS 2928 message is sent to the home AAA server (10) and forwarded to the PPC 2929 (11). 2931 Upon reception of message (11), the PPC updates its records and 2932 continues providing access to the user. At some point the user logs 2933 off (12). The PPC must then report how many resources were consumed, 2934 so that the PPC can subtract the appropriate monetary amount from the 2935 user's prepaid account. To this end the PPC constructs an Access 2936 Request message with a PPAQ AVP for the access service. In this 2937 example, 17 MB were consumed by the access service in total. The PPC 2938 reports 17 MB its final message (13). This is forwarded to the PPS 2939 (14) which correlates the report, using the QID, to the previous 2940 session state. It determines, from the previous records, that the 2941 access service had consumed 14 MB before (as indicated in message 2942 (9)). This means that, of the 17 MB, only the monetary equivalent 2943 for 3 MB have not yet been subtracted from the user's account. The 2944 PPS calculates how much should be deducted from the user's account as 2945 follows. Since the VUATS AVP indicates that 2.5MB were consumed 2946 after the tariff switch, only 0.5 MB were consumed before that. 2947 Thus, the monetary equivalent is 0.5 * 0.6 + 2.5 * 0.8 = 3.6 euros. 2948 That is, the PPS subtracts 3.6 euros from the user's prepaid account. 2949 Since the session has by now be terminated by the PPC (REASON=ACCESS 2950 SERVICE TERMINATED), the PPS now releases any reserved monetary 2951 amount, in this example 12.8 - 3.6 = 9.2 euros. 2953 The PPS responds with an Access Response as required by the RADIUS 2954 base specification (15). So does the home AAA server (16). 2956 Remark: In this example, two tariff switches take place. In other 2957 scenarios, of course, only one tariff switch may occur. In such 2958 scenarios the TITSU AVP is not used. 2960 A.3. Resource pools and Rating Groups 2962 End user PPC AAA Server PPS 2963 user logs on 2964 ------(1)---------> 2966 Access Request 2967 {RADIUS BASE AVPS, 2968 PPAC=00...00101111} 2969 -------(2)--------> 2971 RADIUS authentication 2972 <--------------(3)----------------------> 2974 Access Request 2975 {RADIUS BASE AVPS, 2976 PPAC=00...00101111} 2977 ------(4)---------> 2979 [allocates 2980 5MB quota] 2982 Access Response 2983 {RADIUS BASE AVPS, 2984 PPAQ={QID=5, VQ = 5MB, 2985 poolID=1,mult=1}} 2986 <-------(5)-------- 2987 forwards message 2988 <-----(6)----------- 2990 service provision/metering 2991 -------(7)---------> 2993 user requests service A 2994 -------(8)---------> 2996 Access Request 2997 {RADIUS BASE AVPS,PPAQ={ 2998 SID="A", RGROUP=1}} 2999 -------(9)--------> 3000 forwards message 3001 -----(10)---------> 3003 [allocates 50 min 3004 quota] 3006 Access Response 3007 {RADIUS BASE AVPS, 3008 PPAQ={QID=7, DQ=3000sec 3009 poolID=1,RGROUP=1, SID="A" 3010 mult=1747.63}} 3012 <---------(11)--------------- 3013 forwards message 3014 <----(12)-------- 3016 user requests service B 3017 -------(13)--------> 3019 Pool 1 close to exhaustion 3021 Access Request 3022 {RADIUS BASE AVPS, 3023 PPAQ={QID=5, VQ=4MB, 3024 REASON=QUOTA REACHED, 3025 PoolID=1, mult=1} 3026 PPAQ={QID=7, DQ=3300sec 3027 REASON=QUOTA REACHED, 3028 PoolID=1, mult=1747.63, 3029 SID="A",RGROUP=1}} 3030 -------(14)---------> 3032 forwards message 3033 -------(15)-------> 3035 [allocates another 3036 3 MB to access service 3037 and 30 minutes to 3038 service "A"] 3040 Access Response 3041 {RADIUS BASE AVPS, 3042 PPAQ={QID=8, VQ=8MB, 3043 PoolID=1, mult=1, RGROUP=1}, 3044 PPAQ={QID=9, DQ=4800sec 3045 PoolID=1, mult=1747.63, 3046 SID="A"}} 3047 <----------(16)-------------- 3048 forwards message 3049 <------(17)-------- 3051 user logs off 3052 ------(18)------- 3054 Access Request 3055 {RADIUS BASE AVPS, 3056 PPAQ={QID=8, VQ=6.5MB, 3057 REASON=ACCESS SERV TERMINATED, 3058 PoolID=1, mult=1} 3059 PPAQ={QID=9, DQ=5400sec 3060 REASON=ACCESS SERV TERMINATED, 3061 PoolID=1, mult=1747.63, 3062 SID="A",RGROUP=1}} 3063 -------(19)---------> 3065 forwards message 3066 -------(20)-------> 3068 [reimburses 3069 user account] 3071 AA Response 3072 {RADIUS BASE AVPS 3073 <------(21)-------- 3074 AA Response 3075 {RADIUS BASE AVPS 3076 <------(22)-------- 3078 Figure 14: Example message flow with resource pools and rating groups 3080 The user logs on (1). The PPC sends a RADIUS Access Request message 3081 to the home AAA server (2), and includes the prepaid-specific PPAC 3082 AVP, indicating that multiple services, rating groups and resource 3083 pools are supported. Note that no PPAQ AVP with Update 3084 Reason="initial request" is included (see Section 3.7.1). The home 3085 AAA server then authenticates the user and authorizes the access 3086 service, as is usual in RADIUS (3). Note that the PPAC AVP is 3087 appended by the PPC in at least the last message that is sent to the 3088 home AAA server during this possibly multiple-round exchange. 3090 If authentication and authorization is successful (in this example 3091 this is assumed), the home AAA server forwards the final Access 3092 Request to the PPS (4). The PPS identifies the user's prepaid 3093 account from the included base RADIUS AVPs, and determines the 3094 capabilities of the PPC from the PPAC attribute. Assuming that 3095 sufficient funds are available in the user's prepaid account, the PPS 3096 reserves some of these and rates the service. In this example, the 3097 PPS reserves 5 Euros and determines that the access service is rated 3098 at 1 Euro per MB. In anticipation that the user requests more 3099 chargeable services throughout this prepaid session, and since this 3100 is supported by the PPC, the PPS further associates a resource pool 3101 with this reservation, in this example PoolID=1. The PPC also 3102 specifies the multiplier = 1 for the access service. Note that, 3103 since 5MB = 5242880 octets, 1 unit in the resource pool corresponds 3104 to 5 / 5242880 euros, which is about 0.000095367431640625 Eurocents. 3105 (However, the PPC does not need to know that.) Moreover, the PPS 3106 associates the QuotaIdentifier QID=5 to this quota reservation. This 3107 identifier can be used to later uniquely identify the prepaid 3108 session, user, account, etc. The resulting Access Accept message is 3109 sent to the home AAA server (5) and forwarded to the PPC (6). 3111 Upon reception of message (6), the PPC provides the access service to 3112 the user and meters it accordingly. That is, for every octet 3113 consumed, the PPC subtracts 1 unit (since the multiplier is 1) from 3114 the resouce pool with PoolID=1. 3116 At some point in time, the user requests another chargeable service, 3117 namely service A (8). The PPC generates an Access Request that 3118 contains the usual RADIUS attributes and the Service-ID identifying 3119 service A (9). The PPC has determined that service A is rated in an 3120 identical way as at least one more service. Thus, service A has been 3121 configured to belong to a rating group, in this example the group 3122 with Rating-Group-ID=1. This identifier is included is message (9), 3123 which is then forwarded to the PPS (10). 3125 Upon reception of message (10), the PPS identifies the user and his 3126 account from the base RADIUS attributes, the fact that a prepaid 3127 session is ongoing, and determines that enough credit remains in the 3128 prepaid account in order for service A to be provided. The PPS also 3129 determines that service A is rated at 0.10 euros per minute. The PPS 3130 decides to reserve another 5 euros from the users account; this 3131 corresponds to 50 minutes or, as encoded in the DurationQuota AVP, 3132 3000 seconds. As service A draws from the same prepaid account as 3133 the access service, the PPS associates this reservation with the same 3134 resource pool as the previous reservation (QID=5), namely the pool 3135 with PoolID=1. Note that, in order for the abstract units in the 3136 pool to be consistent, the multiplier has to be 1747.63. This is 3137 because each second corresponds to about 0.10 / 60 = 0.00167 euros, 3138 which is about 1747.63 times the value of an abstract resource pool 3139 unit, as this was determined by the first allocation of quota to the 3140 pool (i.e. 0.000095367431640625 Eurocents). Since this is a new 3141 quota reservation, the PPS also allocates a new QuotaIdentifier to 3142 it, in this example QID=7. The resulting RADIUS message is sent to 3143 the home AAA server (11) and forwarded to the PPC (12). 3145 Upon reception of message (12), the PPC adjusts the units in resource 3146 pool 1. That is, it first determines how much quota had been 3147 allocated to service A in the past, and subtracts this from the quota 3148 reservation found in the message. Since this is the first quota 3149 reservation for service A, there is nothing to subtract. Thus, it 3150 adds 3000 * 1747.63 = 5242890 units to the pool and remembers that 3151 3000 seconds have been allocated to service A during this prepaid 3152 session. The PPC then provides service A to the user, and meters it 3153 against resource pool 1. That is, for every second it subtracts 3154 1747.63 units from the pool. 3156 At some point in time, the user requests service B (13). The PPC 3157 determines that service B is rated exactly in the same way as service 3158 A, i.e. that they belong to the same rating group, namely the one 3159 with Rating-Group-ID=1. Since this rating group has been effectively 3160 authorised by the allocation of quota with QID=7, the PPC provides 3161 service B to the user immediately. It is rated in the same way as 3162 service A, i.e. for every second provided, 1747.63 units are 3163 subtracted from credit pool 1. 3165 At some point in time, resource pool 1 is close to exhaustion. (For 3166 example, the PPC may determine that the pool is "close to exhaustion" 3167 when has less than 10% its initial amount of units.) At that point, 3168 the PPC needs to ask for replenishment for the pool. Suppose that, 3169 at that point in time, 4MB of "access service", 45 minutes of 3170 "service A", and 10 minutes of "service B" were provided to the user. 3171 Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304 3172 + 5767179 = 9961483 abstract service units from the pool. The PPC 3173 constructs an Access Request message that reports the usage for the 3174 "access service" and "service A". This message contains two PPAQ 3175 AVPS, is sent to the home AAA server (14) and forwarded to the PPS 3176 (15). Note that is the message it appears that "service A" has 3177 consumed more than it was allocated (i.e. 55 minutes although only 50 3178 minutes were initially allocated to it). This is not a a problem 3179 since the PPS knows that "service A" was drawing from the same pool 3180 as the "access service" and that the "access service" did only 3181 consume 4 out of the 5 MB it was allocated. 3183 Upon reception of message (15), the PPS subtracts 4 euros from the 3184 user's account for the "access service" and another 5.5 euros for 3185 "service A". (This includes the charge incurred by "service B" up to 3186 that point in time, although the PPS is not aware of "service B" 3187 being provisioned to the user.) The PPS then determines that 3188 sufficient funds remain in the prepaid account in order for both 3189 services to be continued. The PPS decides to reserve another 3MB for 3190 the access service and 30 minutes for "service A". This corresponds 3191 to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a 3192 cumulative manner, the PPAQ attribute that grants the quota for the 3193 "access service" contains a Volume-Quota AVP of 8MB (8388608 octets), 3194 which is the 5MB that were initially allocated, plus the 3MB 3195 allocated now. The resource pool identifier is, as previously, 3196 PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants 3197 quota for "service A" contains 4800 seconds (the initial 3000 plus 3198 1800 that correspond to the 30 additional minutes). Again, the 3199 PoolID=1 and multiplier=1747.63. The resulting Access Response 3200 message is sent to the home AAA server (16) and forwarded to the PPC 3201 (17). 3203 When the PPC received message (17) it checks how much quota has been 3204 allocated previously to the "access service". It finds that the 3205 answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets) 3206 that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets) 3207 have not yet been added to resource pool 1. The PPC thus adds 3208 3145728 abstract units to resource pool 1 (since the multiplier is 3209 1). The PPC then acts similarly on the other PPAQ attribute that 3210 exists in message (17). That is, the PPC determines that 3000 3211 seconds of quota for "service A" had already been added to the pool. 3212 Thus only 1800 out of the 4800 should be additionally added to the 3213 pool. Since the applicable multiplier here is 1747.63, the PPC adds 3214 further 3145734 abstract units to the pool 1. 3216 The PPC then continues to provide the access service, "service A" and 3217 "service B" to the user, and meters them against the pool, as 3218 previously. 3220 At some point the user logs off (18). The PPC must then report how 3221 many resources were consumed, so that the PPC can subtract the 3222 appropriate monetary amount from the user's prepaid account. To this 3223 end the PPC constructs an Access Request message with two PPAQ AVPs; 3224 one for the access service and one for "service A". Suppose that, in 3225 total, 6.5MB were consumed by the access service, 70 minutes were 3226 consumed by "service A" and 20 minutes by "service B". The PPC 3227 reports 6.5MB (6815744 octets) and 90 minutes (5400 seconds) in its 3228 final message (19). This is forwarded to the PPS which determines, 3229 from the previous records, that the access service consumed another 3230 2.5MB (since 4MB out of the 6.5MB were already reported in message 3231 (15), and that "service A" consumed further 600 seconds. This 3232 corresponds to 2.5 + (600/60)*0.1 = 2.5+1=3.5 euros. Thus, the PPS 3233 only subtracts 2.5 out of the 6 previously reserved euros from the 3234 user's prepaid account and responds with an Access Response as 3235 required by the RADIUS base specification. 3237 The home AAA server likewise responds with an Access Response. 3239 Authors' Addresses 3241 Avi Lior 3242 Bridgewater Systems 3243 303 Terry Fox Drive 3244 Ottawa, Ontario Suite 100 3245 Canada 3247 Email: avi@bridgewatersystems.com 3249 Parviz Yegani 3250 Cisco 3251 Mobile Wireless Group, Cisco Systems 3252 3625 Cisco Way, San Jose, California 95134 3253 USA 3255 Email: pyegani@cisco.com 3257 Kuntal Chowdhury 3258 Starent Networks 3259 30 International Place, 3rd Floor 3260 Tewksbury, MA 01876 3261 USA 3263 Email: kchowdhury@starentnetworks.com 3265 Hannes Tschofenig 3266 Siemens 3267 Otto-Hahn Ring 6 3268 Munich, Bavaria 81739 3269 Germany 3271 Email: hannes.tschofenig@siemens.com 3273 Andreas Pashalidis 3274 Siemens 3275 Otto-Hahn Ring 6 3276 Munich, Bavaria 81739 3277 Germany 3279 Email: andreas.pashalidis@siemens.com 3281 Intellectual Property Statement 3283 The IETF takes no position regarding the validity or scope of any 3284 Intellectual Property Rights or other rights that might be claimed to 3285 pertain to the implementation or use of the technology described in 3286 this document or the extent to which any license under such rights 3287 might or might not be available; nor does it represent that it has 3288 made any independent effort to identify any such rights. Information 3289 on the procedures with respect to rights in RFC documents can be 3290 found in BCP 78 and BCP 79. 3292 Copies of IPR disclosures made to the IETF Secretariat and any 3293 assurances of licenses to be made available, or the result of an 3294 attempt made to obtain a general license or permission for the use of 3295 such proprietary rights by implementers or users of this 3296 specification can be obtained from the IETF on-line IPR repository at 3297 http://www.ietf.org/ipr. 3299 The IETF invites any interested party to bring to its attention any 3300 copyrights, patents or patent applications, or other proprietary 3301 rights that may cover technology that may be required to implement 3302 this standard. Please address the information to the IETF at 3303 ietf-ipr@ietf.org. 3305 Disclaimer of Validity 3307 This document and the information contained herein are provided on an 3308 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3309 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3310 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3311 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3312 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3313 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3315 Copyright Statement 3317 Copyright (C) The Internet Society (2006). This document is subject 3318 to the rights, licenses and restrictions contained in BCP 78, and 3319 except as set forth therein, the authors retain all their rights. 3321 Acknowledgment 3323 Funding for the RFC Editor function is currently provided by the 3324 Internet Society.