idnits 2.17.00 (12 Aug 2021) /tmp/idnits62684/draft-lior-radius-prepaid-extensions-11.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 3015. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3005. ** 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 that contains a Service-Id is associated with that Service. A PPAQ 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 or 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 (June 23, 2006) is 5810 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 524 -- Looks like a reference, but probably isn't: 'RFC3576' on line 1124 == Missing Reference: '3576' is mentioned on line 1196, but not defined -- Looks like a reference, but probably isn't: 'DIAMETERCC' on line 1366 -- Looks like a reference, but probably isn't: 'RFC2865' on line 1381 -- Looks like a reference, but probably isn't: 'RFC2869' on line 1783 == Unused Reference: '1' is defined on line 2258, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 2261, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 2264, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2267, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2269, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2272, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2276, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2280, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2286, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2869 (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 (~~), 14 warnings (==), 13 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: December 25, 2006 P. Yegani 5 Cisco 6 K. Chowdhury 7 Starent Networks 8 H. Tschofenig 9 A. Pashalidis 10 Siemens 11 June 23, 2006 13 Prepaid extensions to Remote Authentication Dial-In User Service 14 (RADIUS) 15 draft-lior-radius-prepaid-extensions-11.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 December 25, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document specifies an extension to the Remote Authentication 49 Dial-In User Service (RADIUS) protocol that enables service providers 50 to charge for prepaid services. The supported charging models 51 supported are volume-based, duration-based, and based on one-time 52 events. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 58 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7 60 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 10 61 1.3. A simple use case . . . . . . . . . . . . . . . . . . . . 12 62 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 15 63 2.1. Multiple Concurrent Services . . . . . . . . . . . . . . . 15 64 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 15 65 2.3. Complex Rating Functions . . . . . . . . . . . . . . . . . 17 66 2.4. One-time Charging . . . . . . . . . . . . . . . . . . . . 17 67 2.5. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 18 68 2.6. Support for Roaming . . . . . . . . . . . . . . . . . . . 20 69 2.7. Dynamic Termination . . . . . . . . . . . . . . . . . . . 20 70 2.8. Querying and Rebalancing . . . . . . . . . . . . . . . . . 20 71 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 3.1. Authentication and Authorization Operation . . . . . . . . 22 73 3.2. Session Start Operation . . . . . . . . . . . . . . . . . 24 74 3.3. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24 75 3.4. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26 76 3.4.1. Unsolicited Session Termination Operation . . . . . . 26 77 3.4.2. Unsolicited Change of Authorization Operation . . . . 27 78 3.5. Termination Operation . . . . . . . . . . . . . . . . . . 27 79 3.6. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27 80 3.7. Operation Considerations for Multiple Services . . . . . . 28 81 3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 29 82 3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29 83 3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 30 84 3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 30 85 3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 30 86 3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 30 87 3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 31 88 3.7.8. Accounting Considerations . . . . . . . . . . . . . . 31 89 3.7.9. Interoperability with Diameter Credit Control 90 Application . . . . . . . . . . . . . . . . . . . . . 31 91 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 33 92 4.1. PPAC Attribute . . . . . . . . . . . . . . . . . . . . . . 33 93 4.2. Session Termination Attribute . . . . . . . . . . . . . . 34 94 4.3. PPAQ Attribute . . . . . . . . . . . . . . . . . . . . . . 35 95 4.3.1. Quota Identifier AVP . . . . . . . . . . . . . . . . . 35 96 4.3.2. VolumeQuota AVP . . . . . . . . . . . . . . . . . . . 36 97 4.3.3. VolumeThreshold AVP . . . . . . . . . . . . . . . . . 36 98 4.3.4. DurationQuota AVP . . . . . . . . . . . . . . . . . . 36 99 4.3.5. DurationThreshold AVP . . . . . . . . . . . . . . . . 36 100 4.3.6. ResourceQuota AVP . . . . . . . . . . . . . . . . . . 36 101 4.3.7. ResourceThreshold AVP . . . . . . . . . . . . . . . . 37 102 4.3.8. Value-Digits AVP . . . . . . . . . . . . . . . . . . . 37 103 4.3.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . 37 104 4.3.10. Update-Reason AVP . . . . . . . . . . . . . . . . . . 37 105 4.3.11. PrepaidServer AVP . . . . . . . . . . . . . . . . . . 38 106 4.3.12. Service-ID AVP . . . . . . . . . . . . . . . . . . . . 38 107 4.3.13. Rating-Group-ID AVP . . . . . . . . . . . . . . . . . 39 108 4.3.14. Termination-Action AVP . . . . . . . . . . . . . . . . 39 109 4.3.15. Pool-ID AVP . . . . . . . . . . . . . . . . . . . . . 39 110 4.3.16. Pool-Multiplier AVP . . . . . . . . . . . . . . . . . 39 111 4.3.17. Requested-Action AVP . . . . . . . . . . . . . . . . . 39 112 4.3.18. Check-Balance-Result AVP . . . . . . . . . . . . . . . 40 113 4.3.19. Cost-Information AVP . . . . . . . . . . . . . . . . . 40 114 4.4. Prepaid Tariff Switching Attribute (PTS) . . . . . . . . . 41 115 4.4.1. VolumeUsedAfterTariffSwitch AVP . . . . . . . . . . . 42 116 4.4.2. TariffSwitchInterval AVP . . . . . . . . . . . . . . . 42 117 4.4.3. TimeIntervalafterTariffSwitchUpdate AVP . . . . . . . 42 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) . . . . . . . . . . . . . . . . . . . . . 45 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) . . . . . . . . 51 142 5.2.19. Cost-Information Attribute (s->c) . . . . . . . . . . 52 143 5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) . . . . . 52 145 6. Security Considerations . . . . . . . . . . . . . . . . . . . 53 146 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 147 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 55 148 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 149 9.1. Normative References . . . . . . . . . . . . . . . . . . . 56 150 9.2. Informative References . . . . . . . . . . . . . . . . . . 56 151 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 57 152 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 57 153 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 60 154 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 64 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71 156 Intellectual Property and Copyright Statements . . . . . . . . . . 72 158 1. Introduction 160 This document specifies an extension to the RADIUS protocol that 161 enables service providers to perform accounting and charging in an 162 "online" fashion. In particular, they enable the service provider to 163 (a) ensure that subscriber's remaining funds suffice before the 164 service is delivered, and (b) interrupt service provision when the 165 funds are exhausted. Note that these capabilities are typically used 166 in scenarios where the subscriber maintains a prepaid account with 167 the service provider; hence, this extension is called the "prepaid" 168 extension for RADIUS. Also note that the above capabilities are not 169 provided by the base RADIUS protocol. 171 It has been observed that subscribers prefer prepaid accounts to 172 postpaid ones in many circumstances. Indeed, it is expected that 173 offering a "prepaid mode of operation" will enabe service providers 174 to expand their existing customer bases. This is the main business 175 driver behind the extensions defined in this document. The 176 extensions were designed with the following goals in mind. 178 o Make use of existing infrastructure as much as possible (including 179 enabling the interworking of RADIUS-based and Diameter-based 180 infrastructures), and thereby limit the amount of necessary 181 capital expenditures, 183 o provide the ability to rate service requests in an "online" 184 fashion, 186 o provide the ability to charge the user's account prior to service 187 provision, 189 o protect against revenue loss, i.e. to prevent an end user from 190 obtaining service when the available funds do not suffice, 192 o protect against fraud, and 194 o be deployable over dialup, wired and wireless networks. 196 The architecture between the entities that execute the RADIUS 197 protocols, with the extensions defined in this document, assumes that 198 the rating of chargeable events does not occur in the element that 199 provides the service. Instead, the rating may be performed at a 200 dedicated server, termed the "prepaid-enabled AAA server" or simply 201 "prepaid server". Alternatively, the actual rating may occur in an 202 entity behind this prepaid server. Furthermore, business logic may 203 dictate a time-dependent tariff model, for example that the price for 204 a service may switch at 8pm from a high to a low tariff. The 205 extensions defined in this document support such scenarios. 207 Furthermore, this document assumes an architecture where a "quota 208 server" is available which, through co-ordination with the rating 209 entity and a centralized account balance manager, is able to provide 210 a quota indication for a particular user when requested. This quota 211 server may or may not coexist in the prepaid server. 213 1.1. Terminology 215 o Network Access Server (NAS): As defined in RADIUS. 217 o Prepaid client (PPC): The entity which triggers the RADIUS message 218 exchange, including the prepaid extensions defined in this 219 document. The PPC typically resides in the NAS. 221 o Prepaid Server (PPS): The entity that interacts with the PPC using 222 the RADIUS prepaid extensions defined in this document. 224 o Home Network: The network which contains the user profile and the 225 user's prepaid account. 227 o Authorize-Only Access Request: A RADIUS message of type "Access 228 Request" (code field=1) that contains a "Service-Type" AVP 229 (type=6) with value "Authorize-Only". 231 1.2. Overview 233 This section provides an overview of the prepaid charging models and 234 architectures, which are supported by the extensions described in 235 this document. 237 A number of models of how to charge customers for data services in a 238 prepaid manner are supported, as follows. 240 o Volume-based charging (e.g. 2 Cents/KiloByte). 242 o Duration-based charging (e.g. 3 Cents/minute). 244 o Subscription-based charging (e.g. 10 Dollars/month). 246 o Event-based charging (e.g. 7 Cents/URL or email) . 248 This draft assumes that the user maintains a prepaid account with his 249 home network. This account may be used to fund multiple services, 250 some of which may use the extensions defined in this document, and 251 some may use other mechanisms. The interworking of these mechanisms 252 is outside the scope of this document. Similarly, the means by which 253 the subscriber obtains funds is also outside the scope of this 254 document. 256 1.2.1. Architectural Model 258 The protocol extensions described in this draft assumes that the 259 following entities are present in the network architecture. 261 o Service Access Device (SAD): This entity provides a data service 262 to the users, and typically coincides with the NAS. The SAD 263 executes the RADIUS client which, for the purposes of this 264 document, is termed the "PrePaid Client" (PPC). When the prepaid 265 service is used the SAD collects service event information and 266 reports it while services are provided to the user. This event 267 information is sent to the PPS using the extensions defined in 268 this document. 270 o The PPS: The RADUIS server that supports the prepaid extensions 271 defined in this document. If real-time credit control is 272 required, the PPC (SAD) contacts the PPS with service event 273 information included before the service is provided. The PPS 274 performs a credit check and allocates a portion of the available 275 credit to the service event. 277 o The rating entity: This entity converts the credit that is 278 allocated by the PPS into a time or volume amount, called the 279 "quota". This quota is then returned to the requesting PPC (SAD) 280 (via the PPS). The rating entity may also determine that during 281 service provision a tariff switch will occur. In this case the 282 rating entity will include details of when exactly tariff switch 283 will occur. 285 The requesting PPC (SAD) meters the consumption of the service 286 according to the instructions provided by the PPS. After service 287 completion, or on reception of a subsequent request for service, the 288 PPS deducts the corresponding amount of credit from the user account. 289 When a user terminates an on-going service, the PPC informs the PPS 290 with a suitable indication about the unused portion of the allocated 291 quota. The PPS then refunds the user account accordingly. Note that 292 multiple PPSs may be deployed for reasons of redundancy and load 293 sharing. The system MAY also employ multiple rating servers. 295 accounting 296 +------------+ +-----------+ protocol +--------------+ 297 | User |<---------->| Service | | | 298 | | IEEE 802.1x| Access |<------------>| Accounting | 299 | Device | PANA | Device |<-----+ | Server | 300 +------------+ IKEv2 +-----------+ | +--------------+ 301 ... etc (PPC) | 302 | 303 | +--------------+ 304 +------>| Prepaid | 305 prepaid | Server | 306 protocol +--------------+ 308 Figure 1: Basic prepaid architecture 310 The PPS and the accounting server in this architecture MAY be 311 combined. The SAD must have the ability to meter the consumption of 312 a prepaid data session. This metering is typically based on time 313 (i.e. seconds) or volume (i.e. octets). 315 The device running the PPC may also have "Dynamic Session 316 Capabilities" such as the ability to terminate a data session or 317 change the filters associated with a specific data session by 318 processing "Disconnect" messages and "Change of Authorization" 319 messages as per RFC 3576. 321 This document assumes that the PPS is used as the AAA server. There 322 are three types of AAA server, as follows. 324 o The AAA server in the home network (HAAA), which is responsible 325 for authentication of the subscriber. In addition, the HAAA 326 communicates with the PPS using the RADIUS protocol in order to 327 authorize subscribers. 329 o The AAA server in the visited network (VAAA) which exists only in 330 roaming scenarios and is responsible for forwarding the RADIUS 331 messages to the HAAA. The VAAA may also modify the messages. 332 Note that, in certain roaming deployments, the visited network may 333 be connected to the home network via one or more broker networks. 335 o The AAA server in one of the aforementioned broker networks 336 (BAAA), which is responsible for forwarding messages and does not 337 play an active role in the prepaid data service delivery. A BAAA 338 obviously exists only in those roaming deployments where the VAAA 339 and the HAAA are connected via the BAAA of a broker network. 341 This document assumes that the PPS communicates with the HAAA for the 342 purposes of authentication and authorisation. The PPS, in turn, 343 interfaces to entities which 345 o keep the subscriber's account balance (balance manager), 347 o rate access service requests in real-time (Rating Engine), and 349 o manage quota for a particular prepaid service (Quota Server). 351 The above entities belong to the service provider's backend 352 infrastructure and are outside the scope of this specification. In 353 particular, as far as this specification is concerned, they are 354 assumed to exist in the PPS. Three deployment scenarios are 355 presented in the remainder of this section. The first scenario is 356 depicted in Figure 2. In this scenario, the SAD, which runs the PPC, 357 the HAAA, and the PPS are located in the same provider network. 359 The subscriber's device establishes a connection with one of possibly 360 multiple SADs in the network. The selected SAD communicates with a 361 HAAA server (directly or indirectly). 363 The interface between the HAAA and the PPS is implemented using the 364 RADIUS protocol together with the extensions described in this 365 document. However, in cases where the PPS does not implement the 366 RADIUS protocol, the implementation would have to map the 367 requirements defined in this document to a functionally equivalent 368 protocol. 370 +------+ +-----+ 371 | | | | 372 +--------+ +--------+ +--| HAAA |--+--| PPS | 373 | | | | | | | | | | 374 | Subscr.| | Service| | +------+ | +-----+ 375 | |---| Access |--+ | 376 | Device | | Device | | +------+ | +-----+ 377 | | | | | | | | | | 378 +--------+ +--------+ +--| HAAA |--+--| PPS | 379 | | | | 380 +------+ +-----+ 382 Figure 2: Basic prepaid access architecture 384 The second scenario, depicted in Figure 3, is based on a static 385 roaming architecture that is typical of a wholesale scenario for 386 Dial-Up users or a broker scenario used in Dial-Up or WLAN roaming 387 scenarios. 389 +----+ +----+ +----+ +-----+ 390 | | | | | | | | 391 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 392 | | | | | | | | | | | | | | | | 393 |Sub | |Service| | +----+ | +----+ | +----+ | +-----+ 394 | |--|Access |-+ | | | 395 |Device| |Device | | +----+ | +----+ | +----+ | +-----+ 396 | | | | | | | | | | | | | | | | 397 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 398 | | | | | | | | 399 +----+ +----+ +----+ +-----+ 401 Figure 3: Static roaming prepaid architecture 403 Like in the basic prepaid architecture, the subscriber device 404 establishes a connection with the SAD. The SAD communicates with the 405 VAAA using the RADIUS protocol. The VAAA, in turn, communicates 406 using the RADIUS protocol with BAAA servers in the broker network. 407 There may be more than one Broker Network between the Visited Network 408 and the Home Network. The Home Network is the same as in the 409 architecture depicted in Figure 2. 411 Broker AAA (BAAA) servers MUST support the Message-Authenticator(80) 412 attribute as defined in RFC 2869. If they are used, they forward the 413 RADIUS packets as usual to the appropriate RADIUS servers. 415 Accounting messages are not needed to deliver a prepaid service. 416 However, accounting messages can be used to keep the PPS up to date 417 as to what is happening with the prepaid data session. Therefore, a 418 BAAA SHOULD deliver RADIUS Accounting messages using the pass through 419 mode described in RFC 2866. 421 1.2.2. Motivation 423 Why not use existing RADIUS attributes to construct a protocol for 424 prepaid scenarios? This could lead to a solution where no code has 425 to be modified at existing devices. 427 It is indeed possible to construct a solution for prepaid scenarios 428 using existing RADIUS attributes. The RADIUS server would send an 429 Access-Accept message containing a Session-Timeout(27) and include a 430 Termination-Action(29) in the RADIUS-request. Upon receiving the 431 Access-Accept message, the NAS would meter the duration of the 432 session and upon termination of the session the NAS would generate an 433 Access-Request message again. The RADIUS server would then re- 434 authenticate the session and reply with an Access-Accept message 435 indicating the amount of additional time in a Session-Timeout(27). 436 Alternatively, it could respond with an Access-Reject message if 437 there were no more resources in the user account. 439 Moreover, if the user terminates the session prematurely, the NAS 440 could indicate this in the accounting stream so that unused funds can 441 be returned into the prepaid user account. 443 Unfortunately, the above "solution" has a number of drawbacks, 444 including the following. 446 o It only supports time-based charging. The solution presented in 447 this document supports multiple charging metrics. 449 o Using accounting messages to recoup unused time may be problematic 450 because RADIUS accounting messages are not delivered in real-time. 451 A RADIUS server may store-and-forward accounting messages in 452 batches. Thus, relying on accounting messages for the purposes of 453 prepaid may cause revenue leakage. The solution presented in this 454 document does not rely on Accounting packets at all. It uses 455 Access-Request messages, which are required to flow through any 456 network in real-time. 458 o Session-Timeout(27) is not a mandatory attribute. If a prepaid 459 subscriber is served by a NAS that does not adhere to Session- 460 Timeout then that subscriber may use the service for an 461 undetermined period of time. 463 o Termination-Action(29) presents its own issues. Firstly, the 464 behaviour of Termination-Action(29) is not mandatory. Secondly, 465 according to RFC 2865, Termination-Action fires when the provision 466 of the service has completed. However, service should not be 467 terminated when negotiating additional quota, because this should 468 happen in a manner transparent to the subscriber. Due to the fact 469 that Termination-Action occurs when the service is completed, it 470 is unclear whether or not user experience would be affected if 471 this attribute would be used in a prepaid scenario. The RADIUS 472 server might even allocate a new IP address to the subscriber 473 device after a Termination-Action. Also, the RADIUS server has no 474 way of telling why a given Access-Request message was generated. 475 The RADIUS server might have to wait for the corresponding 476 accounting packet to determine the reason. Finally, re- 477 authenticating the subscriber may take too long. The solution 478 presented in this document allows quota replenishing to occur 479 without affecting user experience. No re-authentication is 480 required and quotas can be negotiated before the available credit 481 actually runs out. 483 o Due to the fact that the standard RADIUS attributes are not 484 mandatory, the correct prepaid operation is really an act of faith 485 on the part of the RADIUS server. If Session-Timeout(27) and/or 486 Termination-Action(29) are not supported, the prepaid subscriber 487 might be able to obtain the service for free. The solution 488 described in this document requires that a prepaid-aware SAD 489 informs the RADIUS server, regardless of whether or not the latter 490 supports the prepaid extensions. The RADIUS server can then 491 determine whether or not service should be granted. For example, 492 if a prepaid subscriber is connected to a NAS that does not 493 support prepaid, the RADIUS server can either instruct the NAS to 494 tunnel the traffic to another entity in the home network (e.g. an 495 Home Agent) that supports prepaid, or cause it to provide only a 496 restricted service. 498 The solution presented in this document requires the support of two 499 mandatory and one optional attribute. Furthermore, it does not 500 require a great amount of additional code at a NAS that already 501 supports time or volume metering. The solution requires that RADIUS 502 entities advertise their prepaid capabilities in an Access-Request 503 and that they generate an Access-Request packet with Service- 504 Type="Authorize-Only" in order to obtain more quota when or before 505 the current quota is used up. It also requires the NAS to send an 506 Access-Request with Service-Type="Authorize-Only" when the session 507 terminates in order to refund the subscriber account. 509 1.3. A simple use case 511 This section describes the sequence of events in a simple RADIUS 512 prepaid transaction. 514 1. When an end host attaches to a network (for example, using PPP or 515 PANA), as usual, the NAS (SAD) that is servicing the subscriber 516 uses the AAA infrastructure in order to authenticate and 517 authorize the subscriber with respect to the requested service. 518 In order to do this, it sends a RADIUS Access-Request to the AAA 519 server. This Access-Request contains the subscriber's 520 credentials and may contain the prepaid capabilities of the SAD. 521 Prepaid capabilities MUST be included if the SAD supports them. 523 2. The authentication procedure proceeds. This may involve several 524 message exchanges such as in EAP [RFC2284]. Once the subscriber 525 has been successfully authenticated, the home AAA server 526 determines that the subscriber is a prepaid subscriber and 527 requests authorisation from the PPS. This request MUST include 528 the prepaid capabilities of the serving SAD. 530 3. The PPS, possibly with the help of the backend infrastructure, 531 validates that the subscriber has a prepaid account and that the 532 account is active. It further validates that the SAD has the 533 appropriate prepaid capabilities. If all is in order, the PPS 534 authorises the subscriber to use the network. Otherwise it 535 rejects the request. The decision is sent to the AAA system in 536 the form of a response message. In the case of success, this 537 message contains attributes that indicate the allocation of a 538 portion of the subscriber credit. This portion is called the 539 "initial quota" and is expressed in units of time or volume. The 540 response may also include a threshold value. Note that only a 541 portion of the user's funds is allocated because the user may be 542 engaged in other services that may draw on the same account. For 543 example, the user may be engaged in a data session and a voice 544 session. Although these two services would draw from the same 545 account, they form separate parts of the overall system. If the 546 entire quota was allocated to the data session then the user 547 would have no more funds for a voice session. 549 4. The AAA system incorporates the attributes received from the PPS 550 into an Access-Accept message that it sends to the SAD. Note 551 that the AAA system is responsible for authorizing the service 552 whereas the prepaid system is responsible for prepaid 553 authorization. 555 5. Upon receiving the Access-Response, the SAD starts the prepaid 556 data session and meters the session based on time or volume, as 557 indicated in the message. 559 6. Once the consumption approaches the allocated limit (as expressed 560 by the threshold), the SAD will request additional quota. Re- 561 authorization for additional quota flows through the AAA system 562 to the PPS. The PPS revalidates the subscriber account and 563 subtracts the previously allocated quota from the current 564 balance. If there is remaining balance, it reauthorizes the 565 request with an additional quota allotment. Otherwise, the PPS 566 rejects the request. Note that the replenishment of the quota is 567 a re-authorization procedure and does not require the subscriber 568 to authenticate himself again. 570 7. Upon receiving a re-allotment of the quota, the SAD continues to 571 provide the data service until the new threshold is reached. If 572 the request for additional quota cannot be fulfilled then the SAD 573 lets the subscriber use the remaining quota and terminates the 574 session. Alternatively, instead of terminating the session, the 575 SAD may restrict the data session such that the subscriber can 576 only reach a particular web server. This web server maybe used 577 to allow the subscriber to replenish his account. This 578 restriction can also be used to allow new subscribers to set up 579 prepaid accounts in the first place. 581 8. Should the subscriber terminate the session before the quota is 582 exhausted, the remaining balance allotted to the session MUST be 583 refunded into his account. 585 Note that the subscriber may have disconnected while the Access 586 Device is waiting for the initial quota. The entire allocated quota 587 will have to be credited back to the subscribers account in this 588 case. Also note that the PPS maintains session state for the 589 subscriber. This state includes how much account balance was 590 allocated during the last quota enquiry and how much is left in the 591 account. Therefore, it is required that all messages about the 592 session reach the same (and correct) PPS. 594 For a simple message flow, along the lines of this use case, please 595 see Appendix A. 597 2. Supported Features 599 This section describes the features that are supported by the 600 extensions specified in this document. 602 2.1. Multiple Concurrent Services 604 Examples of services that the user may be using are browsing the web, 605 participating in a VoIP conversation, watching streaming video and 606 downloading a file. Some operators may want to distinguish between 607 these services. Some services are charged at different rates and 608 services may be metered differently. Therefore, the prepaid solution 609 needs to be able to distinguish services, and allocate quota to the 610 services using different unit types (time, volume) and allow for 611 those quotas to be consumed at different rates. 613 +---------+ 614 | Session | 615 +---------+ 616 | 1 617 V N 618 +--------------+ 1 : 1 +-------+ 619 | Service |------>| Quota | 620 | (service-Id) | +-------+ 621 +--------------+ 623 Figure 4: Multiple services within a single session 625 As shown in Figure 4, a session may be associated with multiple (N) 626 services. Each service is identified by a service identifier 627 (Service-ID). The format of the Service-ID is not in the scope of 628 this document but it could be expressed as an IP flow using the 629 5-tuple {Source-IP and Port, Destination-IP and Port, protocol type}. 630 Each service is associated with a quota metric. An example message 631 flow that involves multiple such services within a single session is 632 given in the appendix. 634 2.2. Resource Pools 636 When working with multiple services a new problem arises because one 637 service may consume its quota faster than another service. When the 638 user balance is close to exhaustion, a situation could arise where 639 one service is unable to obtain quota while another service has 640 plenty of quota remaining. Unless the quotas can be rebalanced, the 641 SAD would then have to terminate the former service. Moreover, if 642 each service generates a certain amount of RADIUS prepaid traffic. 643 In an environment with many users and chargarble services, this 644 amount of traffic is considerable and could cause undesirable network 645 congestion. 647 One method to circumvent the above situation is to use a so-called 648 "resource pool". Resource pools enable the allocation of resources 649 to multiple services of a session by allocating resources to a pool 650 and have services draw their quota from the pool at a rate 651 appropriate to that service. When the quota that has been allocated 652 to the pool is close to exhaustion, the entire pool (rather than 653 individual services) is replenished. 655 +-----------+ 656 | Service-A |-----+ +--------+ 657 +-----------+ | Ma | | 658 +-------->| | 659 | Pool | 660 +-------->| (1) | 661 +-----------+ | Mb | | 662 | Service-B |-----+ +--------+ 663 +-----------+ 665 Figure 5: Resource pool example 667 As shown in Figure 5, Service-A and Service-B are bound to Pool(1). 668 Ma and Mb are the pool multipliers (that are associated with 669 Service-A and Service-B respectively) that determine the rate at 670 which Service-A and Service-B draw from the pool. 672 The pool is initialized by taking the quota allocated to service n 673 and multiplying it by Mn. Therefore, the amount of resources 674 allocated to a pool is given by Poolr = Ma*Qa + Mb*Qb + . . ., where 675 Qn denotes the amount of quota that is allocated to service n. 676 Further, the pool is considered to be empty if 678 Poolr <= Ca*Ma + Cb*Mb + . . ., 680 Figure 6 682 where Ca and Cb are resources consumed by Service-A and Service-B 683 respectively. 685 Note that the resources assigned to the pool are not associated with 686 a metric. That is, Service-A can be rated at $1 per MB and Service-B 687 can rated at $0.10 per minute. In this case if $5 worth of resources 688 are allocated for service-A to the pool and if Ma = 10, then 50 units 689 would be placed into the pool. If a further $5 are allocated for 690 service-B to the pool, then M=1 and 50 units are deposited into the 691 pool. The pool would then have a sum of 100 units to be shared 692 between the two services. The PPC would then meter the services such 693 that each Mbyte used by Service-A will draw 10 units from the pool 694 and each minute used by Service-B will draw 1 unit from the pool. 696 2.3. Complex Rating Functions 698 The rating of a service can be quite complex. While some operators 699 follow linear pricing models, others may wish to apply more complex 700 functions. For example, a service provider may wish to rate a 701 service such that the first N MBytes are free, then the next M Mbytes 702 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 703 per MB. Such a function could be implemented by repeated message 704 exchanges in the prepaid system. 706 To avert the need to exchange many messages while still supporting 707 such complex rating functions, the notion of a "Rating Group" is 708 introduced. A Rating Group are typically configured at the SAD. As 709 shown in Figure 7, a Rating Group is associated with one or more 710 services and defines the rate that the services associated with the 711 Rating Group consume an allocated amount of quota. 713 +--------------+ +--------------+ 714 +-----------+ N 1 | | M 1 | Resource Pool| 715 | Service-A +---------->| Rating Group |------>| or | 716 +-----------+ | | | Quota | 717 +--------------+ +--------------+ 719 Figure 7: Example of a rating group 721 During the usage of a service that is associated with a Rating Group, 722 the PPC sends the ID of the Rating Group to the PPS. The PPS 723 authorises the Rating Group by allocating a quota to it and 724 optionally assigning it to a Resource Pool. When an additional 725 service that belongs to an already authorised Rating Group is 726 instantiated, the PPC does not need to authorize this service. This 727 effectively means that the PPC meters the service such that it draws 728 from the already allocated quota. Therefore, no RADIUS messages need 729 to be exchanged in this case. This limits the amount of traffic 730 between the PPC and the PPS. An example of a flow that uses Rating 731 Groups is given in Appendix A.3 733 2.4. One-time Charging 735 One-time charging is a mode of operation of where the RADIUS prepaid 736 extensions are used for charging of a service that is provided 737 instansteneously, i.e. without an ongoing session. An example of 738 such an event is the purchase of a ring-tone. Subscription based 739 services can also be modeled as a one-time event. In this case the 740 one-time service event is the purchase of a subscription. 742 For a given user, one-time charging may occur in parallel with other 743 charging models. For example, the subscriber may access a website 744 which is metered (based on time or volume) while he also purchases 745 the right to use a ring tone (a one-time-based event). Note: it is 746 up to the service providers to decide whether or not the user will be 747 charged for the download of the tone and also be charged for the time 748 and volume required to download the ring-tone. The facilities 749 provided by this document gives the service provider the capability 750 to achieve their service charging business goals. For example, 751 should the service provider choose not to charge for the download 752 volume or time, then they can treat the download IP flow as a 753 separate service that is not subject to charging. 755 The SAD signals one-time charging to the PPS with an indication that 756 identifies the service and the units that should be debited from the 757 user account. 759 A SAD may decide to perform one-time charging for an event that was 760 triggered by an unauthenticated user. In this case case the SAD will 761 have to authenticate the user before sending the relevant message to 762 the user's home AAA server. 764 Note that one-time charging can also be used to credit the prepaid 765 account. For example, the SAD can return resources to the subscriber 766 by issuing a one-time charge request that includes the amount of 767 resources to be credited into the account. 769 2.5. Tariff Switching 771 The PPC and the PPS may support tariff switching mechanism described 772 in this section. This mechanism is useful if, for example, as shown 773 in Figure 8, traffic before 18:00 is rated at rate r1 and traffic 774 after 18:00 is rated at rate r2. The mechanism requires the PPC to 775 report usage before and after the switch occured. 777 18:00 778 ------------------+----------------- 779 r1 | r2 780 ------------------+----------------- 781 ^ ^ 782 |<----TSI---> | 783 | | 784 Access-Accept Access-Request 785 (quota allocated) (quota consumed) 787 Figure 8: Example of tariff switching 789 The PPC it indicates support for tariff switching by setting the 790 appropriate bit in the PPAC. If the PPS needs to signal a tariff 791 switch time it will send a PTS attribute which indicates the point in 792 time when the switch will occur. This indication represents the 793 number of seconds from current time (TariffSwitchInterval TSI). 795 At some point after the tariff switch the PPC sends another Access- 796 Request, as a result of either the user having logged off or the 797 volume threshold being reached. The PPC reports how much volume was 798 used in total (in a PPAQ attribute) and how much volume was used 799 after the tariff switch (in a PTS VUATS subtype attribute). 801 In situations with multiple tariff switches, the PPS must specify the 802 length of the tariff switch period using the 803 TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute as 804 shown below. 806 18:00 23:30 807 ------------------+---------------------+-------------- 808 r1 | r2 | r3 809 ------------------+---------------------+-------------- 810 ^ ^ ^ 811 |<----TSI---><-----------|-------->|TITSU 812 | | 813 Access-Accept Access-Request 815 Figure 9: Multiple tariff switches 817 When a TITSU is specified in the PTS, the PPC MUST generate an 818 Access-Request within the time after TSI and before TITSU expires. 819 Note that, typically, the PPC will be triggered by the Volume 820 Threshold. However, it is possible that, during period r2, resources 821 are not entirely consumed and, thus, the threshold is not reached. 822 The TITSU attribute ensures that, even in this case, the PPC will 823 generate the new Access-Request in good time. 825 Note that it makes no sense to use the tariff switching mechanism 826 described in this section for services that are metered based on time 827 and the consumption of which is continuous (i.e. without 828 interruption). Also note that separate services flows may have 829 individual tariff periods. 831 2.6. Support for Roaming 833 In certain networks it is essential for prepaid data services to be 834 available to roaming subscribers. Support for both static and 835 dynamic roaming models is needed. In a static roaming scenario the 836 subscriber connects to a foreign network which has a roaming 837 agreement either directly with the home network, or through a broker 838 network. When the subscriber logs into another foreign network, a 839 new login procedure has to be executed. 841 In a dynamic roaming scenario the subscriber may move between 842 networks while maintaining his connection. In such a scenario the 843 data session is seamlessly handed off between the networks. 845 In both roaming scenarios, the subscriber always authenticates 846 himself to the home network. Authorization for the prepaid session 847 and quota replenishing occurs at the home network and more 848 specifically at the PPS where state is being maintained. 850 Dynamic roaming is challenging because a subscriber who established a 851 prepaid data session may move to another Access Device that does not 852 support the prepaid extensions. Even in this case the system should 853 be able to continue the prepaid session. 855 2.7. Dynamic Termination 857 When fraud or an error is detected, either only the affected session, 858 or all sessions of the affected subscriber should be immediately 859 terminated. It may further happen that the prepaid system enters a 860 state where it is unclear whether or not the data session is in 861 progress. Under certain conditions, the system may wish to terminate 862 the session in order to make sure that the user is not charged for 863 this potential inactivity. 865 Certain handoff procedures used in dynamic roaming scenarios require 866 that the system terminates the subscribers prepaid data session at a 867 SAD. This is the case, for example, when time-based prepaid is used 868 and the mobile subscriber performs a dormant handoff. 870 2.8. Querying and Rebalancing 872 It should be possible for the PPS to Query the current resource 873 consumption at a SAD and adjust the user account balance. For 874 example, a request to the PPS is made (e.g. a one-time charging 875 event), the account is depleted and resources have been allocated to 876 the SAD. The PPS should have the ability to query the SAD and if it 877 has the spare resources to reassign the quotas to the SAD and to the 878 pending request. Note that the PPS does not know resource usage 879 until the SAD request for more resources. This can be a long time. 881 In the absence of this capability the PPS can minimize the effect of 882 this phenomenon by allocating small quotas, a practice that results 883 in more message exchanges. 885 3. Operations 887 This section describes the operations that are implemented by a 888 prepaid-enabled NAS (SAD). 890 3.1. Authentication and Authorization Operation 892 The SAD initiates the authentication and authorization procedure by 893 sending a RADIUS Access-Request to the HAAA. Since the SAD has PPC 894 capabilities, it MUST include a PPAC attribute in the RADIUS Access- 895 Request. The PPAC attribute indicates to the PPS which prepaid 896 capabilities are possessed by the SAD. These are required in order 897 to complete the prepaid authorization procedure. Moreover, if the 898 SAD supports the Disconnect-Message or the Change-of-Authorization 899 capabilities, then it SHOULD include the Dynamic-Capabilities 900 attribute. 902 In certain deployments, there may be other ways to terminate a data 903 session, or change authorization of an active session. For example, 904 some SADs provide a session termination service via Telnet or SNMP. 905 In these cases, the AAA server MAY add the Dynamic-Capabilities 906 message to the Access-Request. Upon receiving the Change-of- 907 Authorization message, the AAA server would then be responsible for 908 terminating the session using the means that are supported by the 909 device. 911 If the authentication procedure involves multiple message exchanges 912 (as in EAP), the SAD MUST include the PPAC(TBD) attribute and the 913 Dynamic-Capabilities attribute (if used) in at least the last Access- 914 Request of the authentication procedure. 916 The Access-Request is sent, as usual, to the HAAA, possibly through 917 one or more BAAA. 919 Once the Access-Request arrives at the HAAA, the HAAA authenticates 920 the subscriber. If this fails, the HAAA sends an Access-Reject 921 message to the client. If authentication succeeds, the HAAA 922 determines whether or not the subscriber is a prepaid subscriber. 923 (How this is done is beyond the scope of this document.) If the 924 subscriber is not a prepaid subscriber, then the HAAA responds as 925 usual with an Access-Accept or an Access-Reject message. If the 926 subscriber is a prepaid subscriber then the HAAA SHALL forward the 927 Access-Request to the PPS for further authorization. 929 The Access-Request contains the PPAC(TBD) attribute and the Dynamic- 930 Capabilities attribute if one was included. The User-Name(1) 931 attribute MAY be set to a value that identifies the subscriber. This 932 attribute is used by the PPS to locate his account. For added 933 security, the HAAA MAY also set the User-Password(2) attribute to the 934 password used between the HAAA and the PPS. 936 The PPS locates the subscriber account and authorizes him. During 937 this procedure, the PPS takes into consideration the SAD PPC 938 Capabilities. Upon successful authorization, the PPS generates an 939 Access-Accept containing an PPAC attribute and an PPAQ attribute. 940 The PPAC attribute returned to the client indicates the type of 941 prepaid service to be provided for the session. The PPAQ attribute 942 includes the following information. 944 o The QUOTA-ID, which is set by the PPS to a unique value that is 945 used to correlate subsequent quota requests. 947 o Volume and/or Time quota, which is set to a value representing a 948 portion of the subscriber's credit. 950 o It MAY contain a Time or Volume Threshold that indicates when the 951 SAD should request additional quota. 953 o The IP address of the Serving PPS and one or more alternative 954 PPSs. This is used by the HAAA to route subsequent quota 955 replenishing messages to the appropriate PPS(s). 957 o A State attribute, as defined in RFC 2865. This is necessary in 958 order to satisfy the requirements of section 5.44 of RFC 2865, 959 which mandates that an Access-Request with Service- 960 Type="Authorize-Only" must contain a State attribute. Since the 961 SAD sends subsequent quota replenishment requests in the form of 962 such "Authorize-Only" requests, a State attribute MUST be present 963 in all Access-Accept messages that also carry a PPAQ attribute. 965 Note: The Idle-Timeout(28) attribute can be used to trigger the 966 premature termination of a prepaid service, for example as a result 967 of inactivity. 969 Depending on site policies, after failed authorization, the PPS may 970 generate an Access-Reject in order to terminate the session 971 immediately. Alternatively, the PPS may generate an Access-Accept 972 blocking some or all of the traffic and/or redirect some or all of 973 the traffic to a location to a fixed server. (This feature could be 974 used, for example, to prompt the user to replenish their account.) 975 Blocking of traffic is achieved by either Filter-ID(11) or NAS- 976 Filter-Rule(see Redirect I-d). Redirection is achieved by sending 977 Redirect-Id or Redirect-Rule, HTTP Redirection defined in the 978 Redirect I-d. The time period before the session is blocked/ 979 redirected is specified by the Session-Timeout(27) attribute. 981 Upon receiving an Access-Accept from the PPS, the HAAA appends the 982 usual service attributes and forward the packet to the SAD. The HAAA 983 SHOULD NOT overwrite any attributes already set by the PPS. If the 984 HAAA receives an Access-Reject message, it will simply forward the 985 packet to its client. Depending on site policies, if the HAAA does 986 not receive an Access-Accept or an Access-Reject message from the PPS 987 it MAY do nothing or send an Access-Reject or an Access- Accept 988 message back to the PPC. 990 3.2. Session Start Operation 992 The start of the session is indicated by the arrival of an 993 Accounting-Request(Start) packet. The Accounting-Request (Start) MAY 994 be routed to the PPS such that it can confirm the initial quota 995 allocation. 997 Note that the role of the PPS is not to record accounting messages 998 and therefore it SHOULD NOT respond with an Accounting Response 999 packet. If the PPS does not receive the Accounting-Request(start) 1000 message it will only know that the session has started upon the first 1001 reception of a quota replenishment operation. 1003 If the PPS does not receive indication directly (via Accounting- 1004 Request(start)) or indirectly, it SHOULD, after some configurable 1005 time, deduce that the Session has not started. If the SAD supports 1006 termination capabilities, the PPS SHOULD send a Disconnect Message to 1007 the SAD as a measure to ensure that the session is indeed dead. 1009 3.3. Mid-Session Operation 1011 During the lifetime of a prepaid data session the SAD may request the 1012 replenishment of the quotas using an Authorize-Only Access-Request 1013 message. Once either the allocated quota has been exhausted or the 1014 threshold has been reached, the SAD MUST send an Access-Request with 1015 Service-Type(6) set to a value of "Authorize-Only" and the PPAQ 1016 attribute. 1018 The SAD MUST also include NAS identifiers, and Session identifier 1019 attributes in the Authorize-Only Access-Request. The Session 1020 Identifier should be the same as the one used during the initial 1021 Access-Request. For example, if the User-Name(1) attribute was used 1022 in the Access-Request it MUST be included in the Authorize-Only 1023 Access-Request, especially if the User-Name(1) attribute is used to 1024 route the Access-Request to the Home AAA server. 1026 The Authorize-Only Access-Request MUST NOT include a User Password 1027 and MUST NOT include a Chap Password. In order to enable the 1028 receiver to authenticate the message, the SAD MUST include a Message- 1029 Authenticator(80). In order to satisfy the requirements of section 1030 5.44 of RFC 2865, the SAD MUST also include the State attribute. It 1031 is anticipated that the inclusion of the State attribute will enable 1032 the PPS to map the Authorize-Only Access Request to the 1033 authentication context that was established when the PPC 1034 authenticated itself at the beginning of the session. The SAD 1035 computes the value for the Message-Authenticator and the State 1036 attributes according to RFC 2869 and 2865 respectively. 1038 When the HAAA receives an Authorize-Only Access-Request that contains 1039 a PPAQ(TBD), it SHALL validate the message using the Message- 1040 Authenticator(80), according to RFC 2869. If the HAAA receives an 1041 Authorize-Only Access-Request that contains a PPAQ(TBD) and either no 1042 or an invalid Message-Authenticator(80) it SHALL silently discard the 1043 message. An Authorize Only Access-Request message that does not 1044 contain a PPAQ(TBD) is either erroneous or belongs to another 1045 application (for example, a Change of Authorization message 1046 [RFC3576]). In this case the Authorize-Only Access-Request is either 1047 silently discarded or handled by another application. 1049 Once the Authorize-Only Access-Request message is validated, the HAAA 1050 SHALL forward the Authorize-Only Access-Request to the appropriate 1051 PPS. The HAAA MUST forward the Authorize-Only Access-Request to the 1052 PPS specified in the PPAQ(TBD). The HAAA MUST add a Message- 1053 Authenticator(80) to the message, according to RFC 2869. As with the 1054 Access-Request message, the HAAA MAY modify the User-Name(1) 1055 attribute such that it identifies the user to the PPS. Note that the 1056 PPS may also use the Quota-ID sub-attribute contained within the 1057 PPAQ(TBD) to locate the user account. 1059 Upon receiving the Authorize-Only Access-Request containing a 1060 PPAQ(TBD) attribute, the PPS MUST validate the Message- 1061 Authenticator(80) as described in RFC 2869. If validation fails, the 1062 PPS MUST silently discard the message. If it receives an Authorize- 1063 Only Access-Request message that does not contain a PPAQ(TBD), it 1064 MUST silently discard the message. 1066 The PPS locates the prepaid session state using the Quota Id 1067 contained within the PPAQ(TBD). The PPS takes the most recently 1068 allocated quota and subtracts it from the user balance. If 1069 sufficient balance remains, the PPS authorizes the PPS and allocates 1070 additional quota. The PPS may also calculate a new threshold value. 1071 Upon successful re-authorization, the PPS generates an Access-Accept 1072 containing the PPAQ(TBD) attribute. The Access-Accept message MAY 1073 contain Servicetype(6) set to Authorize-Only and MAY contain the 1074 Message-Authenticator(80). 1076 Depending on site policies, upon unsuccessful authorization, the PPS 1077 generates an Access-Reject or an Access-Accept with Filter-Id(11) or 1078 Ascend-Data-Filter (if supported) attribute and the Session- 1079 Timeout(27) attribute such that the subscriber can get access to a 1080 restricted set of locations for a short period of time. This feature 1081 could be used to enable users to replenish their accounts, create new 1082 accounts, or to browse free content. 1084 Upon receiving the Access-Accept from the PPS, the HAAA SHALL return 1085 the packet to its client. If the HAAA receives an Access-Reject 1086 message, it forwards the packet. Depending on site policies, if the 1087 HAAA does not receive an Access-Accept or an Access-Reject message 1088 from the PPS it MAY do nothing or it MAY send an Access-Reject 1089 message back to its client. 1091 Upon receiving an Access-Accept, the SAD SHALL update its quotas and 1092 threshold parameters with the values contained in the PPAQ(TBD) 1093 attribute. Note that the PPS MAY update the PrePaidServer 1094 attribute(s) and these may have to be saved as well. If the Access- 1095 Accept message contains a Filter-Id(11), an Ascend-Data-Filter 1096 attribute, or Session Timeout(27), the SAD SHALL restrict the 1097 subscriber session accordingly. 1099 3.4. Dynamic Operations 1101 The PPS may take advantage of the dynamic capabilities that are 1102 supported by the SAD as advertised in the Dynamic-Capabilities 1103 attribute during the initial Access-Request. There are two types of 1104 action that the PPS may perform. Firstly, it may request the session 1105 to be terminated. Secondly, it may request the attributes associated 1106 with the session to be modified. More specifically, it may modify a 1107 previously sent PPAQ(TBD). 1109 Both of these actions require that the session be uniquely identified 1110 at the SAD. As a minimum, the PPS MUST provide 1112 1. either the NAS-IP-Address(4) or the NAS-Identifier(32), and 1114 2. at least one session identifier such as User-Name(1), Framed-IP- 1115 Address(), the Accounting-Session-Id(44). 1117 Other attributes could also be used to uniquely identify a prepaid 1118 data session. 1120 3.4.1. Unsolicited Session Termination Operation 1122 At anytime during a session the PPS may send a Disconnect Message in 1123 order to terminate a session. This capability is described in detail 1124 in [RFC3576]. The PPS sends a Disconnect Message that MUST contain 1125 identifiers that uniquely identify the data session and the SAD 1126 servicing that session. 1128 If the SAD receives a Disconnect-Message, it responds with either a 1129 Disconnect-ACK message (if it is able to terminate the session) or 1130 with a Disconnect-NAK packet (otherwise). Upon successful 1131 termination of a session the SAD MUST return any unused quota to the 1132 PPS by issuing an Authorize-Only Access-Request containing the PPAQ 1133 which contains any unused Quota and the Update-Reason set to "Remote 1134 Forced Disconnection". 1136 3.4.2. Unsolicited Change of Authorization Operation 1138 At any time during the session the PPC may receive a Change of 1139 Authorization (CoA) message. A PPS may send a new Quota to either 1140 add or to remove quota that is allocated to the service. If the 1141 Change of Authorization contains a PPAQ then that PPAQ overrides a 1142 previously received PPAQ. The PPS MUST NOT change the units used in 1143 the PPAQ. 1145 If the newly received PPAQ reduces the amount of allocated quota 1146 beyond what is already used then the SAD accepts the new PPAQ and act 1147 as it normally would when the quota is used up. For example, if the 1148 threshold is reached then is request a quota update . 1150 3.5. Termination Operation 1152 The termination phase is initiated when (i) the subscriber logs off, 1153 (ii) the subscriber balance is exhausted, or (iii) when the SAD 1154 receives a Disconnect Message. 1156 In case the user logged off, or the SAD receives a Disconnect 1157 Message, the SAD sends an Authorize-Only Access-Request message with 1158 a PPAQ and Update-Reason attribute set to either "Client Service 1159 Termination" or "Remote Forced Disconnect". This message indicates 1160 the amount of consumed quota. 1162 In case the currently allocated quota is exhausted, if the PPAQ 1163 contained the Termination-Action field, the SAD follows the specified 1164 action (which would be to immediately terminate the service, request 1165 more quota, or redirect/filter the service). 1167 3.6. Mobile IP Operations 1169 In roaming scenarios with Mobile-IP, the prepaid data session should 1170 be maintained transparently if the HA is acting as the SAD. As the 1171 subscriber device associates with a new SAD (AP or PDSN that supports 1172 PPC capability), the SAD sends a RADIUS Access-Request and the 1173 subscriber is re-authenticated and reauthorized. The SAD MUST 1174 include the PPAC(TBD) attribute in the RADIUS Access-Request. In 1175 this manner, the procedure follows the Authentication and 1176 Authorization procedure described earlier. 1178 If the HA was acting as the SAD before handoff, the prepaid session 1179 does not undergo any change after the handoff because the Mobile IP 1180 session is anchored at the HA and the user's Home IP address does not 1181 change. 1183 In the case of a wireless access point or PDSN acting as the SAD, it 1184 is likely that the user's (care-of) IP address will change. The 1185 prepaid session will be affected by this. In this scenario the SAD 1186 shall send an Access-Request message which is routed to the home 1187 network and MUST reach the PPS that is serving this session. The PPS 1188 correlates the new authorization request with the existing active 1189 session and assigns a quota to the new request. Any outstanding 1190 quota at the old SAD MUST be returned to the PPS if the Mobile-IP 1191 nodes (HA and FA) support registration revocation (Mobile IPv4 only). 1192 Specifically, the quota SHOULD be returned when the SAD sends the 1193 Authorize-Only Access-Request with PPAQ(TBD) Update-Reason set to 1194 either "Remote Forced Disconnect" or "Client Service Termination". 1195 In order to trigger the sending of this last Authorize-Only Access- 1196 Request, the PPS may issue a Disconnect Message [3576] to the SAD. 1198 Even if the subscriber moves to a SAD that does not have prepaid 1199 capabilities can the prepaid data service continue. This can be done 1200 by requesting the Home Agent (assuming it has such capabilities) to 1201 take over the responsibilities of the SAD (i.e. metering). This 1202 scenario will be discussed in detail in a later version of this 1203 document. 1205 3.7. Operation Considerations for Multiple Services 1207 This section describes the support for multiple prepaid services on a 1208 single SAD. Message flows illustrating the various interactions are 1209 presented in Appendix A. 1211 A SAD that supports prepaid operations for multi-services SHOULD set 1212 the "Multi-Services Supported" bit in the PPAC. When working with 1213 multi-services, we need to differentiate between the services. A 1214 Service-Id attribute is used in the PPAQ(TBD) in order to uniquely 1215 differentiate between the services. The exact definition of the 1216 Service-Id attribute is outside the scope of this document. 1218 A PPAQ that contains a Service-Id is associated with that Service. A 1219 PPAQ that contains a Rating-Group-Id is associated with that Rating- 1220 Group. A PPAQ MUST not contain both a Rating-Group-Id and a 1221 Service-Id. A PPAQ that contains neither a Rating-Group-Id or a 1222 Service-Id applies to the Access Service. 1224 3.7.1. Initial Quota Request 1226 When operations with multi-services is desired, the SAD requests the 1227 initial quota for the Service by sending a PPAQ containing the 1228 Service-Id for that Service in an Authorize-Only Access-Request 1229 packet. Similarly, if the SAD supports Rating-Groups then it may 1230 request a quota for the Rating-Group by sending a PPAQ containing the 1231 Rating-Group-Id. In both cases the Update-Reason is set to "Initial- 1232 Request". 1234 The Authorize-Only Access-Request message may contain more than one 1235 PPAQ. The Authorize-Only Access-Request MUST include one or more 1236 attributes that serve to identify the session so that it can be 1237 linked to the original authentication. Which Session Identifiers are 1238 included is up to specific deployments. The Authorize-Only message 1239 must contain the Message-Authenticator(80) attribute for integrity 1240 protection of the Authorize-Only Access-Request message. 1242 Upon receiving an Authorize-Only Access-Accept message containing one 1243 or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ 1244 is assigned a unique QID that MUST appear in subsequent PPAQ updates 1245 for that service or rating-group. Additionally, the PPAQ MUST 1246 contain the Service-ID or Group-ID, unless the PPAQ is the generic 1247 "Access Service". 1249 3.7.2. Quota Update 1251 Once the services start to utilize their allotted quota they will 1252 eventually need to replenish their quotas (either the threshold is 1253 reached or no more quota remains). In order to replenish the quota, 1254 the PPC sends an Authorize-Only Access-Request message containing one 1255 or more PPAQs. Each PPAQ MUST contain the appropriate QID, 1256 Service-ID or Group-ID (or neither the Service-ID or Group-Id if the 1257 quota replenishment is for the "Access Service"). The Update-Reason 1258 filed indicates either "Threshold reached"(3), or "Quota reached"(4). 1259 The Authorize-Only message must contain session identifiers. 1261 Upon receiving an Authorize-Only Access-Request packet with one or 1262 more PPAQs the PPS responds with a new PPAQ for that service. The 1263 PPAQ contains a new QID, the Service-Id or Rating-Group-Id, a new 1264 Quota. If the PPS does not grant additional quota to the service it 1265 MUST include the Termination-Action subfield in the PPAQ that will 1266 instruct the SAD what to do with the service. 1268 3.7.3. Termination 1270 When the allotted quota for a service is exhausted, the SAD shall act 1271 in accordance with the Termination-Action field set in the Quota. If 1272 the Termination-Action field is absent then the service MUST be 1273 terminated. If the service is to be terminated, then the SAD shall 1274 send a PPAQ with the appropriate QID, the Service-Id, the used quota, 1275 and the Update-Reason set to "Client Service Termination". 1277 If the oAccess Serviceoe has terminated, then all other services must 1278 be terminated as well. In this case the SAD MUST report on all 1279 issued quotas for the various services. The Update-Reason field 1280 should be set to "Access Service Terminated". 1282 3.7.4. Dynamic Operations 1284 Dynamic operations for multi-services are similar to dynamic 1285 operations described for single service operations. The prepaid 1286 system may send a COA message containing a PPAQ for an existing 1287 service instance. The SAD matches the PPAQ with the service using 1288 the Service-ID attribute. The new quota could differ from the 1289 previously allocated value. The SAD must react to the new value 1290 accordingly. 1292 A disconnect message terminates the "Access Service". As such the 1293 SAD MUST report all unused quotas by sending an Authorize-Only Access 1294 Request message containing a PPAQ for each active service. The 1295 Update-Reason shall indicate that the reason for the update. 1297 3.7.5. Support for Resource Pools 1299 If the PPC supports pools as indicated by setting the "Pools 1300 supported" bit in the PPAC(TBD) then the PPS may associate a Quota 1301 with a Pool by including the Pool-Id and the Pool-Multiplier in the 1302 PPAQ(TBD). When Resource Pools are used, the PPAQ must not use the 1303 threshold field. 1305 3.7.6. One-time Charging 1307 To initiate a One-Time charge the PPC includes the PPAQ attribute in 1308 an Access-Request packet. The Access Request packet MUST include a 1309 Message-Authenticator(80) and an Event-Timestamp(55) attribute. The 1310 Service Id field of the PPAQ identifies the prepaid service. The 1311 amount to be charged is specified using the Resource Quota and 1312 Resource Quota overflow subtypes. If the value specified is negative 1313 then the resources are credited to the user account. 1315 The QID field MUST be set to a unique value and is used by the PPS to 1316 detect duplicates. The Update Reason field MUST be set to One-Time 1317 Charging. Upon receiving a One-Time charge PPAQ, the RADIUS server 1318 authenticates the user and, if successful, passes the PPAQ to the 1319 PPS. The PPS locates the account and debits or credits it 1320 accordingly. The PPS MUST respond to the PPS with an Access-Accept 1321 message if successful, or an Access-Reject message otherwise. 1323 The RADIUS server shall respond to the SAD with an Access Accept 1324 message. Since this is a one-time charge the SAD must not allow the 1325 session to continue. Therefore, the RADIUS server should include in 1326 the Access-Accept a Session-Timeout set to 0. Upon receiving an 1327 Access-Accept response the SAD shall generate an Accounting Stop 1328 message. 1330 A PPAQ used for One-Time charging may appear in an Authorize-Only 1331 Access Request. This is the case when the session already exists. 1332 The PPS responds with an Access-Accept to indicate that the user 1333 account has been debited or an Access-Reject otherwise. 1335 3.7.7. Error Handling 1337 If the PPS receives a PPAQ with an invalid QID it MUST ignore that 1338 PPAQ. 1340 If the PPS receives a PPAQ containing a Service-Id, or a Rating- 1341 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1343 If the PPC receives a PPAQ containing a Service-Id, or a Rating- 1344 Group-Id that it does not recognize, then it must ignore that PPAQ. 1346 If the PPC receives a PPAQ that contains a Pool-Id without a Pool- 1347 Multiplier or a Pool-Multiplier without a Pool-Id it must ignore that 1348 PPAQ. 1350 3.7.8. Accounting Considerations 1352 Although typically generated, accounting messages are not required to 1353 deliver a prepaid data service. When generated, accounting messages 1354 are used for auditing purposes and for billing. Accounting messages 1355 associated with prepaid data sessions should include the PPAQ(TBD) 1356 attribute. 1358 3.7.9. Interoperability with Diameter Credit Control Application 1360 The RADIUS prepaid extensions need to interoperate with the Diameter 1361 protocol. Two interoperability scenarios exist, as follows. Either 1362 the AAA infrastructure is Diameter based and the SAD are RADIUS 1363 based, or the SAD is Diameter based and the AAA infrastructure is 1364 RADIUS based. 1366 The Diameter Credit Control Application [DIAMETERCC] describes how to 1367 implement a prepaid accounting system using a Diameter based 1368 infrastructure. 1370 4. Attributes 1372 This section specifies the attributes that implement the RADIUS 1373 extensions for prepaid. Their general format follow that of the base 1374 RADIUS [RFC2865] and take also account current design guidelines that 1375 are proposed in the RADEXT working group. The type field of these 1376 attributes contains a value that is drawn from the type value space 1377 specified in [RFC2865]. The exact value for the type field of each 1378 attribute is to be allocated by IANA. Note that, unless otherwise 1379 specified, the format of the value field of each of the AVPs defined 1380 in this section adheres to one of the formats specified in section 5 1381 of [RFC2865]. In particular, the labels "string", "integer", and 1382 "address" are used to indicate the format in the remainder of this 1383 document. 1385 4.1. PPAC Attribute 1387 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1388 Access-Request message by a prepaid capable NAS and is used to 1389 describe the prepaid capabilities of the NAS. The PPAC is also 1390 present in an Access-Accept message by the PPS in order to indicate 1391 the type of metering that is to be applied to this session. 1393 0 1 2 3 1394 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 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | TYPE | LENGTH | SUBtype 1 | LENGTH | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | AvailableInClient (AiC) | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 TYPE : value of PPAC 1402 LENGTH: 8 1403 VALUE : String 1405 The value MUST be encoded as follows: 1407 Subtype (=1) : Subtype for AvailableInClient attribute 1408 Length : Length of AvailableInClient attribute 1409 (= 6 octets) 1410 AvailableInClient (AiC): 1412 The optional AvailableInClient Subtype, generated by the PPC, 1413 indicates the metering capabilities of the NAS and shall be bitmap 1414 encoded. The possible values are as follows. 1416 0x00000001 Volume metering supported. 1417 0x00000002 Duration metering supported. 1418 0x00000004 Resource metering supported. 1419 0x00000008 Pools supported 1420 0x00000010 Rating groups supported 1421 0x00000020 Multi-Services supported. 1422 0x00000040 Tariff Switch supported. 1424 Others Reserved 1426 Figure 10: PPAC Attribute 1428 4.2. Session Termination Attribute 1430 The value is bitmap encoded. This attribute is included in a RADIUS 1431 Access-Request message to the RADIUS server and indicates whether or 1432 not the NAS supports Dynamic Authorization. 1434 0 1 2 3 1435 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 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | TYPE | LENGTH | String | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 Type : value of Session Termination Capability 1441 Length: = 4 1442 String encoded as follows: 1444 0x00000001 Dynamic Authorization Extensions (rfc3576) is 1445 supported. 1447 Figure 11: Session Termination Attribute 1449 4.3. PPAQ Attribute 1451 One or more PPAQ attributes are sent in an Access Request, Authorize- 1452 Only Access-Request and Access-Accept message. In an Access Request 1453 message, the PPAQ attribute is used to facilitate One-Time charging 1454 transactions. In Authorize-Only Access-Request messages it is used 1455 for One-Time charging, report usage and the request for further 1456 quota. It is also used in order to request prepaid quota for a new 1457 service instance. In an Access-Accept message it is used in order to 1458 allocate the (initial and subsequent) quotas. 1460 When multiple services are supported, a PPAQ is associated with a 1461 specific service as indicated by the presence of a Service-Id, a 1462 Rating-Group-Id, or the "Access Service" (as indicated by the absence 1463 of a Service-Id and a Rating-Group-Id). 1465 The attribute has a variable length (greater than 8, encoded into one 1466 octet), and consists of a variable number of subtypes. Unused 1467 subtypes are omitted from the message. In the following subsections 1468 the various subtypes of the PPAQ attribute are specified. 1470 4.3.1. Quota Identifier AVP 1472 The value of the type field of the QuotaIDentifier AVP is TBD. The 1473 length of this AVP is 6 octets. Its value is encoded as a string. 1474 It is generated by the PPS together with the allocation of new quota. 1475 The online quota update RADIUS Access-Request message that is sent 1476 from the SAD to the PPS includes a previously received 1477 QuotaIdentifier AVP. 1479 4.3.2. VolumeQuota AVP 1481 The value of the type field of the VolumeQuota AVP is TBD. The 1482 length of this AVP is 12 or 18 octets. The AVP is only present if 1483 volume-based charging is used. In a RADIUS Access-Accept message 1484 (PPS to SAD direction), it indicates the volume (in octets) allocated 1485 for the session by the PPS. In an RADIUS Authorize-Only Access- 1486 Request message (SAD to PPS direction), it indicates the total used 1487 volume (in octets) for both inbound and outbound traffic. The 1488 attribute consists of a Value-Digits AVP and optionally an Exponent 1489 AVP (as indicated in the length field). The Exponent AVP, if 1490 present, MUST NOT encode a negative number or zero. 1492 4.3.3. VolumeThreshold AVP 1494 The value of the type field of the VolumeThreshold AVP is TBD and its 1495 length is 12 or 18 octets. This AVP is optionally present if 1496 VolumeQuota is present in a RADIUS Access-Accept message (PPS to SAD 1497 direction). It is generated by the PPS and indicates the volume (in 1498 octets) that shall be consumed before a new quota should be 1499 requested. This threshold should not be larger than the VolumeQuota. 1500 The attribute consists of a Value-Digits AVP and optionally an 1501 Exponent AVP (as indicated by the length field). The Exponent AVP, 1502 if present, MUST NOT encode a negative number or zero. 1504 4.3.4. DurationQuota AVP 1506 The value of the type field of the DurationQuota AVP is TBD and its 1507 length is 6 octets. This optional AVP is only present if duration- 1508 based charging is used. In RADIUS Access-Accept message (PPS to SAD 1509 direction), it indicates the duration (in seconds) allocated for the 1510 session by the PPS. It is encoded as an integer. In an on-line 1511 RADIUS Access-Accept message (PPC to PPS direction), it indicates the 1512 total duration (in seconds) since the start of the accounting session 1513 related to the QuotaID of the PPAQ AVP in which it occurs. 1515 4.3.5. DurationThreshold AVP 1517 The value of the type field of the DurationThreshold AVP is TBD and 1518 its length is 6 octets. This AVP shall optionally be present if 1519 DurationQuota is present in a RADIUS Access-Accept message (PPS to 1520 PPC direction). It represents the duration (in seconds) after which 1521 new quota should be requested. This threshold should not be larger 1522 than the DurationQuota. It is encoded as an integer. 1524 4.3.6. ResourceQuota AVP 1526 The value of the type field of the ResourceQuota AVP is TBD. The 1527 length of this AVP is 12 or 18 octets. This optional AVP is only 1528 present if resource-based or one-time charging is used. In the 1529 RADIUS Access-Accept message (PPS to SAD direction) it indicates the 1530 resources allocated for the session by the PPS. In RADIUS Authorize- 1531 Only Access-Request message (SAD to PPS direction), it indicates the 1532 resources used in total, including both incoming and outgoing 1533 chargeable traffic. In one-time charging scenarios, the subtype 1534 represents the number of units to charge or credit the user. The 1535 attribute consists of a Value-Digits AVP and optionally an Exponent 1536 AVP (as indicated by the length field). 1538 4.3.7. ResourceThreshold AVP 1540 The value of the type field of the ResourceThreshold AVP is TBD. The 1541 length of this AVP is 12 or 18 octets. The semantics of this AVP 1542 follow those of the VolumeThreshold and DurationThreshold AVPs. It 1543 consists of a Value-Digits AVP and optionally an Exponent AVP. 1545 4.3.8. Value-Digits AVP 1547 The value of the type field of the Value-Digits AVP is TBD and its 1548 length is 10 octets. This AVP encodes the most significant digits of 1549 a number, encoded as an integer. If decimal values are needed to 1550 present the number, the scaling MUST be indicated with a related 1551 Exponent AVP. For example, the decimal number 0.05 is encoded by a 1552 Value-Digits AVP set to 5, and a scaling that is indicated with the 1553 Exponent AVP set to -2. 1555 4.3.9. Exponent AVP 1557 The value of the type field of the Exponent AVP is TBD. The length 1558 of this AVP is 6 octets. This AVP contains the exponent value that 1559 is to be applied to the accompanying Value-Digit AVP. Its value is 1560 encoded as an integer. 1562 4.3.10. Update-Reason AVP 1564 The value of the type field of the Update-Reason AVP is TBD. The 1565 length of this AVP is 4 octets. This AVP shall be present in the on- 1566 line RADIUS Access-Request message (PPC to PPS direction). It 1567 indicates the reason for initiating the on-line quota update 1568 operation. Update reasons 6, 7, 8 and 9 indicate that the associated 1569 resources are released at the client side, and that therefore the PPS 1570 shall not allocate a new quota in the RADIUS Access Accept message. 1572 1. Pre-initialization 1573 2. Initial Request 1575 3. Threshold Reached 1577 4. Quota Reached 1579 5. TITSU Approaching 1581 6. Remote Forced Disconnect 1583 7. Client Service Termination 1585 8. "Access Service" Terminated 1587 9. Service not established 1589 10. One-Time Charging 1591 4.3.11. PrepaidServer AVP 1593 The value of the type field of the PrepaidServer AVP is TBD. The 1594 length of this AVP is 6 or 18 octets, for IPv4 and IPv6 addresses 1595 respectively. This optional AVP indicates the address of the serving 1596 PPS. If present, the Home RADIUS server uses this address to route 1597 the message to the serving PPS. The attribute may be sent by the 1598 Home RADIUS server. Multiple instances of this subtype MAY be 1599 present in a single PPAQ AVP. The value of this AVP is encoded as an 1600 address. 1602 If present in the incoming RADIUS Access-Accept message, the SAD 1603 shall send this attribute back without modifying it in the subsequent 1604 RADIUS Access-Request message, except for the first one. If multiple 1605 values are present, the SAD shall not change their order. 1607 4.3.12. Service-ID AVP 1609 The value of the type and length fields of the Service-ID AVP are 1610 TBD. The value field of this AVP is encoded as a string. This value 1611 is handled as an opaque string that uniquely describes the service 1612 instance to which prepaid metering should be applied. A Service-Id 1613 could be an IP 5-tuple (source address, source port, destination 1614 address, destination port, protocol). If a Service-ID AVP is present 1615 in the PPAQ, the entire PPAQ refers to that service. If a PPAQ does 1616 not contain a Service-Id or Rating-Group-ID, then the PPAQ refers to 1617 the Access Service. 1619 4.3.13. Rating-Group-ID AVP 1621 The value of the type field of the Rating-Group-ID is TBD. The 1622 length of this AVP is 6 octets. This AVP indicates that this PPAQ is 1623 associated with resources allocated to a Rating Group with the 1624 corresponding ID. This AVP is encoded as a string. A PPAQ MUST NOT 1625 contain more than one Rating-Group-ID. 1627 4.3.14. Termination-Action AVP 1629 The value of the type field of the Termination-Action AVP is TBD. 1630 The length of this AVP is 3 octets. This AVP contains an enumeration 1631 of the action to take when the PPS does not grant additional quota. 1632 Valid actions are as follows. (Note that the value 0 is reserved.) 1634 1. Terminate 1636 2. Request More Quota 1638 3. Redirect/Filter 1640 4.3.15. Pool-ID AVP 1642 The value of the type field of the Pool-ID AVP is TBD. The length of 1643 this AVP is 6 octets. This AVP identifies the resource pool that the 1644 quota included in this PPAQ is associated with. It is encoded as a 1645 string. 1647 4.3.16. Pool-Multiplier AVP 1649 The value of the type field of the Pool-Multiplier AVP is TBD. The 1650 length of this AVP is 12 or 18 octets. The pool-multiplier 1651 determines the weight that resources are inserted into the pool that 1652 is identified by the accompanying Pool-ID AVP, and the rate at which 1653 resources are taken out of the pool by the relevant Service or 1654 Rating-Group. The attribute consists of a Value-Digits AVP and 1655 optionally an Exponent AVP (as indicated by the length field). 1657 4.3.17. Requested-Action AVP 1659 The value of the type field of the Requested-Action AVP is TBD. The 1660 length of this AVP is 3 octets. This AVP can only be present in 1661 messages sent from the PPC to the PPS. It indicates that the user or 1662 the PPC desires the PPS to perform the indicated action and to return 1663 the result. The PPAQ in which a Requested-Action AVP occurs MUST NOT 1664 contain a QID, and MUST contain a Service-Identifier that, possibly 1665 in combination with other AVPS, can be used by the PPS to uniquely 1666 identify the service for which the indicated action is requested. 1668 The following actions may be requested. 1670 1. Balance Check 1672 2. Price Enquiry 1674 4.3.18. Check-Balance-Result AVP 1676 The value of the type field of the Check-Balance-Result AVP is TBD. 1677 The length of this AVP is 3 octets. This AVP can only be present in 1678 messages sent from the PPS to the PPC. It indicates the balance 1679 check decision of the PPS about a previously received Balance Check 1680 Request (as indicated in a Requested-Action AVP). Possible values 1681 are 0 for "success" and any other value for "failure" and mean that 1682 sufficient funds are available (resp. are not available) in the 1683 user's prepaid account. The PPAQ in which a Check-Balance-Result 1684 occurs MUST NOT include a QID, because no quota is reserved by the 1685 PPS. 1687 4.3.19. Cost-Information AVP 1689 The value of the type field of the Cost-Information AVP is TBD. The 1690 length of this AVP is variable. This AVP is used in order to return 1691 the cost information of a service, which the PPC can transfer 1692 transparently to the end user. This AVP is sent from the PPS to the 1693 PPC as a response to a "Price Enquiry", as indicated by the 1694 Requested-Action AVP. This AVP consists of four further AVPs, as 1695 follows. 1697 1. Value-Digits ASP: this encodes the most significant digits of the 1698 monetery value that represents the cost in question. 1700 2. Exponent AVP: this encodes the exponent that applies to the 1701 Value-Digits AVP. 1703 3. Currency-Code AVP: the value of the type field of this AVP is 1704 TBD. The length of this AVP is 4 octets. It encodes the 1705 currency code, as defined in the ISO 4217 standard. 1707 4. Cost-Unit AVP: the value of the type field of this AVP is TBD. 1708 The length of this AVP is variable. It carries a UTF8String 1709 encoded human readable string that can be displayed to the end 1710 user. It specifies the applicable unit to the Cost-Information 1711 when the service cost is a cost per unit (e.g., cost of the 1712 service is $1 per minute). The Cost-Unit can be minutes, hours, 1713 days, kilobytes, megabytes, etc. 1715 Example: the cost of 7.75 Malawi kwacha per hour would be encoded as 1716 follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, and 1717 Cost-Unit = "hour". 1719 The PPAQ in which a Cost-Information occurs MUST NOT include a QID, 1720 because no quota is actually reserved by the PPS. 1722 NOTES: Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear 1723 in the PPAQ attribute. A PPAQ MUST NOT contain more than one 1724 Service-Id, MUST NOT contain more than one Rating-Group-Id, and MUST 1725 NOT contain both a Service-Id and a Rating-Group-Id. A PPAQ that 1726 does not contain a Service-ID or a Rating-Group-Id refers to the 1727 "Access Service". A PPAQ MUST NOT contain more than one Pool-Id. A 1728 PPAQ that contains a Pool-Id MUST also contain a Pool-Multiplier AVP. 1730 4.4. Prepaid Tariff Switching Attribute (PTS) 1732 This specification defines the PTS attribute which allows for 1733 changeovers from one rate to another during service provision. 1734 Support for tariff switching is optional for both the PPC and the 1735 PPS. PPCs use the flag "Tariff Switching supported" of the 1736 AvailableInClient subtype of the PPAC attribute in order to indicate 1737 support for tariff switching. PPSs employ the PTS attribute in order 1738 to announce their support for tariff switching. Details of this will 1739 be specified after the format of the PTS attribute has been defined. 1741 If a RADIUS message contains a PTS attribute, it MUST also contain at 1742 least one PPAQ attribute. If a RADIUS Access-Request message 1743 contains a PTS attribute or a "Tariff Switching supported" flag, it 1744 MUST also contain an Event-Timestamp RADIUS attribute (see 1745 [RFC2869]). 1747 The value of the type field of the PTS AVP is TBD. The length of 1748 this AVP is variable. It contains one or more subtypes, as follows. 1749 Every PTS AVP MUST include a QuotaIdentifier AVP as specified in 1750 Section 4.3.1. In an online RADIUS Access-Request message sent from 1751 the PPC to the PPS, the QuotaIdentifier AVP must contain a quota 1752 identifier that was previously received from the PPS and MUST be the 1753 same as a quota identifier of one of the PPAQ attributes included the 1754 same RADIUS message. 1756 A PPAQ attribute that is transported along with a PTS attribute and 1757 has the same quota identifier value as the PTS attribute in its own 1758 QID subfield is referred to as the "accompanying PPAQ attribute". If 1759 a PPS receives an Access-Request message from a PPC, it associates a 1760 unique quota identifier to this request. Thus, a quota identifier 1761 also identifies a particular service. 1763 The PTS AVP contains a number of other subtype AVPs which are 1764 specified in the following subsections. 1766 4.4.1. VolumeUsedAfterTariffSwitch AVP 1768 The value of the type field of the VolumeUsedAfterTariffSwitch AVP is 1769 TBD. The length of this AVP is 12 or 18 octets. The 1770 VolumeUsedAfterTariffSwitch subtype SHALL be used in online RADIUS 1771 Access-Request messages (PPC to PPS direction). It indicates the 1772 volume (in octets) used during a session after the last tariff switch 1773 for the service specified via the QID subfield and the accompanying 1774 PPAQ attribute. The attribute consists of a Value-Digits AVP and 1775 optionally an Exponent AVP (as indicated in the length field). 1777 4.4.2. TariffSwitchInterval AVP 1779 The type of the TariffSwitchInterval is TBD and its length 6 octets. 1780 This AVP MUST be present in each PTS attribute that is part of a 1781 RADIUS Access-Accept message (PPS to PPC direction). It indicates 1782 the interval (in seconds) between the value of Event-Timestamp RADIUS 1783 attribute (see [RFC2869]) of the corresponding RADIUS Access-Request 1784 message and the next tariff switch condition. 1786 4.4.3. TimeIntervalafterTariffSwitchUpdate AVP 1788 The value of the type field of the 1789 TimeIntervalafterTariffSwitchUpdate (TITSU) AVP is TBD. The length 1790 of this AVP is 6 octets. The PPS MUST include this AVP if there is 1791 another tariff switch period after the period that ends as indicated 1792 by the TSI attribute. The value of the TITSU AVP in encoded as an 1793 integer, and contains the number of seconds of the tariff period that 1794 begins immediately after the period that ends as indicated by the TSI 1795 attribute. If the TITSU attribute is not present, the PPC assumes 1796 that the tariff period which ends as indicated by the TSI attribute 1797 lasts until further notice. If TITSU is specified, the PPC MUST send 1798 a quota update before the point in time specified by the TITSU 1799 attribute (see Figure 9). 1801 If a RADIUS message contains a PTS attribute, it MUST also contain at 1802 least one PPAQ attribute. The PTS is associated with the PPAQ by the 1803 QID. If multiple services are supported and if the PPAQ is 1804 associated with a service as indicated by the Service-ID AVP, then 1805 the PTS refers to the tariff switch for that service. If the PPAQ 1806 does not have a Service-ID, then the PTS refers to tariff switch for 1807 the Access-Service. 1809 If a PPC supports tariff switching then it MUST set the 0x00000040 1810 (Tariff switching supported) flag of the AvailableInClient subtype of 1811 the PPAC attribute that is contained in the Access-Request packet 1812 starting the session. 1814 5. Translation between RADIUS prepaid and Diameter Credit Control 1816 In scenarios where the service metering device uses the "RADIUS 1817 prepaid" (RPP) protocol for accounting and prepaid charging while the 1818 AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, 1819 a translation agent that enables the interoperation of both systems, 1820 is desirable. This also applies vice versa, i.e. in scenarios where 1821 the AAA infrastructure uses RADIUS and the service metering device 1822 uses Diameter. 1824 The idea of such a translation agent would be to convert incoming RPP 1825 (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It 1826 would be, in principle, desirable for the translation agent to be 1827 stateless. That is, the agent should not be required to internally 1828 maintain information about each ongoing RADIUS or Diameter session. 1829 However, under the current specification of RPP and DCC, this appears 1830 to be impossible due to a number of reasons. These include the 1831 following. 1833 1. The transport mechanism for DCC is TCP, which requires per- 1834 session state to be maintained at both endpoints of the 1835 communication. Note, however, that, in principle, each DCC 1836 message could be sent over a dedicated TCP connection which is 1837 torn down as soon as the message is sent. This, however, is 1838 likely to be unacceptable in terms of efficiency. 1840 2. While RPP messages encode the cumulative amount of consumed/ 1841 requested resources, DCC messages carry the difference from the 1842 previous message. This means that the translation agent has to 1843 maintain the current amount of consumed/requested resources in 1844 order to be able to calculate the correct amount to be put into 1845 an outgoing message. 1847 The translator maps each incoming RPP (resp. DCC) message into an 1848 outgoing DCC (resp. RPP) message, and possibly establishes or updates 1849 local state that is associated with the session. The translated 1850 (i.e. outgoing) message is a function of the incoming message as well 1851 as existing state that is associated with the current session. 1853 Translation occurs on an attribute-by-attribute basis. Certain 1854 attributes are translated without consideration of local per-session 1855 state. Other attributes, namely those that are bound to a particular 1856 session, require such consideration. The translation agent has to 1857 identify the session (and possibly subsession) an incoming message 1858 belongs to in order to consult the appropriate local per-session 1859 state. 1861 Note that certain DCC attributes cannot be translated due to their 1862 semantics not being present in RPP, and vice versa. This results in 1863 the messages, in which these attributes occur, not being delivered to 1864 their intended destination. In such cases it is desirable to inform 1865 the originator about the failure and terminate the session. 1867 In each scenario (i.e. RPP client / DCC AAA infrastructure and DCC 1868 client / RPP AAA infrastructure), the translator operates in two 1869 directions, namely RPP to DCC and vice versa. In the following 1870 sections, the notation c->s means that the attribute in question may 1871 occur only in the direction from the client to the server. The 1872 notation s->c denotes the converse and the notation c<->s denotes 1873 that the attribute may occur in messages that are directed in either 1874 direction. 1876 5.1. Session Identification 1878 The translation agent has to keep per-session state in order to 1879 perform its task. A session may be identified based on the RPP 1880 identifier or the DCC session identifier. That is, the translation 1881 agent should always maintain a pair of (RPP, DCC) session identifiers 1882 and maintain the per-session state in association with that pair. 1883 This per-session state must be addressable by either of these two 1884 identifiers. Moreover, an RPP session identifier must uniquely 1885 correspond to a DCC identifier. (If this holds, the converse also 1886 holds.) Each subsession identifier within an RPP session must also 1887 uniquely correspond to a subsession identifier within its 1888 corresponding DCC session. (If this holds the converse also holds.) 1890 5.2. Translation between RADIUS prepaid client and Diameter Credit 1891 Control AAA infrastructure 1893 This section describes the translator in the "RPP client / DCC AAA 1894 infrastructure" case. In other words, in this section it is assumed 1895 that the client "talks" RPP and the AAA inftrastructure "talks" DCC. 1896 The translator is assumed to sit somewhere in the middle and to 1897 mediate between client and server. 1899 For each RPP AVP (i.e. AVP that is specified in the present 1900 document), the transformation into a semantically equivalent DCC AVP 1901 (if such an AVP exists), along with what per-session state the 1902 translator has to create or consult, is described. For clarity of 1903 exposition, each RPP AVP is addressed in a separate subsection. 1904 Since in this scenario, the PPC is typically the initiator a session, 1905 the focus is on the RPP AVPs. 1907 5.2.1. PPAC (c<->s) 1909 A DCC client is assumed to always support Volume metering, Duration 1910 metering, Resource metering, Pools, Rating groups, and Tariff 1911 Switching. Thus, if a PPAQ that indicates any of the above is sent 1912 client->server, the translator does the following: It lets message go 1913 through but remembers what exactly the client supports. If the 1914 server later requests (servier -> client direction) an unsupported 1915 metering to be performed, send failure to server and cause the 1916 session to be terminated at the client. 1918 If a PPAC indicates support for multiple services (0x00000020), the 1919 translator maps this onto a DCC Multiple-Services- Indicator AVP. 1921 5.2.2. Service Termination Attribute (c->s) 1923 The Diameter base protocol assumes that the client always supports 1924 dynamic session termination. If this AVP is present, the translator 1925 does not need to do anything, i.e. there exists no DCC AVP that this 1926 AVP can be mapped to. If this AVP is absent, the message in which it 1927 appears should either be discarded and originator should be informed 1928 of a failure, or the message can be passed on (without this AVP being 1929 mapped onto a DCC AVP). However, in the latter case, the translator 1930 has to remember that the client does not support dynamic termination. 1931 Thus, the translatior has to initiate the normal session termination 1932 procedure with the client when (if) dynamic termination is later 1933 initiated by the server. 1935 5.2.3. Quota Identifier Attribute (c<->s) 1937 When quota is allocated for the first time by the DCC server, the 1938 translator has to create a QID AVP, as required by this 1939 specification. The translator later uses a QID AVP that is sent in 1940 the client-to-server direction in order to identify the corresponding 1941 DCC session. The QID has to be saved in the translator's per session 1942 state. 1944 5.2.4. Volume Quota Attribute (c<->s) 1946 If this AVP occurs in a message that is sent in the server-to-client 1947 direction, it is translated into a Granted-Service-Unit AVP with an 1948 embedded CC-Total-Octets AVP. [editor's note: this sentence belongs 1949 to the other translation type, i.e. AAA = RPP and client = DCC.] 1951 If this AVP occurs in a message that is sent in the client-to-server 1952 direction, then it is translated into a Used-Service-Unit AVP with an 1953 embedded CC-Total-Octets AVP. Note that only the difference between 1954 current cumulative quota for the (sub)session and the quota in 1955 incoming messages is indicated in the translated DCC message. Local 1956 state is updated with cumulative consumed resources. 1958 Conversely, if the server grants quota using the DCC Granted-Service- 1959 Unit AVP with an embedded CC-Total-Octets AVP, then the translation 1960 agent must translate this into a Volume Quota Attribute. Again, 1961 local state must be consulted so that the cumulative amount of octets 1962 is indicated in the Volume Quota attribute. 1964 5.2.5. Duration Quota Attribute (c<->s) 1966 If this AVP occurs in a message that is sent in the server-to-client 1967 direction, it is translated into a Granted-Service-Unit AVP with an 1968 embedded CC-Time AVP. [editor's note: this sentence belongs to the 1969 other translation type, i.e. AAA = RPP and client = DCC.] 1971 If this AVP occurs in a message that is sent in the client-to-server 1972 direction, then it is translated into a Used-Service-Unit AVP with an 1973 embedded CC-Time AVP. Note that only the difference between current 1974 cumulative quota for the (sub)session and the quota in incoming 1975 messages is indicated in the translated DCC message. Local state is 1976 updated with cumulative consumed resources (i.e. time). 1978 Conversely, if the server grants quota using the DCC Granted-Service- 1979 Unit AVP with an embedded CC-Time AVP, then the translation agent 1980 must translate this into a Duration Quota attribute. Again, local 1981 state must be consulted so that the cumulative amount of seconds is 1982 indicated in the Duaration Quota attribute. 1984 5.2.6. Resource Quota Attribute (c<->s) 1986 If this AVP occurs in a message that is sent in the server-to-client 1987 direction, it is translated into a Granted-Service-Unit AVP with an 1988 embedded CC-Service-Specific-Units AVP. [editor's note: this sentence 1989 belongs to the other translation type, i.e. AAA = RPP and client = 1990 DCC.] 1992 If this AVP occurs in a message that is sent in the client-to-server 1993 direction, then it is translated into a Used-Service-Unit AVP with an 1994 embedded CC-Service-Specific-Units AVP. Note that only the 1995 difference between current cumulative quota for the (sub)session and 1996 the quota in incoming messages is indicated in the translated DCC 1997 message. Local state is updated with cumulative consumed resources 1998 (i.e. resources). 2000 Conversely, if the server grants quota using the DCC Granted-Service- 2001 Unit AVP with an embedded CC-Service-Specific-Units AVP, then the 2002 translation agent must translate this into a Resource Quota 2003 attribute. Again, local state must be consulted so that the 2004 cumulative amount of resource units is indicated in the Resource 2005 Quota attribute. 2007 Note that the "resource" type is application dependent. This means 2008 that a DCC application unit corresponds to n RPP application units, 2009 where n may be any real number. If n is not 1, then the RPP/DCC 2010 translator must be aware of that and translate resource units 2011 accordingly. 2013 5.2.7. Value Digits Attribute (c<->s) 2015 The encoding of this AVP is similar in RPP and DCC, and the value it 2016 holds may have to be evaluated in conjunction with an acommpanying 2017 "Exponent" AVP. It should be kept in mind that, in RPP the 2018 cumulative amount of granted/consumed quota is typically encoded into 2019 an AVP of this type, while in DCC only the difference from a previous 2020 message. 2022 5.2.8. Exponent Attribute (c<->s) 2024 The encoding of this AVP is similar in RPP and DCC, and the value it 2025 holds may have to be evaluated in conjunction with an acommpanying 2026 "Value Digits" AVP. It should be kept in mind that, in RPP the 2027 cumulative amount of granted/consumed quota is typically encoded into 2028 a related "Value Digits" and "Exponent" AVP pair, while in DCC only 2029 the difference from a previous message is encoded into such a pair. 2031 5.2.9. Volume/Duration/Resource Threshold Attributes (s->c) 2033 In DCC the concept of "threshold" does not exist. Instead, the DCC 2034 client is assumed to ask for the replenishment of quota in good time. 2035 In RPP, on the other hand, the server may optionally include a 2036 threshold AVP, as an indication to the PPC about when to ask for 2037 quota replenishment. 2039 Thus, in this scenario, there is no need for the translator to ever 2040 include a threshold attribute into the messages that it sends to the 2041 PPC. If, however, there is a need for a threshold attribute to be 2042 present in order to avoid a possible service provision 2044 5.2.10. Update Reason Attribute (c->s) 2046 The DCC AVP that is semantically closer to the Update Reason AVP than 2047 any other AVP is the CC-Request-Type AVP. This AVP indicates whether 2048 the message is which it appears is intended to indicate an "initial", 2049 an "intermediate" or a "final interrogation". Morever, in case of 2050 the session being terminated at the client, it indicates the reason 2051 for this termination. 2053 The following list lists the possible values of an "Update Reason" 2054 attribute, along with corresponding values for the CC-Request-Type 2055 AVP. 2057 o Pre-initialization: No action/value defined. 2059 o Initial Request: Typically an "intial interrogation" is triggered 2060 as a result of the reception of the message that contains this 2061 Update Reason AVP. Hence, CC-Request-Type AVP indicates 2062 "INITIAL_REQUEST". 2064 o Threshold Reached: The reception of the message containing this 2065 Update Reason AVP typically triggers an "intermediate 2066 interrogation". Hence, CC-Request-Type AVP indicates 2067 "UPDATE_REQUEST". 2069 o Quota Reached: The reception of the message containing this Update 2070 Reason AVP typically triggers an "intermediate interrogation". 2071 Hence, CC-Request-Type AVP indicates "UPDATE_REQUEST". 2073 o TITSU Approaching: The reception of the message containing this 2074 Update Reason AVP typically triggers an "intermediate 2075 interrogation". Hence, CC-Request-Type AVP indicates 2076 "UPDATE_REQUEST". 2078 o Remote Forced Disconnect: Reception of such an Update Reason 2079 indicates that the client has terminated the session. The 2080 corresponding value for the CC-Request-Type AVP is 2081 "TERMINATION_REQUEST". 2083 o Client Service Termination: Reception of such an Update Reason 2084 indicates that the client has terminated the session. The 2085 corresponding value for the CC-Request-Type AVP is 2086 "TERMINATION_REQUEST". 2088 o "Access Service" Terminated: Reception of such an Update Reason 2089 indicates that the client has terminated the session. The 2090 corresponding value for the CC-Request-Type AVP is 2091 "TERMINATION_REQUEST". 2093 o Service not established: Reception of such an Update Reason 2094 indicates that the client has terminated the session. The 2095 corresponding value for the CC-Request-Type AVP is 2096 "TERMINATION_REQUEST". 2098 o One-Time Charging: Such an Update Reason indicates that a one-time 2099 charging event is initiated by the client. The corresponding 2100 value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a 2101 "Requested-Action: AVP MUST also be included in the outgoing DCC 2102 message. Typically, this would be of the type "DIRECT_DEBITING", 2103 or "REFUND_ACCOUNT", depending on other AVPs present in the 2104 message. 2106 5.2.11. PrepaidServer Attribute (s<->c) 2108 The PPC typically never sets the value of a PrepaidServer attribute. 2109 Instead, it repeats those values that it receives from the AAA 2110 infrastructure, in this scenario from the translator. This attribute 2111 is therefore not used in a translation scenario. Nevertheless, the 2112 translator must make sure that messages about the same RPP session 2113 are forwarded to the same DCC server, throughout the whole session. 2114 This may be easy to guarantee since the transport of Diameter is TCP. 2116 5.2.12. Service-ID Attribute (s<->c) 2118 The DCC equivalent of a RPP "Service-ID" AVP is the combination of 2119 Service-Context-Id and Service-Identifier AVPs. The translator must 2120 keep a static equivalence table of the RPP Service-ID and the 2121 corresponding DCC combination in order to correctly translate an RPP 2122 service identifier into DCC and back. 2124 5.2.13. Rating-Group-ID Attribute (s<->c) 2126 The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a 2127 "Rating-Group-ID". Depending on the configuration, this AVP may 2128 contain the same value on both the RPP and the DCC side of the 2129 communication. If, however, static rating groups are configured 2130 between the RCC client and the translator, and different rating 2131 groups between the DCC server and the translator, then the translator 2132 has to maintain a static translation table for the rating group 2133 identifier. In any case, the translation of a rating group AVP, is 2134 not a function of the translator's local per-session state. 2136 5.2.14. Termination-Action Attribute (s->c) 2138 The DCC equivalent of the "Termination-Action" AVP is called the 2139 "Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA 2140 infrastructure), a DCC "Final-Unit-Action" AVP is translated into a 2141 "Termination-Action" AVP. The following list contains the possible 2142 "Final-Unit-Action" values along with their "Termination-Action" 2143 equivalent. 2145 o TERMINATE (DCC): This value has a direct equivalent in RPP, also 2146 called "Terminate". 2148 o REDIRECT (DCC): If this value appears in a "Final-Unit-Action" 2149 AVP, then a "Redirect-Server-Address" AVP must also appear in the 2150 same DCC message. The translator translates these two AVPs into a 2151 "Termination-Action" with value "Redirect/Filter" and an 2152 eqiovalent NAS-Filter-Rule attribute (specified in http:// 2153 www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt). 2155 o RESTRICT_ACCESS (DCC): If this value appears in a "Final-Unit- 2156 Action" AVP, then a "Restriction-Filter-Rule" AVP must also appear 2157 in the same DCC message. The translator translates these two AVPs 2158 into a "Termination-Action" with value "Redirect/Filter" and an 2159 eqiovalent Filter-ID attribute (specified in http://www.ietf.org/ 2160 internet-drafts/draft-ietf-radext-ieee802-00.txt). 2162 o In the absence of a "Final-Unit-Action" AVP, the DCC server 2163 assumes that the DCC client will ask for replenishment of quota at 2164 some suitable time. In RPP, this is explicitly conveyed via a 2165 "Termination-Action" AVP with the value "Request More Quota". 2166 Thus, in the absence of a "Final-Unit-Action" AVP, the translator 2167 in this scenario appends such an AVP into the outgoing RPP 2168 message. 2170 5.2.15. Pool-ID Attribute (s<->c) 2172 The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID". 2173 Typically, no translation needs to be done to the "Pool-ID" 2174 attribute. 2176 5.2.16. Multiplier Attribute (s<->c) 2178 The multiplier attribute, which is a pair of "Value-Digits" and 2179 "Exponent" AVPs, typically needs no translation, since the value it 2180 carries (inside a "Value-Digits" and an "Exponent" AVP) represents 2181 the rating of the service or rating group to which it refers, with 2182 respect to abstract units. As such, the same multiplier value would 2183 typically applyt be conveyed from a DCC server to an PPC, and vice 2184 versa. 2186 5.2.17. Requested-Action Attribute (c->s) 2188 The "Requested Action" AVP can be directly translated into its DCC 2189 equivalent, which carries the same name. 2191 1. Balance Check (PCC): CHECK_BALANCE (DCC) 2193 2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC) 2195 5.2.18. Check-Balance-Result Attribute (s->c) 2197 This attribute carries only a binary value. Hence, its translation 2198 is straightforward. 2200 5.2.19. Cost-Information Attribute (s->c) 2202 This attribute consists of a Value-Digits AVP, an Exponent AVP, a 2203 Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise 2204 exist in DCC, and carry identical semantics in the context of the 2205 "Cost-Information" AVP. Thus, the translation of this attribute is 2206 straightforward. 2208 5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) 2210 This attribute carries the amount of octets that were consumed after 2211 a tariff change. It always appears in a message with an accompanying 2212 PPAQ attribute in which the total amount of octets (i.e. those that 2213 were consumed both before and after the tariff switch) is reported. 2214 Thus, the translation agent can compute the amount of octets that 2215 were consumed before the tariff change. 2217 In DCC, the two amounts, i.e. the octets that were consumed before a 2218 tariff change and those that were consumed afterwards, are reported 2219 in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs 2220 have an embedded CC-Total-Octets AVP that indicates the appropriate 2221 amount of octets. Furthermore, the Used-Service-Unit AVP that 2222 carries the amount that was consumed before the tariff switch also 2223 carries an embedded Tariff-Change-Usage AVP with the value 2224 UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP 2225 that carries the amount that was consumed after the tariff switch 2226 also carries an embedded Tariff-Change-Usage AVP with the value 2227 UNIT_AFTER_TARIFF_CHANGE (1). 2229 6. Security Considerations 2231 The extended RADIUS protocol described in this document is subject to 2232 a number of potential attacks, in a manner similar to the RADIUS 2233 protocol without these extensions. It is recommended that IPsec be 2234 employed to protect against certain of the attacks. 2236 7. IANA Considerations 2238 This document requires the assignment of new Radius attributes type 2239 numbers for the following attributes. Prepaid-Accounting-Capability 2240 (PPAC), AvailableInClient, Prepaid-Accounting-Operation (PPAQ), 2241 QuotaIdentifier, (QID), VolumeQuota (VQ), VolumeTreshold (VT), 2242 DurationQuota (DQ), DurationTreshold (DT), UpdateReason (UR), 2243 PrePaidServer (PPS), ServiceID (SID), Rating-Group-ID (RGID), 2244 TerminationAction (TA), PoolID (PID), PoolMultiplier (PM), Cost- 2245 Information (COST), Session-Termination-Capability (STC), 2246 PrepaidTariffSwitch (PTS), TariffSwitchInterval (TSI) and others. 2248 8. Acknowledgements 2250 The authors would like to thank Christian Guenther for his valuable 2251 insight and feedback and his active and ongoing contributions that he 2252 provided throughout the development of this document. 2254 9. References 2256 9.1. Normative References 2258 [1] Bradner, S., "RFC 2026: The Internet Standards Process -- 2259 Revision 3", October 1996. 2261 [2] Bradner, S., "RFC 2119: Key words for use in RFCs to Indicate 2262 Requirement Levels", March 1997. 2264 [3] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2865: 2265 Remote Authentication Dial In User Server (RADIUS)", June 2000. 2267 [4] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. 2269 [5] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS 2270 Extensions", June 2000. 2272 [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and 2273 I. Goyret, "RFC 2868: RADIUS Attributes for Tunnel Protocol 2274 Support", June 2000. 2276 [7] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Adoba, 2277 "RFC 3576: Dynamic Authorization Extensions to Remote 2278 Authentication Dial-In User Service (RADIUS)", February 2003. 2280 [8] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2281 Levkowetz, "RFC 3748: Extensible Authentication Protocol", 2282 June 2004. 2284 9.2. Informative References 2286 [9] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 2287 Loughney, "RFC 4006: Diameter Credit Control Application", 2288 August 2005. 2290 Appendix A. Example flows 2292 This section presents certain example flows that involve the RADIUS 2293 prepaid extensions. By no means is the intent of this section to 2294 specify or recommend business logic, rating strategies, and 2295 application-level behaviour. The intent of this section is purely to 2296 illustrate some fictive scenarios and the RADIUS prepaid message 2297 flows that could be associated with these scenarios. The contents of 2298 this section should be regarded as a collection of informative 2299 examples that aim to provide guidance to implementors. 2301 A.1. A simple flow 2303 End user PPC AAA Server PPS 2305 user logs on 2306 ------(1)---------> 2308 Access Request 2309 {RADIUS BASE AVPS, 2310 PPAC=00...00011} 2311 -------(2)--------> 2313 RADIUS authentication 2314 <--------------(3)----------------------> 2316 Access Request 2317 {RADIUS BASE AVPS, 2318 PPAC=00...00011} 2319 ------(4)---------> 2321 [allocates 2322 5MB quota] 2324 Access Response 2325 {RADIUS BASE AVPS, 2326 PPAQ={QID=5, VQ = 5MB, 2327 VTH = 4.5 MB}} 2328 <-------(5)-------- 2329 forwards message 2330 <-----(6)----------- 2332 service provision/metering 2333 -------(7)---------> 2335 4.5 MB consumed 2336 Access Request 2337 {RADIUS BASE AVPS, 2338 PPAQ={QID=5, VQ=4.5MB, 2339 REASON=THRESHOLD REACHED}} 2340 -------(8)---------> 2342 forwards message 2343 -------(9)-------> 2345 [allocates another 7MB 2346 to the access service] 2348 Access Response 2349 {RADIUS BASE AVPS, 2350 PPAQ={QID=8, VQ=12MB, 2351 VTH = 11.5 MB}} 2352 <----------(10)-------------- 2353 forwards message 2354 <------(11)-------- 2356 user logs off 2357 ------(12)------- 2359 Access Request 2360 {RADIUS BASE AVPS, 2361 PPAQ={QID=8, VQ=7 MB, 2362 REASON=ACCESS SERV TERMINATED}} 2363 -------(13)---------> 2365 forwards message 2366 -------(14)-------> 2368 [reimburses 2369 user account] 2371 AA Response 2372 {RADIUS BASE AVPS} 2373 <------(15)-------- 2374 AA Response 2375 {RADIUS BASE AVPS} 2376 <------(16)-------- 2378 Figure 12: A simple example message flow 2380 The user logs on (1). The PPC sends a RADIUS Access Request message 2381 to the home AAA server (2), and includes the prepaid-specific PPAC 2382 AVP. This AVP indicates that both duration-based and volume-based 2383 metering is supported. However, it also indicated that multiple 2384 services, rating groups and resource pools are not supported. Note 2385 that, since this is not an "Authorize-Only" message, no PPAQ AVP with 2386 Update Reason="initial request" is included (see Section 3.7.1). The 2387 home AAA server then authenticates the user and authorizes the access 2388 service, as is usual in RADIUS (3). Note that the PPAC AVP is 2389 appended by the PPC in at least the last message that is sent to the 2390 home AAA server during this possibly multiple-round exchange. 2392 If authentication and authorization is successful (in this example 2393 this is assumed), the home AAA server forwards the final Access 2394 Request to the PPS (4). The PPS identifies the user's prepaid 2395 account from the included base RADIUS AVPs, and determines the 2396 capabilities of the PPC from the PPAC attribute. Assuming that 2397 sufficient funds are available in the user's prepaid account, the PPS 2398 reserves some of these and rates the service. In this example, the 2399 PPS reserves, say, 2 Euros and determines that the access service is 2400 rated at 0.4 Euro per MB. This results in 5 MB of quota being 2401 granted. The PPS also determines that the PPC should ask for this 2402 quota to be replenished once 4.5 MB have been consumed. Thus, it 2403 creates an Access Accept message with a Volume-Threshold indication 2404 of 4.5MB. It further associates the QuotaIdentifier QID=5 to this 2405 quota reservation. This identifier can be used to later uniquely 2406 identify the prepaid session, user, account, etc. The resulting 2407 Access Accept message is sent to the home AAA server (5) and 2408 forwarded to the PPC (6). 2410 Upon reception of message (6), the PPC provides the access service to 2411 the user and meters it accordingly. 2413 At some point in time, the threshold is reached, i.e. 4.5MB of 2414 "access service" have been consumed by the user. At that point, the 2415 PPC generates an Authorize-Only Access Request that contains the 2416 usual RADIUS attributes and a PPAQ AVPs that reports the amount of 2417 consumed quota, and the request for replenishment, i.e. the Update- 2418 Reason= THRESHOLD REACHED (8). Note that the QID in this message is 2419 the same as the one previously received from the user's home AAA 2420 server. This message is forwarded to the PPS (9). 2422 Upon reception of message (9), the PPS identifies the user and his 2423 account from the QID. In also determines that a prepaid session is 2424 ongoing, and that enough credit remains in the prepaid account in 2425 order for the access service to continue being provided. Since 4.5 2426 MB have been consumed, the PPS subtracts 1.8 Euros from the user's 2427 prepaid account. The PPS decides to reserve another 2.8 euros from 2428 the user's account. (This results in 3 euros being reserved in total 2429 at this point in time.) As the access service is rated at 0.4 euros 2430 per MB, the PPS determines that another 7 MB of quota should be 2431 granted. This results in a total cumulative quota allocation of 12 2432 MB for the access service. The PPS further calculates the new 2433 threshold value of 11.5 MB. Since this is a new quota reservation, 2434 the PPS also allocates a new QuotaIdentifier to it, in this example 2435 QID=8. The resulting RADIUS message is sent to the home AAA server 2436 (10) and forwarded to the PPC (11). 2438 Upon reception of message (11), the PPC updates its records and 2439 continues provisioning access to the user. At some point the user 2440 logs off (12). The PPC must then report how many resources were 2441 consumed, so that the PPC can subtract the appropriate monetary 2442 amount from the user's prepaid account. To this end the PPC 2443 constructs an Authorize-Only Access Request message with a PPAQ AVPs 2444 for the access service. In this example, 7 MB were consumed by the 2445 access service in total. The PPC reports 7 MB its final message 2446 (13). This is forwarded to the PPS (14) which correlates the report, 2447 using the QID, to the previous session state. It determines, from 2448 the previous records, that the access service had consumed another 2449 4.5 MB before (as indicated in message (9)). This means that, of the 2450 7 MB, only 3.5 MB have not yet been subtracted from the user's 2451 account. Thus, the PPS subtracts another 1.4 euros from the user's 2452 account and, since the session is to be terminated (REASON=ACCESS 2453 SERVICE TERMINATED), releases any reserved monetary amount. 2455 The PPS responds with an Access Response as required by the RADIUS 2456 base specification (15). So does the home AAA server (16). 2458 A.2. A flow with prepaid tariff switching 2460 End user PPC AAA Server PPS 2462 user logs on 2463 ------(1)---------> 2465 Access Request 2466 {RADIUS BASE AVPS, 2467 PPAC=00...00111} 2468 -------(2)--------> 2470 RADIUS authentication 2471 <--------------(3)----------------------> 2473 Access Request 2474 {RADIUS BASE AVPS, 2475 PPAC=00...00011} 2476 ------(4)---------> 2478 [allocates 2479 20MB quota] 2481 Access Response 2482 {RADIUS BASE AVPS, 2483 PPAQ={QID=5, VQ = 20MB, 2484 VTH = 18 MB}, PTS={ 2485 QID=5, PTS{TSI=300sec, 2486 TITSU=6000sec}} 2487 <-------(5)-------- 2488 forwards message 2489 <-----(6)----------- 2491 service provision/metering 2492 -------(7)---------> 2494 5900 seconds have passed 2496 Access Request 2497 {RADIUS BASE AVPS, 2498 PPAQ={QID=5, VQ=14MB, 2499 REASON=TITSU APPROACH.}, 2500 TSI={QID=5, VUATS=11MB}} 2501 -------(8)---------> 2503 forwards message 2504 -------(9)-------> 2506 [allocates another 10MB 2507 to the access service] 2509 Access Response 2510 {RADIUS BASE AVPS, 2511 PPAQ={QID=8, VQ=30MB, 2512 VTH = 28 MB},PTS={ 2513 QUD=8, PTS=95 sec}} 2514 <----------(10)-------------- 2515 forwards message 2516 <------(11)-------- 2518 user logs off 2519 ------(12)------- 2521 Access Request 2522 {RADIUS BASE AVPS, 2523 PPAQ={QID=8, VQ=17 MB, 2524 REASON=ACCESS SERV TERMINATED}, 2525 PTS={QID=8, VUATS=2.5 MB} 2526 -------(13)---------> 2528 forwards message 2529 -------(14)-------> 2531 [reimburses 2532 user account] 2534 AA Response 2535 {RADIUS BASE AVPS} 2536 <------(15)-------- 2537 AA Response 2538 {RADIUS BASE AVPS} 2539 <------(16)-------- 2541 Figure 13: Example message flow with Tariff Switch 2543 The user logs on (1). The PPC sends a RADIUS Access Request message 2544 to the home AAA server (2), and includes the prepaid-specific PPAC 2545 AVP. This AVP indicates that both duration-based and volume-based 2546 metering is supported, as well as tariff switching. The home AAA 2547 server then authenticates and user and authorizes the access service, 2548 as is usual in RADIUS (3). Note that the PPAC AVP is appended by the 2549 PPC in at least the last message that is sent to the home AAA server 2550 during this possibly multiple-round exchange. 2552 If authentication and authorization is successful (in this example 2553 this is assumed), the home AAA server forwards the final Access 2554 Request to the PPS (4). The PPS identifies the user's prepaid 2555 account from the included base RADIUS AVPs, and determines the 2556 capabilities of the PPC from the PPAC attribute. In this example, it 2557 is assumed that a tariff switch is about to occur in 300 seconds from 2558 the current time. Suppose that the access service is currently rated 2559 at 0.5 euros per MB and in the next tariff period it is rated at 0.6 2560 euros per MB. Suppose further that a third tariff period is about to 2561 start in 6000 seconds from current time and that that access service 2562 is rated at 0.8 euros per MB in that period. The PPS then decides to 2563 reserve 12 euros from the user's account. Since it is conceivable 2564 that the user may consume all allocated quota in the (more expensive) 2565 "0.6-euro" period, the PPS reserves 20 MB of quota, and determines a 2566 threshold value of 18 MB. It constructs a Radius Access Accept 2567 message with a PPAQ attribute that reflects these choices, and 2568 carries a QuotaIdentifier QID=5. It further adds a PTS AVP in the 2569 message which is linked to the PPAQ via the common QID value. The 2570 PTS AVP contains a TSI attribute indicating that a tariff switch will 2571 occur in 300 seconds. It also includes a TITSU attribute with the 2572 value of 6000 seconds. This is included in order to make sure that 2573 the PPC will report the consumed quota before the "2-euro" tariff 2574 period will start. The message is sent to the AAA server (5) and 2575 forwarded to the PPC (6). 2577 Upon reception of message (6), the PPC provides the access service to 2578 the user and meters it accordingly (7). It also keeps track of time. 2579 That is, it remembers how many octets are consumed before and how 2580 many after the tariff switch that will take place in 300 seconds. 2582 In this example it is assumed that the user consumes the allocated 2583 quota rather slowly. In particular, nearly 6000 seconds (the value 2584 indicated by TITSU) pass without the threshold of 18 MB being 2585 reached. The PPC notices this and must therefore report usage and 2586 request the quota to be replenished despite the fact that the 2587 threshold has not been reached. In this example, it decides to do so 2588 100 seconds before the 6000 seconds are reached. To this end, it 2589 constructs an Authorization Access Request message including a PPAQ 2590 that indicates that 14 MB have been consumed up to now. It also 2591 includes a PTS AVP in order to indicate, using the VUATS AVP, that 11 2592 MB of these were consumed after the tariff switch. The message is 2593 sent to the AAA server (8) and forwarded to the PPS (9). 2595 The PPS can link the message to previous session state via the QID. 2596 It now rates the consumed volume as follows. The 11 MB that were 2597 consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros 2598 and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS 2599 subtracts the amount of 6.6+1.5=8.1 euros from the user's account, 2600 which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved. 2602 The PPS now determines that message (9) was sent in order to 2603 replenish the quota for this prepaid session. This can be deduced 2604 from the UPDATE REASON field, which indicates that the PPC sent this 2605 message because the time indicated by the TITSU AVP is approacing. 2606 The PPS now determines that enough credit remains in the user's 2607 prepaid account in order for the access service to continue being 2608 provided and decides to reserve another 8.9 euros from the user's 2609 account. Since it is conceivable that the user will consume the 6 2610 unused MB of quota from the previous allocation, as well as the 2611 entire quota that is to be allocated now, entirely in the "0.8-euro" 2612 period, the quota that should now be granted in addition to the 2613 previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros 2614 are being reserved in order to "cover the worst case scenario". The 2615 fact that 0.9 euros are reserved for this purpose is due to the fact 2616 that the unused 6 MB from the previous allocation correspond to 4.8 2617 euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more 2618 than the amount of funds that are still "reserved" from the previous 2619 allocation. (After this reservation, the total amount of reserved 2620 money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB 2621 being consumed in the "0.8-euro" period.) 2623 Since quotas are encoded in a cumulative way in RADIUS, the PPS 2624 includes a VolumeQuota of 30 MB into the Access Accept message (10). 2625 The PPS further calculates the new threshold value of 28 MB. Since 2626 this is a new quota reservation, the PPS also allocates a new 2627 QuotaIdentifier to it, in this example QID=8. The resulting RADIUS 2628 message is sent to the home AAA server (10) and forwarded to the PPC 2629 (11). 2631 Upon reception of message (11), the PPC updates its records and 2632 continues providing access to the user. At some point the user logs 2633 off (12). The PPC must then report how many resources were consumed, 2634 so that the PPC can subtract the appropriate monetary amount from the 2635 user's prepaid account. To this end the PPC constructs an Authorize- 2636 Only Access Request message with a PPAQ AVPs for the access service. 2637 In this example, 17 MB were consumed by the access service in total. 2638 The PPC reports 17 MB its final message (13). This is forwarded to 2639 the PPS (14) which correlates the report, using the QID, to the 2640 previous session state. It determines, from the previous records, 2641 that the access service had consumed 14 MB before (as indicated in 2642 message (9)). This means that, of the 17 MB, only the monetary 2643 equivalent for 3 MB have not yet been subtracted from the user's 2644 account. The PPS calculates how much should be deducted from the 2645 user's account as follows. Since the VUATS AVP indicates that 2.5MB 2646 were consumed after the tariff switch, only 0.5 MB were consumed 2647 before that. Thus, the monetary equivalent is 0.5 * 0.6 + 2.5 * 0.8 2648 = 3.6 euros. That is, the PPS subtracts 3.6 euros from the user's 2649 prepaid account. Since the session has by now be terminated by the 2650 PPC (REASON=ACCESS SERVICE TERMINATED), the PPS now releases any 2651 reserved monetary amount, in this example 12.8 - 3.6 = 9.2 euros. 2653 The PPS responds with an Access Response as required by the RADIUS 2654 base specification (15). So does the home AAA server (16). 2656 Remark: In this example, two tariff switches take place. In other 2657 scenarios, of course, only one tariff switch may occur. In such 2658 scenarios the TITSU AVP is not used. 2660 A.3. Resource pools and Rating Groups 2662 End user PPC AAA Server PPS 2663 user logs on 2664 ------(1)---------> 2666 Access Request 2667 {RADIUS BASE AVPS, 2668 PPAC=00...00101111} 2669 -------(2)--------> 2671 RADIUS authentication 2672 <--------------(3)----------------------> 2674 Access Request 2675 {RADIUS BASE AVPS, 2676 PPAC=00...00101111} 2677 ------(4)---------> 2679 [allocates 2680 5MB quota] 2682 Access Response 2683 {RADIUS BASE AVPS, 2684 PPAQ={QID=5, VQ = 5MB, 2685 poolID=1,mult=1}} 2686 <-------(5)-------- 2687 forwards message 2688 <-----(6)----------- 2690 service provision/metering 2691 -------(7)---------> 2693 user requests service A 2694 -------(8)---------> 2696 Access Request 2697 {RADIUS BASE AVPS,PPAQ={ 2698 SID="A", RGROUP=1}} 2699 -------(9)--------> 2700 forwards message 2701 -----(10)---------> 2703 [allocates 50 min 2704 quota] 2706 Access Response 2707 {RADIUS BASE AVPS, 2708 PPAQ={QID=7, DQ=3000sec 2709 poolID=1,RGROUP=1, SID="A" 2710 mult=1747.63}} 2712 <---------(11)--------------- 2713 forwards message 2714 <----(12)-------- 2716 user requests service B 2717 -------(13)--------> 2719 Pool 1 close to exhaustion 2721 Access Request 2722 {RADIUS BASE AVPS, 2723 PPAQ={QID=5, VQ=4MB, 2724 REASON=QUOTA REACHED, 2725 PoolID=1, mult=1} 2726 PPAQ={QID=7, DQ=3300sec 2727 REASON=QUOTA REACHED, 2728 PoolID=1, mult=1747.63, 2729 SID="A",RGROUP=1}} 2730 -------(14)---------> 2732 forwards message 2733 -------(15)-------> 2735 [allocates another 2736 3 MB to access service 2737 and 30 minutes to 2738 service "A"] 2740 Access Response 2741 {RADIUS BASE AVPS, 2742 PPAQ={QID=8, VQ=8MB, 2743 PoolID=1, mult=1, RGROUP=1}, 2744 PPAQ={QID=9, DQ=4800sec 2745 PoolID=1, mult=1747.63, 2746 SID="A"}} 2747 <----------(16)-------------- 2748 forwards message 2749 <------(17)-------- 2751 user logs off 2752 ------(18)------- 2754 Access Request 2755 {RADIUS BASE AVPS, 2756 PPAQ={QID=8, VQ=6.5MB, 2757 REASON=ACCESS SERV TERMINATED, 2758 PoolID=1, mult=1} 2759 PPAQ={QID=9, DQ=5400sec 2760 REASON=ACCESS SERV TERMINATED, 2761 PoolID=1, mult=1747.63, 2762 SID="A",RGROUP=1}} 2763 -------(19)---------> 2765 forwards message 2766 -------(20)-------> 2768 [reimburses 2769 user account] 2771 AA Response 2772 {RADIUS BASE AVPS 2773 <------(21)-------- 2774 AA Response 2775 {RADIUS BASE AVPS 2776 <------(22)-------- 2778 Figure 14: Example message flow with resource pools and rating groups 2780 The user logs on (1). The PPC sends a RADIUS Access Request message 2781 to the home AAA server (2), and includes the prepaid-specific PPAC 2782 AVP, indicating that multiple services, rating groups and resource 2783 pools are supported. Note that, since this is not an "Authorize- 2784 Only" message, no PPAQ AVP with Update Reason="initial request" is 2785 included (see Section 3.7.1). The home AAA server then authenticates 2786 the user and authorizes the access service, as is usual in RADIUS 2787 (3). Note that the PPAC AVP is appended by the PPC in at least the 2788 last message that is sent to the home AAA server during this possibly 2789 multiple-round exchange. 2791 If authentication and authorization is successful (in this example 2792 this is assumed), the home AAA server forwards the final Access 2793 Request to the PPS (4). The PPS identifies the user's prepaid 2794 account from the included base RADIUS AVPs, and determines the 2795 capabilities of the PPC from the PPAC attribute. Assuming that 2796 sufficient funds are available in the user's prepaid account, the PPS 2797 reserves some of these and rates the service. In this example, the 2798 PPS reserves 5 Euros and determines that the access service is rated 2799 at 1 Euro per MB. In anticipation that the user requests more 2800 chargeable services throughout this prepaid session, and since this 2801 is supported by the PPC, the PPS further associates a resource pool 2802 with this reservation, in this example PoolID=1. The PPC also 2803 specifies the multiplier = 1 for the access service. Note that, 2804 since 5MB = 5242880 octets, 1 unit in the resource pool corresponds 2805 to 5 / 5242880 euros, which is about 0.000095367431640625 Eurocents. 2807 (However, the PPC does not need to know that.) Moreover, the PPS 2808 associates the QuotaIdentifier QID=5 to this quota reservation. This 2809 identifier can be used to later uniquely identify the prepaid 2810 session, user, account, etc. The resulting Access Accept message is 2811 sent to the home AAA server (5) and forwarded to the PPC (6). 2813 Upon reception of message (6), the PPC provides the access service to 2814 the user and meters it accordingly. That is, for every octet 2815 consumed, the PPC subtracts 1 unit (since the multiplier is 1) from 2816 the resouce pool with PoolID=1. 2818 At some point in time, the user requests another chargeable service, 2819 namely service A (8). The PPC generates an Authorize-Only Access 2820 Request that contains the usual RADIUS attributes and the Service-ID 2821 identifying service A (9). The PPC has determined that service A is 2822 rated in an identical way as at least one more service. Thus, 2823 service A has been configured to belong to a rating group, in this 2824 example the group with Rating-Group-ID=1. This identifier is 2825 included is message (9), which is then forwarded to the PPS (10). 2827 Upon reception of message (10), the PPS identifies the user and his 2828 account from the base RADIUS attributes, the fact that a prepaid 2829 session is ongoing, and determines that enough credit remains in the 2830 prepaid account in order for service A to be provided. The PPS also 2831 determines that service A is rated at 0.10 euros per minute. The PPS 2832 decides to reserve another 5 euros from the users account; this 2833 corresponds to 50 minutes or, as encoded in the DurationQuota AVP, 2834 3000 seconds. As service A draws from the same prepaid account as 2835 the access service, the PPS associates this reservation with the same 2836 resource pool as the previous reservation (QID=5), namely the pool 2837 with PoolID=1. Note that, in order for the abstract units in the 2838 pool to be consistent, the multiplier has to be 1747.63. This is 2839 because each second corresponds to about 0.10 / 60 = 0.00167 euros, 2840 which is about 1747.63 times the value of an abstract resource pool 2841 unit, as this was determined by the first allocation of quota to the 2842 pool (i.e. 0.000095367431640625 Eurocents). Since this is a new 2843 quota reservation, the PPS also allocates a new QuotaIdentifier to 2844 it, in this example QID=7. The resulting RADIUS message is sent to 2845 the home AAA server (11) and forwarded to the PPC (12). 2847 Upon reception of message (12), the PPC adjusts the units in resource 2848 pool 1. That is, it first determines how much quota had been 2849 allocated to service A in the past, and subtracts this from the quota 2850 reservation found in the message. Since this is the first quota 2851 reservation for service A, there is nothing to subtract. Thus, it 2852 adds 3000 * 1747.63 = 5242890 units to the pool and remembers that 2853 3000 seconds have been allocated to service A during this prepaid 2854 session. The PPC then provides service A to the user, and meters it 2855 against resource pool 1. That is, for every second it subtracts 2856 1747.63 units from the pool. 2858 At some point in time, the user requests service B (13). The PPC 2859 determines that service B is rated exactly in the same way as service 2860 A, i.e. that they belong to the same rating group, namely the one 2861 with Rating-Group-ID=1. Since this rating group has been effectively 2862 authorised by the allocation of quota with QID=7, the PPC provides 2863 service B to the user immediately. It is rated in the same way as 2864 service A, i.e. for every second provided, 1747.63 units are 2865 subtracted from credit pool 1. 2867 At some point in time, resource pool 1 is close to exhaustion. (For 2868 example, the PPC may determine that the pool is "close to exhaustion" 2869 when has less than 10% its initial amount of units.) At that point, 2870 the PPC needs to ask for replenishment for the pool. Suppose that, 2871 at that point in time, 4MB of "access service", 45 minutes of 2872 "service A", and 10 minutes of "service B" were provided to the user. 2873 Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304 2874 + 5767179 = 9961483 abstract service units from the pool. The PPC 2875 constructs an Authorize-Only Access Request message that reports the 2876 usage for the "access service" and "service A". This message 2877 contains two PPAQ AVPS, is sent to the home AAA server (14) and 2878 forwarded to the PPS (15). Note that is the message it appears that 2879 "service A" has consumed more than it was allocated (i.e. 55 minutes 2880 although only 50 minutes were initially allocated to it). This is 2881 not a a problem since the PPS knows that "service A" was drawing from 2882 the same pool as the "access service" and that the "access service" 2883 did only consume 4 out of the 5 MB it was allocated. 2885 Upon reception of message (15), the PPS subtracts 4 euros from the 2886 user's account for the "access service" and another 5.5 euros for 2887 "service A". (This includes the charge incurred by "service B" up to 2888 that point in time, although the PPS is not aware of "service B" 2889 being provisioned to the user.) The PPS then determines that 2890 sufficient funds remain in the prepaid account in order for both 2891 services to be continued. The PPS decides to reserve another 3MB for 2892 the access service and 30 minutes for "service A". This corresponds 2893 to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a 2894 cumulative manner, the PPAQ attribute that grants the quota for the 2895 "access service" contains a Volume-Quota AVP of 8MB (8388608 octets), 2896 which is the 5MB that were initially allocated, plus the 3MB 2897 allocated now. The resource pool identifier is, as previously, 2898 PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants 2899 quota for "service A" contains 4800 seconds (the initial 3000 plus 2900 1800 that correspond to the 30 additional minutes). Again, the 2901 PoolID=1 and multiplier=1747.63. The resulting Access Response 2902 message is sent to the home AAA server (16) and forwarded to the PPC 2903 (17). 2905 When the PPC received message (17) it checks how much quota has been 2906 allocated previously to the "access service". It finds that the 2907 answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets) 2908 that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets) 2909 have not yet been added to resource pool 1. The PPC thus adds 2910 3145728 abstract units to resource pool 1 (since the multiplier is 2911 1). The PPC then acts similarly on the other PPAQ attribute that 2912 exists in message (17). That is, the PPC determines that 3000 2913 seconds of quota for "service A" had already been added to the pool. 2914 Thus only 1800 out of the 4800 should be additionally added to the 2915 pool. Since the applicable multiplier here is 1747.63, the PPC adds 2916 further 3145734 abstract units to the pool 1. 2918 The PPC then continues to provide the access service, "service A" and 2919 "service B" to the user, and meters them against the pool, as 2920 previously. 2922 At some point the user logs off (18). The PPC must then report how 2923 many resources were consumed, so that the PPC can subtract the 2924 appropriate monetary amount from the user's prepaid account. To this 2925 end the PPC constructs an Authorize-Only Access Request message with 2926 two PPAQ AVPs; one for the access service and one for "service A". 2927 Suppose that, in total, 6.5MB were consumed by the access service, 70 2928 minutes were consumed by "service A" and 20 minutes by "service B". 2929 The PPC reports 6.5MB (6815744 octets) and 90 minutes (5400 seconds) 2930 in its final message (19). This is forwarded to the PPS which 2931 determines, from the previous records, that the access service 2932 consumed another 2.5MB (since 4MB out of the 6.5MB were already 2933 reported in message (15), and that "service A" consumed further 600 2934 seconds. This corresponds to 2.5 + (600/60)*0.1 = 2.5+1=3.5 euros. 2935 Thus, the PPS only subtracts 2.5 out of the 6 previously reserved 2936 euros from the user's prepaid account and responds with an Access 2937 Response as required by the RADIUS base specification. 2939 The home AAA server likewise responds with an Access Response. 2941 Authors' Addresses 2943 Avi Lior 2944 Bridgewater Systems 2945 303 Terry Fox Drive 2946 Ottawa, Ontario Suite 100 2947 Canada 2949 Email: avi@bridgewatersystems.com 2951 Parviz Yegani 2952 Cisco 2953 Mobile Wireless Group, Cisco Systems 2954 3625 Cisco Way, San Jose, California 95134 2955 USA 2957 Email: pyegani@cisco.com 2959 Kuntal Chowdhury 2960 Starent Networks 2961 30 International Place, 3rd Floor 2962 Tewksbury, MA 01876 2963 USA 2965 Email: kchowdhury@starentnetworks.com 2967 Hannes Tschofenig 2968 Siemens 2969 Otto-Hahn Ring 6 2970 Munich, Bavaria 81739 2971 Germany 2973 Email: hannes.tschofenig@siemens.com 2975 Andreas Pashalidis 2976 Siemens 2977 Otto-Hahn Ring 6 2978 Munich, Bavaria 81739 2979 Germany 2981 Email: andreas.pashalidis@siemens.com 2983 Intellectual Property Statement 2985 The IETF takes no position regarding the validity or scope of any 2986 Intellectual Property Rights or other rights that might be claimed to 2987 pertain to the implementation or use of the technology described in 2988 this document or the extent to which any license under such rights 2989 might or might not be available; nor does it represent that it has 2990 made any independent effort to identify any such rights. Information 2991 on the procedures with respect to rights in RFC documents can be 2992 found in BCP 78 and BCP 79. 2994 Copies of IPR disclosures made to the IETF Secretariat and any 2995 assurances of licenses to be made available, or the result of an 2996 attempt made to obtain a general license or permission for the use of 2997 such proprietary rights by implementers or users of this 2998 specification can be obtained from the IETF on-line IPR repository at 2999 http://www.ietf.org/ipr. 3001 The IETF invites any interested party to bring to its attention any 3002 copyrights, patents or patent applications, or other proprietary 3003 rights that may cover technology that may be required to implement 3004 this standard. Please address the information to the IETF at 3005 ietf-ipr@ietf.org. 3007 Disclaimer of Validity 3009 This document and the information contained herein are provided on an 3010 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3011 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3012 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3013 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3014 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3015 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3017 Copyright Statement 3019 Copyright (C) The Internet Society (2006). This document is subject 3020 to the rights, licenses and restrictions contained in BCP 78, and 3021 except as set forth therein, the authors retain all their rights. 3023 Acknowledgment 3025 Funding for the RFC Editor function is currently provided by the 3026 Internet Society.