idnits 2.17.00 (12 Aug 2021) /tmp/idnits52635/draft-lior-radius-prepaid-extensions-09.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 2996. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2986. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A PPAQ 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 (October 23, 2005) is 6053 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 541 -- Looks like a reference, but probably isn't: 'RFC3576' on line 1120 == Missing Reference: '3576' is mentioned on line 1192, but not defined -- Looks like a reference, but probably isn't: 'DIAMETERCC' on line 1362 -- Looks like a reference, but probably isn't: 'RFC2865' on line 1370 == Unused Reference: '4' is defined on line 2248, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2251, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2253, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2257, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2261, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2267, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '6') ** Obsolete normative reference: RFC 3576 (ref. '7') (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4006 (ref. '9') (Obsoleted by RFC 8506) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT A. Lior 3 Internet-Draft Bridgewater Systems 4 Expires: April 26, 2006 P. Yegani 5 Cisco 6 K. Chowdhury 7 Starent Networks 8 H. Tschofenig 9 A. Pashalidis 10 Siemens 11 October 23, 2005 13 Prepaid extensions to Remote Authentication Dial-In User Service 14 (RADIUS) 15 draft-lior-radius-prepaid-extensions-09.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 April 26, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This draft presents an extension to the Remote Authentication Dial- 49 In User Service (RADIUS) protocol to support charging for prepaid 50 services. The charging models supported are namely: volume-based 51 charging, duration-based charging and one-time-based charging. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 57 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7 59 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 11 60 1.3. A simple use case . . . . . . . . . . . . . . . . . . . . 13 61 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 15 62 2.1. Multiple Concurrent Services . . . . . . . . . . . . . . . 15 63 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 15 64 2.3. Complex Rating Functions . . . . . . . . . . . . . . . . . 17 65 2.4. One-time Charging . . . . . . . . . . . . . . . . . . . . 17 66 2.5. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 18 67 2.6. Support for Roaming . . . . . . . . . . . . . . . . . . . 20 68 2.7. Dynamic Termination . . . . . . . . . . . . . . . . . . . 20 69 2.8. Querying and Rebalancing . . . . . . . . . . . . . . . . . 20 70 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 3.1. Authentication and Authorization Operation . . . . . . . . 22 72 3.2. Session Start Operation . . . . . . . . . . . . . . . . . 24 73 3.3. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24 74 3.4. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26 75 3.4.1. Unsolicited Session Termination Operation . . . . . . 26 76 3.4.2. Unsolicited Change of Authorization Operation . . . . 26 77 3.5. Termination Operation . . . . . . . . . . . . . . . . . . 27 78 3.6. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27 79 3.7. Operation Considerations for Multiple Services . . . . . . 28 80 3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 28 81 3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29 82 3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 29 83 3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 30 84 3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 30 85 3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 30 86 3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 31 87 3.7.8. Accounting Considerations . . . . . . . . . . . . . . 31 88 3.7.9. Interoperability with Diameter Credit Control 89 Application . . . . . . . . . . . . . . . . . . . . . 31 90 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32 91 4.1. PPAC Attribute . . . . . . . . . . . . . . . . . . . . . . 32 92 4.2. Session Termination Attribute . . . . . . . . . . . . . . 33 93 4.3. PPAQ Attribute . . . . . . . . . . . . . . . . . . . . . . 34 94 4.3.1. Quota Identifier AVP . . . . . . . . . . . . . . . . . 34 95 4.3.2. VolumeQuota AVP . . . . . . . . . . . . . . . . . . . 35 96 4.3.3. VolumeThreshold AVP . . . . . . . . . . . . . . . . . 35 97 4.3.4. DurationQuota AVP . . . . . . . . . . . . . . . . . . 35 98 4.3.5. DurationThreshold AVP . . . . . . . . . . . . . . . . 35 99 4.3.6. ResourceQuota AVP . . . . . . . . . . . . . . . . . . 36 100 4.3.7. ResourceThreshold AVP . . . . . . . . . . . . . . . . 36 101 4.3.8. Value-Digits AVP . . . . . . . . . . . . . . . . . . . 36 102 4.3.9. Exponent AVP . . . . . . . . . . . . . . . . . . . . . 36 103 4.3.10. Update-Reason AVP . . . . . . . . . . . . . . . . . . 36 104 4.3.11. PrepaidServer AVP . . . . . . . . . . . . . . . . . . 37 105 4.3.12. Service-ID AVP . . . . . . . . . . . . . . . . . . . . 37 106 4.3.13. Rating-Group-ID AVP . . . . . . . . . . . . . . . . . 37 107 4.3.14. Termination-Action AVP . . . . . . . . . . . . . . . . 38 108 4.3.15. Pool-ID AVP . . . . . . . . . . . . . . . . . . . . . 38 109 4.3.16. Pool-Multiplier AVP . . . . . . . . . . . . . . . . . 38 110 4.3.17. Requested-Action AVP . . . . . . . . . . . . . . . . . 38 111 4.3.18. Check-Balance-Result AVP . . . . . . . . . . . . . . . 39 112 4.3.19. Cost-Information AVP . . . . . . . . . . . . . . . . . 39 113 4.4. Prepaid Tariff Switching Attribute (PTS) . . . . . . . . . 40 114 4.4.1. VolumeUsedAfterTariffSwitch AVP . . . . . . . . . . . 40 115 4.4.2. TariffSwitchInterval AVP . . . . . . . . . . . . . . . 41 116 4.4.3. TimeIntervalafterTariffSwitchUpdate AVP . . . . . . . 41 117 5. Translation between RADIUS prepaid and Diameter Credit 118 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 119 5.1. Session Identification . . . . . . . . . . . . . . . . . . 43 120 5.2. Translation between RADIUS prepaid client and Diameter 121 Credit Control AAA infrastructure . . . . . . . . . . . . 43 122 5.2.1. PPAC (c<->s) . . . . . . . . . . . . . . . . . . . . . 43 123 5.2.2. Service Termination Attribute (c->s) . . . . . . . . . 44 124 5.2.3. Quota Identifier Attribute (c<->s) . . . . . . . . . . 44 125 5.2.4. Volume Quota Attribute (c<->s) . . . . . . . . . . . . 44 126 5.2.5. Duration Quota Attribute (c<->s) . . . . . . . . . . . 45 127 5.2.6. Resource Quota Attribute (c<->s) . . . . . . . . . . . 45 128 5.2.7. Value Digits Attribute (c<->s) . . . . . . . . . . . . 46 129 5.2.8. Exponent Attribute (c<->s) . . . . . . . . . . . . . . 46 130 5.2.9. Volume/Duration/Resource Threshold Attributes 131 (s->c) . . . . . . . . . . . . . . . . . . . . . . . . 46 132 5.2.10. Update Reason Attribute (c->s) . . . . . . . . . . . . 46 133 5.2.11. PrepaidServer Attribute (s<->c) . . . . . . . . . . . 48 134 5.2.12. Service-ID Attribute (s<->c) . . . . . . . . . . . . . 48 135 5.2.13. Rating-Group-ID Attribute (s<->c) . . . . . . . . . . 48 136 5.2.14. Termination-Action Attribute (s->c) . . . . . . . . . 48 137 5.2.15. Pool-ID Attribute (s<->c) . . . . . . . . . . . . . . 49 138 5.2.16. Multiplier Attribute (s<->c) . . . . . . . . . . . . . 49 139 5.2.17. Requested-Action Attribute (c->s) . . . . . . . . . . 49 140 5.2.18. Check-Balance-Result Attribute (s->c) . . . . . . . . 49 141 5.2.19. Cost-Information Attribute (s->c) . . . . . . . . . . 50 142 5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) . . . . . 50 143 6. Security Considerations . . . . . . . . . . . . . . . . . . . 51 144 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 145 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 146 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 147 9.1. Normative References . . . . . . . . . . . . . . . . . . . 54 148 9.2. Informative References . . . . . . . . . . . . . . . . . . 54 149 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 55 150 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 55 151 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 58 152 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 62 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 154 Intellectual Property and Copyright Statements . . . . . . . . . . 70 156 1. Introduction 158 This draft describes extentions for the RADIUS protocol. These 159 extensions are meant to enable service providers to charge and bill 160 their customers using prepaid accounts. 162 A prepaid service subscriber is a user who has purchased a contract 163 according to which he will receive a particular data service for 164 either a period of time or a quantity of data. In the typical 165 prepaid scenario, the service provider verifies that the subscriber 166 has sufficient funds in his account before delivering the service. 167 Only if suffiecient funds are available is the service provided to 168 the user. 170 The business driver behind the protocol extensions defined in this 171 document is to increase participation (i.e. a service provider's 172 subscriber base) and thus to increase revenues. In particular, the 173 extensions were designed with the following goals in mind. 175 o Make use of existing infrastructure as much as possible (including 176 enabling the interworking of RADIUS-based and Diameter-based 177 infrastructures), and thereby limit the amount of necessary 178 capital expenditures, 180 o provide the ability to rate service requests in real-time, 182 o provide the ability to charge the user's account prior to service 183 provision, 185 o protect against revenue loss, i.e. to prevent an end user from 186 obtaining service when the available funds are not sufficient, 188 o protect against fraud, and 190 o be deployable over dialup, wired and wireless networks. 192 The architecture between the entities that execute the RADIUS 193 protocols, with the extensions defined in this document, assumes that 194 the rating of chargeable events does not occur in the element that 195 provides the service. Instead, the rating may be performed at a 196 dedicated server, termed the "prepaid enabled AAA server" or simply 197 "prepaid server". Alternatively, the actual rating may occur in an 198 entity behind this prepaid server. Furthermore, business logic may 199 dictate a time-dependent tariff model, for example that the price for 200 a service may switch at 8pm from a high to a low tariff. The 201 extensions defined in this document support such scenarios. 203 Furthermore, this documents assumes an architecture where a "quota 204 server" is available which, through co-ordination with the rating 205 entity and a centralized account balance manager, is able to provide 206 a quota indication for a particular user when requested. This quota 207 server may or may not coexist in the prepaid server. 209 1.1. Terminology 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [1]. 215 Furthermore, this document uses the following terms: 217 Network Access Server (NAS): 219 As defined in RADIUS [2]. 221 Prepaid client (PPC): 223 The entity which triggers the RADIUS message exchange, including 224 the prepaid extensions defined in this document. The PPC 225 typically resides in the NAS. 227 Prepaid Server (PPS): 229 The entity that interacts with the PPC using the RADIUS prepaid 230 extensions defined in this document. 232 Home Network: 234 The network which contains the user profile and the user's prepaid 235 account. 237 1.2. Overview 239 This section provides an overview of the prepaid charging models and 240 architectures, which are supported by the extensions described in 241 this draft. 243 A number of models of how to charge customers for data services in a 244 prepaid manner are supported, as follows. 246 o Volume-based charging: (e.g. 2 Cents/KiloByte). 248 o Duration-based charging: (e.g. 3 Cents/minute). 250 o Subscription-based charging: (e.g. Dollars/month). 252 o Event-based charging: (e.g. 7 Cents/URL or email) . 254 This draft assumes that the user maintains a prepaid account with his 255 home network. However, whether this account is a dedicated prepaid 256 account or not (such as a current bank account) is outside the scope 257 of this document. Similarly, the means by which the subscriber 258 obtains funds is also outside the scope of this document. In some 259 scenarios, the subscriber's account may be used to fund multiple 260 services, some of which may use the extensions defined in this 261 documents, and some may use other mechanisms. While the interworking 262 of the mechanisms described in this document with other mechanisms 263 should be possible and straightforward, the specification of how this 264 could be done depends on the external mechanisms and is, as such, 265 outside the scope of this document. 267 1.2.1. Architectural Model 269 The protocol extensions described in this draft assumes that the 270 following entities are present in the network architecture. 272 o Service Access Device (SAD): This entity provides a data service 273 to the users, and typically coincides with the NAS. The SAD 274 executes the RADIUS client which, for the purposes of this 275 document, is termed the "PrePaid Client" (PPC). When the prepaid 276 service is used the SAD collects service event information and 277 reports it while or after services are provided to the user. This 278 event information is sent to the PPS using the extensions defined 279 in this document. 281 o The PPS: The RADUIS server that supports the prepaid extensions 282 defined in this document. If real-time credit control is 283 required, the PPC (SAD) contacts the PPS with service event 284 information included before the service is provided. The PPS 285 performs a credit check and allocates a portion of available 286 credit to the service event. 288 o The rating entity: This entity converts the credit that is 289 allocated by the PPS into a time or volume amount, called the 290 "quota". This quota is then returned to the requesting PPC (SAD) 291 (via the PPS). The rating entity may also determine that during 292 service provision a tariff switch will occur. In this case the 293 rating entity will include details of when exactly tariff switch 294 will occur. 296 The requesting SAD (PPC) monitors the provision of the service 297 according to the instructions returned by the PPS. After service 298 completion or on a subsequent request for service, the PPS deducts 299 the corresponding amount of credit from the user account. When a 300 user terminates an on-going service, the PPC informs the PPS with a 301 suitable indication about the unused portion of the allocated quota. 302 The PPS is then able to refund the user account appropriately. 304 Multiple PPSs may be deployed for reasons of redundancy and load 305 balancing. The system MAY also employ multiple rating servers. 306 Prepaid accounts may be located in a centralized database. The 307 detailed architecture of the system and its interfaces are outside 308 the scope of this specification. 310 accounting 311 +------------+ +-----------+ protocol +--------------+ 312 | User |<---------->| Service | | | 313 | | IEEE 802.1x| Access |<------------>| Accounting | 314 | Device | PANA | Device |<-----+ | Server | 315 +------------+ IKEv.2 +-----------+ | +--------------+ 316 ... etc (PPC) | 317 | 318 | +--------------+ 319 +------>| Prepaid | 320 prepaid | Server | 321 protocol +--------------+ 323 Figure 1: Basic prepaid architecture 325 The PPS and the accounting server in this architecture are logical 326 entities. The real configuration MAY combine them into a single 327 host. 329 The SAD must have the ability to meter the usage for a prepaid data 330 session. This usage includes time or volume (e.g. number of bytes). 332 The device running the PPC may also have "Dynamic Session 333 Capabilities" such as the ability to terminate a data session or 334 change the filters associated with a specific data session by 335 processing "Disconnect" messages and "Change of Authorization" 336 messages as per RFC 3576. 338 This document assumes that the PPS is used as the AAA server. There 339 are three types of AAA server, as follows. 341 o The AAA server in the home network (HAAA), which is responsible 342 for authentication of the subscriber. In addition, the HAAA 343 communicates with the PPS using the RADIUS protocol in order to 344 authorize subscribers. 346 o The AAA server in the visited network (VAAA) which exists only in 347 roaming scenarios and is responsible for forwarding the RADIUS 348 messages to the HAAA. The VAAA may also modify the messages. 349 Note that, in certain roaming deployments, the visited network may 350 be connected to the home network via one or more broker networks. 352 o The AAA server in one of the aforementioned broker networks 353 (BAAA), which is responsible for forwarding messages and does not 354 play an active role in the prepaid data service delivery. A BAAA 355 obviously exists only in those roaming deployments where the VAAA 356 and the HAAA are connected via the BAAA of a broker network. 358 This document assumes that the PPS communicates with the HAAA for the 359 purposes of authorisation. Additionally, the PPS interfaces to 360 entities which 362 o keep the subscriber's account balance (balance manager), 364 o rate access service requests in real-time (Rating Engine), and 366 o manage quota for a particular prepaid service (Quota Server). 368 Three deployment scenarios are presented in the remainder of this 369 section. The first scenario is depicted in Figure 2. In this 370 scenario, the SAD, which runs the PPC, the HAAA, and the PPS are 371 located in the same provider network. 373 The subscriber's device establishes a connection with one of possibly 374 multiple SADs in the network. The selected SAD communicates with a 375 HAAA server (directly or indirectly). 377 The interface between the HAAA and the PPS is implemented using the 378 RADIUS protocol together with the extensions described in this 379 document. However, in cases where the PPS does not implement the 380 RADIUS protocol, the implementation would have to map the 381 requirements defined in this document to a functionally equivalent 382 protocol. 384 +------+ +-----+ 385 | | | | 386 +--------+ +--------+ +--| HAAA |--+--| PPS | 387 | | | | | | | | | | 388 | Subscr.| | Service| | +------+ | +-----+ 389 | |---| Access |--+ | 390 | Device | | Device | | +------+ | +-----+ 391 | | | | | | | | | | 392 +--------+ +--------+ +--| HAAA |--+--| PPS | 393 | | | | 394 +------+ +-----+ 396 Figure 2: Basic prepaid access architecture 398 The second scenario, depicted in Figure 3, is based on a static 399 roaming architecture that is typical of a wholesale scenario for 400 Dial-Up users or a broker scenario used in Dial-Up or WLAN roaming 401 scenarios. 403 +----+ +----+ +----+ +-----+ 404 | | | | | | | | 405 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 406 | | | | | | | | | | | | | | | | 407 |Sub | |Service| | +----+ | +----+ | +----+ | +-----+ 408 | |--|Access |-+ | | | 409 |Device| |Device | | +----+ | +----+ | +----+ | +-----+ 410 | | | | | | | | | | | | | | | | 411 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 412 | | | | | | | | 413 +----+ +----+ +----+ +-----+ 415 Figure 3: Static roaming prepaid architecture 417 Like in the basic prepaid architecture, the subscriber device 418 establishes a connection with the SAD. The SAD communicates with the 419 VAAA using the RADIUS protocol. The VAAA, in turn, communicates 420 using the RADIUS protocol with BAAA servers in the broker network. 421 There may be more than one Broker Network between the Visited Network 422 and the Home Network. The Home Network is the same as in the 423 architecture depicted in Figure 2. 425 Broker AAA (BAAA) servers MUST support the Message-Authenticator(80) 426 attribute as defined in RFC 2869. If they are used, they forward the 427 RADIUS packets as usual to the appropriate RADIUS servers. 429 Accounting messages are not needed to deliver a prepaid service. 431 However, accounting messages can be used to keep the PPS up to date 432 as to what is happening with the prepaid data session. Therefore, a 433 BAAA SHOULD deliver RADIUS Accounting messages using the pass through 434 mode described in RFC 2866. 436 1.2.2. Motivation 438 Why not use existing RADIUS attributes to construct a protocol for 439 prepaid scenarios? This could lead to a solution where no code has 440 to be modified at existing devices. 442 It is indeed possible to construct a solution for prepaid billing 443 scenarios using existing RADIUS attributes. The RADIUS server would 444 send an Access-Accept message containing a Session-Timeout(27) and 445 include a Termination-Action(29) in the RADIUS-request. Upon 446 receiving the Access-Accept message, the NAS would meter the duration 447 of the session and upon termination of the session the NAS would 448 generate an Access-Request message again. The RADIUS server would 449 then re-authenticate the session and reply with an Access-Accept 450 message indicating the amount of additional time in a Session- 451 Timeout(27). Alternatively, it could respond with an Access-Reject 452 message if there were no more resources in the user account. 454 Moreover, if the user terminates the session prematurely, the NAS 455 could indicate this in the accounting stream so that unused funds can 456 be returned into the prepaid user account. 458 Unfortunately, the above "solution" has a number of problems, 459 including the following. 461 o It only supports time-based accounting. The solution presented in 462 this document supports both time and volume based prepaid. 464 o Using accounting messages to recoup unused time may be problematic 465 because RADIUS accounting messages are not delivered in real-time. 466 A RADIUS server may store-and-forward accounting messages in 467 batches. Thus, relying on accounting messages for the purposes of 468 prepaid may cause revenue leakage. The solution presented in this 469 document does not rely on Accounting packets at all. It uses 470 Access-Request messages, which are required to flow through any 471 network in real-time. 473 o Session-Timeout(27) is not a mandatory attribute. If a prepaid 474 subscriber is being serviced by a NAS that does not adhere to 475 Session-Timeout then that subscriber may use the service for an 476 undetermined period of time. 478 o Termination-Action(29) presents its own issues. Firstly the 479 behaviour of Termination-Action(29) is not mandatory. Secondly, 480 according to RFC 2865, Termination-Action fires when the provision 481 of the service has completed. However, service should not be 482 terminated when negotiating additional quota, because this should 483 happen in a manner transparent to the subscriber. Due to the fact 484 that Termination-Action occurs when the service is completed, it 485 is unclear whether or not user experience would be affected if 486 this attribute would be used in a prepaid scenario. The RADIUS 487 server might even allocate a new IP address to the subscriber 488 device after a Termination-Action. Also, the RADIUS server has no 489 way of telling why a given Access-Request message was generated. 490 The RADIUS server might have to wait for the corresponding 491 accounting packet to determine the reason. Finally, re- 492 authenticating the subscriber may take too long. The solution 493 presented in this document allows quota replenishing to occur 494 without affecting user experience. No re-authentication is 495 required and quotas can be negotiated before the available credit 496 actually runs out. 498 o Due to the fact that the standard RADIUS attributes are not 499 mandatory, the correct prepaid operation is really an act of faith 500 on the part of the RADIUS server. If Session-Timeout(27) and/or 501 Termination-Action(29) are not supported, the prepaid subscriber 502 might be able to obtain the service for free. The solution 503 described in this document requires that a prepaid-aware SAD 504 informs the RADIUS server, regardless of whether or not the latter 505 supports the prepaid extensions. The RADIUS server can then 506 determine whether or not service should be granted. For example, 507 if a prepaid subscriber is connected to a NAS that does not 508 support prepaid, the RADIUS server can either instruct the NAS to 509 tunnel the traffic to another entity in the home network (e.g. the 510 Home Agent) that supports prepaid, or it provide only a restricted 511 service. 513 The solution presented in this document requires the support of two 514 mandatory and one optional attribute. Furthermore, it does not 515 require a great amount of additional code at a NAS that already 516 supports time or volume metering. The solution requires that RADIUS 517 entities advertise their prepaid capabilities in an Access-Request 518 and that they generate an Access-Request Authorize-Only packet to 519 obtain more quota when or before the current quota is used up. It 520 also requires the NAS to send an Access-Request with Authorize-Only 521 when the session terminates in order to refund the subscriber 522 account. 524 1.3. A simple use case 526 This section describes the sequence of events in a simple RADIUS 527 prepaid transaction. 529 1. When an end host attaches to a network (for example, using PPP or 530 PANA), as usual, the NAS (SAD) that is servicing the subscriber 531 uses the AAA infrastructure to authenticate and authorize the 532 subscriber (if such network accesss authentication is required). 534 2. The SAD sends a RADIUS Access-Request to the AAA server in order 535 to authenticate and authorise the subscriber with respect to the 536 requested service. The Access-Request contains the subscriber's 537 credentials and may contain the prepaid capabilities of the SAD. 538 Prepaid capabilities MUST be included if the SAD supports them. 540 3. The authentication procedure proceeds. This may involve several 541 message exchanges such as in EAP [RFC2284]. Once the subscriber 542 has been successfully authenticated, the home AAA server 543 determines that the subscriber is a prepaid subscriber and 544 requests authorisation from the PPS. The request MUST include 545 the prepaid capabilities of the serving SAD. 547 4. The PPS validates that the subscriber has a prepaid account and 548 that the account is active. It further validates that the SAD 549 has the appropriate prepaid capabilities. If all is in order, 550 the PPS authorises the subscriber to use the network. Otherwise 551 it rejects the request. The decision is sent to the AAA system. 552 The response includes attributes to indicate the allocation of a 553 portion of the subscriber credit. This portion is called the 554 "initial quota" (in units of time or volume) and optionally a 555 threshold value. Note that only a portion of the user's funds is 556 allocated because the user may be engaged in other services that 557 may draw on the same account. For example, the user may be 558 engaged in a data session and a voice session. Although these 559 two services would draw from the same account, they form separate 560 parts of the overall system. If the entire quota was allocated 561 to the data session then the user would have no more funds for a 562 voice session. 564 5. The AAA system incorporates the attributes received from the PPS 565 into an Access-Accept message that it sends to the SAD. Note 566 that the AAA system is responsible for authorizing the service 567 whereas the prepaid system is responsible for prepaid 568 authorization. 570 6. Upon receiving the Access-Response, the SAD starts the prepaid 571 data session and meters the session based on time or volume, as 572 indicated in the message. 574 7. Once the usage for the session approaches the allocated limit (as 575 expressed by the threshold), the SAD will request additional 576 quota. Re-authorization for additional quota flows through the 577 AAA system to the PPS. The PPS revalidates the subscriber 578 account and subtracts the previously allocated quota from the 579 current balance. If there is remaining balance, it reauthorizes 580 the request with an additional quota allotment. Otherwise, the 581 PPS rejects the request. Note that the replenishment of the 582 quota is a re-authorization procedure and does not require the 583 subscriber to authenticate himself again. 585 8. Upon receiving a re-allotment of the quota, the SAD continues to 586 provide the data service until the new threshold is reached. If 587 the request for additional quota cannot be fulfilled then the SAD 588 lets the subscriber use the remaining quota and terminates the 589 session. Alternatively, instead of terminating the session, the 590 SAD may restrict the data session such that the subscriber can 591 only reach a particular web server. This web server maybe used 592 to allow the subscriber to replenish his account. This 593 restriction can also be used to allow new subscribers to set up 594 prepaid accounts in the first place. 596 9. Should the subscriber terminate the session before the quota is 597 exhausted, the remaining balance allotted to the session MUST be 598 refunded into his account. 600 Note that the subscriber may have disconnected while the Access 601 Device is waiting for the initial quota. The entire allocated quota 602 will be credited back to the subscribers account in this case. Also 603 note that the PPS maintains session state for the subscriber. This 604 state includes how much account balance was allocated during the last 605 quota enquiry and how much is left in the account. Therefore, it is 606 required that all messages about the session reach the same (and 607 correct) PPS. 609 For a simple message flow, along the lines of this use case, please 610 see Appendix A. 612 2. Supported Features 614 This section describes the features that are supported by the prepaid 615 extensions defined in this draft. 617 2.1. Multiple Concurrent Services 619 Examples of services that the user may be using are browsing the web, 620 participating in a VoIP conversation, watching streaming video and 621 downloading a file. Some operators may want to distinguish between 622 these services. Some services are chaged at different rates and 623 services may be metered differently. Therefore, the prepaid solution 624 needs to be able to distinguish services, and allocate quota to the 625 services using different unit types (time, volume) and allow for 626 those quotas to be consumed at different rates. 628 +---------+ 629 | Session | 630 +---------+ 631 | 1 632 V N 633 +--------------+ 1 : 1 +-------+ 634 | Service |------>| Quota | 635 | (service-Id) | +-------+ 636 +--------------+ 638 Figure 4: Multiple services within a single session 640 As shown in Figure 4, a session may be associated with multiple (N) 641 services. Each service is identified by a service identifier 642 (Service-ID). The format of the Service-ID is not in the scope of 643 this document but it could be expressed as an IP flow using the 644 5-tuple {Source-IP and Port, Destination-IP and Port, protocol type}. 645 Each service is associated with a quota metric. An example message 646 flow that involves multiple such services within a single session is 647 given in the appendix. 649 2.2. Resource Pools 651 When working with multiple services a new problem arises because one 652 service may consume its quota faster than another service. When the 653 user balance is close to exhaustion, a situation could arise where 654 one service is unable to obtain quota while another service has 655 plenty of quota remaining. Unless the quotas can be rebalanced, the 656 SAD would then have to terminate the former service. Moreover, if 657 each service generates a certain amount of RADIUS prepaid traffic. 658 In an environment with many users and chargarble services, this 659 amount of traffic is considerable and could leads inefficiency. 661 One method to circumvent the above situation is to use a so-called 662 "resource pool". Resource pools enable the allocation of resources 663 to multiple services of a session by allocating resources to a pool 664 and have services draw their quota from the pool at a rate 665 appropriate to that service. When the quota that has been allocated 666 to the pool is close to exhaustion, the entire pool (rather than 667 individual services) is replenished. 669 +-----------+ 670 | Service-A |-----+ +--------+ 671 +-----------+ | Ma | | 672 +-------->| | 673 | Pool | 674 +-------->| (1) | 675 +-----------+ | Mb | | 676 | Service-B |-----+ +--------+ 677 +-----------+ 679 Figure 5: Resource pool example 681 As shown in Figure 5, Service-A and Service-B are bound to Pool(1). 682 Ma and Mb are the pool multipliers (that are associated with 683 Service-A and Service-B respectively) that determine the rate at 684 which Service-A and Service-B draw from the pool. 686 The pool is initialized by taking the quota allocated to service n 687 and multiplying it by Mn. Therefore, the amount of resources 688 allocated to a pool is given by Poolr = Ma*Qa + Mb*Qb + . . ., where 689 Qn denotes the amount of quota that is allocated to service n. 690 Further, the pool is considered to be empty if 692 Poolr <= Ca*Ma + Cb*Mb + . . ., 694 Figure 6 696 where Ca and Cb are resources consumed by Service-A and Service-B 697 respectively. 699 Note that the resources assigned to the pool are not associated with 700 a metric. That is, Service-A can be rated at $1 per MB and Service-B 701 can rated at $0.10 per minute. In this case if $5 worth of resources 702 are allocated for service-A to the pool and if Ma = 10, then 50 units 703 would be placed into the pool. If a further $5 are allocated for 704 service-B to the pool, then M=1 and 50 units are deposited into the 705 pool. The pool would then have a total sum of 100 units to be shared 706 between the two services. The PPC would then mater the services such 707 that each Mbyte used by Service-A will draw 10 units from the pool 708 and each minute used by Service-B will draw 1 unit from the pool. 710 2.3. Complex Rating Functions 712 The rating of a service can be quite complex. While some operators 713 follow linear pricing models, others may wish to apply more complex 714 functions. For example, a service provider may wish to rate a 715 service such that the first N MBytes are free, then the next M Mbytes 716 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 717 per MB. Such a function could be implemented by repeated message 718 exchanges with the prepaid system. 720 To avert the need to exchange many messages while still supporting 721 such complex rating functions, the notion of a "Rating Group" is 722 introduced. A Rating Group are typically configured at the SAD. As 723 shown in Figure 7, a Rating Group is associated with one or more 724 services and defines the rate that the services associated with the 725 Rating Group consume an allocated amount of quota. 727 +--------------+ +--------------+ 728 +-----------+ N 1 | | M 1 | Resource Pool| 729 | Service-A +---------->| Rating Group |------>| or | 730 +-----------+ | | | Quota | 731 +--------------+ +--------------+ 733 Figure 7: Example of a rating group 735 During the usage of a service that is associated with a Rating Group, 736 the PPC sends the ID of the Rating Group to the PPS. The PPS 737 authorises the Rating Group by allocating a quota to it and 738 optionally assigning it to a Resource Pool. When an additional 739 service that belongs to an already authorised Rating Group is 740 instantiated, the PPC does not need to authorize this service. This 741 effectively means that the PPC meters the service such that it draws 742 from the already allocated quota. Therefore, no RADIUS messages need 743 to be exchanged in this case. This limits the amount of traffic 744 between the PPC and the PPS. An example of a flow that uses Rating 745 Groups is given in Appendix A.3 747 2.4. One-time Charging 749 One-time charging is a mode of operation of where the RADIUS prepaid 750 extensions are used for charging of a service that is provided 751 instansteneously, i.e. without an ongoing session. An example of 752 such an event is the purchase of a ring-tone. Subscription based 753 services can also be modeled as a one-time event. In this case the 754 one-time service event is the purchase of a subscription. 756 For a given user, one-time-based charging may occur in parallel with 757 other charging models. For example, the subscriber may access a 758 website which is metered (based on time or volume) while he also 759 purchases the right to use a ring tone (a one-time-based event). 760 Note: it is up to the service providers to decide whether or not the 761 user will be charged for the download of the tone and also be charged 762 for the time and volume required to download the ring-tone. The 763 facilities provided by this document gives the service provider the 764 capability to achieve their service charging business goals. For 765 example, should the service provider choose not to charge for the 766 download volume or time, then they can treat the download IP flow as 767 a separate service that is not subject to charging. 769 The SAD signals one-time-based charging to the PPS with an indication 770 that identifies the service and the units that should be debited from 771 the user account. 773 A SAD may decide to perform one-time-based charging for an event that 774 was triggered by an unauthenticated user. In this case case the SAD 775 will have to authenticate the user before sending the relevant 776 message to the user's home AAA server. 778 Note that one-time-based charging can also be used to credit the 779 prepaid account. For example, the SAD can return resources to the 780 subscriber by issuing a one-time charge request that includes the 781 amount of resources to be credited into the account. 783 2.5. Tariff Switching 785 The PPC and the PPS may support tariff switching. For example, as 786 shown in Figure 8, traffic before 18:00 may be rated at rate r1 and 787 traffic after 18:00 is rated at rate r2. The PPC reports usage 788 before and after the switch occurs. Tariff switching does not make 789 sense for services that are metered based on time, and the 790 consumption of which is continuous (i.e. without interruption). 792 18:00 793 ------------------+----------------- 794 r1 | r2 795 ------------------+----------------- 796 ^ ^ 797 |<----TSI---> | 798 | | 799 Access-Accept Access-Request 800 (quota allocated) (quota consumed) 802 Figure 8: Example of tariff switching 804 The PPC it indicates support for tariff switching by setting the 805 appropriate bit in the PPAC. If the PPS needs to signal a tariff 806 switch time it will send a PTS attribute which indicates the point in 807 time when the switch will occur. This indication represents the 808 number of seconds from current time (TarrifSwitchInterval TSI). 810 At some point after the tariff switch the PPC sends another Access- 811 Request, as a result of either the user having logged off or the 812 volume threshold being reached. The PPC reports how much volume was 813 used using the PPAQ in total and how much volume was used after the 814 tariff switch using the PTS VUATS subtype. 816 In situations with multiple tariff switches, the PPS must specify the 817 length of the tariff switch period using the 818 TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute as 819 shown below. 821 18:00 23:30 822 ------------------+---------------------+-------------- 823 r1 | r2 | r3 824 ------------------+---------------------+-------------- 825 ^ ^ ^ 826 |<----TSI---><-----------|-------->|TITSU 827 | | 828 Access-Accept Access-Request 830 Figure 9: Multiple tariff switches 832 When a TITSU is specified in the PTS, the PPC MUST generate an 833 Access-Request within the time after TSI and before TITSU expires. 834 Note that, typically, the PPC will be triggered by the Volume 835 Threshold. However, it is possible that, during period r2, resources 836 are not entirely consumed and, thus, the threshold is not reached. 837 Even in this case PPC MUST generate an Access-Request in good time. 838 Also note that separate services flows may have individual tariff 839 periods. 841 2.6. Support for Roaming 843 In certain networks it is essential for prepaid data services to be 844 available to roaming subscribers. Support for both static and 845 dynamic roaming models is needed. In a static roaming scenario the 846 subscriber connects to a foreign network which has a roaming 847 agreement either directly with the home network, or through a broker 848 network. When the subscriber logs into another foreign network, a 849 new login procedure has to be executed. 851 In a dynamic roaming scenario the subscriber may move between 852 networks while maintaining his connection. In such a scenario the 853 data session is seamlessly handed off between the networks. 855 In both roaming scenarios, the subscriber always authenticates 856 himself to the home network. Authorization for the prepaid session 857 and quota replenishing occurs at the home network and more 858 specifically at the PPS where state is being maintained. 860 Dynamic roaming is challenging because a subscriber who established a 861 prepaid data session may move to another Access Device that does not 862 support the prepaid extensions. Even in this case the system should 863 be able to continue the prepaid session. 865 2.7. Dynamic Termination 867 When fraud or an error is detected, either only the affected session, 868 or all sessions of the affected subscriber should be immediately 869 terminated. It may further happen that the prepaid system enters a 870 state where it is unclear whether or not the data session is in 871 progress. Under certain conditions, the system may wish to terminate 872 the session in order to make sure that the user is not charged for 873 this potential inactivity. 875 Certain handoff procedures used in dynamic roaming scenarios require 876 that the system terminates the subscribers prepaid data session at a 877 SAD. This is the case, for example, when time-based prepaid is used 878 and the mobile subscriber performs a dormant handoff. 880 2.8. Querying and Rebalancing 882 It should be possible for the PPS to Query the current resource 883 consumption at a SAD and adjust the user account balance. For 884 example, a request to the PPS is made (e.g. a one-time charging 885 event), the account is depleted and resources have been allocated to 886 the SAD. The PPS should have the ability to query the SAD and if it 887 has the spare resources to reassign the quotas to the SAD and to the 888 pending request. Note that the PPS does not know resource usage 889 until the SAD request for more resources. This can be a long time. 891 In the absence of this capability the PPS can minimize the effect of 892 this phenomenon by allocating small quotas, a practice that results 893 in more message exchanges. 895 3. Operations 897 This section describes the operations that are implemented by a 898 prepaid-enabled NAS (SAD). 900 3.1. Authentication and Authorization Operation 902 The SAD initiates the authentication and authorization procedure by 903 sending a RADIUS Access-Request to the HAAA. Since the SAD has PPC 904 capabilities, it MUST include a PPAC attribute in the RADIUS Access- 905 Request. The PPAC attribute indicates to the PPS which prepaid 906 capabilities are possessed by the SAD. These are required in order 907 to complete the prepaid authorization procedure. Moreover, if the 908 SAD supports the Disconnect-Message or the Change-of-Authorization 909 capabilities, then it SHOULD include the Dynamic-Capabilities 910 attribute. 912 In certain deployments, there may be other ways to terminate a data 913 session, or change authorization of an active session. For example, 914 some SADs provide a session termination service via Telnet or SNMP. 915 In these cases, the AAA server MAY add the Dynamic-Capabilities 916 message to the Access-Request. Upon receiving the Change-of- 917 Authorization message, the AAA server would then be responsible for 918 terminating the session using the means that are supported by the 919 device. 921 If the authentication procedure involves multiple message exchanges 922 (as in EAP), the SAD MUST include the PPAC(TBD) attribute and the 923 Dynamic-Capabilities attribute (if used) in at least the last Access- 924 Request of the authentication procedure. 926 The Access-Request is sent as usual to the HAAA, possibly through one 927 or more BAAA. 929 Once the Access-Request arrives at the HAAA, the HAAA authenticates 930 the subscriber. If this fails, the HAAA sends an Access-Reject 931 message to the client. If authentication succeeds, the HAAA 932 determines whether or not the subscriber is a prepaid subscriber. 933 (How this is done is beyond the scope of this document.) If the 934 subscriber is not a prepaid subscriber, then the HAAA responds as 935 usual with an Access-Accept or an Access-Reject message. If the 936 subscriber is a prepaid subscriber then the HAAA SHALL forward the 937 Access-Request to the PPS for further authorization. 939 The Access-Request contains the PPAC(TBD) attribute and the Dynamic- 940 Capabilities attribute if one was included. The User-Name(1) 941 attribute MAY be set to a value that identifies the subscriber. This 942 attribute is used by the PPS to locate his account. For added 943 security, the HAAA MAY also set the User-Password(2) attribute to the 944 password used between the HAAA and the PPS. 946 The PPS locates the subscriber account and authorizes him. During 947 this procedure, the PPS takes into consideration the SAD PPC 948 Capabilities. Upon successful authorization, the PPS generates an 949 Access-Accept containing an PPAC attribute and an PPAQ attribute. 950 The PPAC attribute returned to the client indicates the type of 951 prepaid service to be provided for the session. The PPAQ attribute 952 includes the following information. 954 o The QUOTA-ID, which is set by the PPS to a unique value that is 955 used to correlate subsequent quota requests. 957 o Volume and/or Time quota, which is set to a value representing a 958 portion of the subscriber's credit. 960 o It MAY contain a Time or Volume Threshold that indicates when the 961 SAD should request additional quota. 963 o The IP address of the Serving PPS and one or more alternative 964 PPSs. This is used by the HAAA to route subsequent quota 965 replenishing messages to the appropriate PPS(s). 967 Note: The Idle-Timeout(28) attribute can be used to trigger the 968 premature termination of a prepaid service, for example as a result 969 of inactivity. 971 Depending on site policies, after failed authorization, the PPS may 972 generate an Access-Reject in order to terminate the session 973 immediately. Alternatively, the PPS may generate an Access-Accept 974 blocking some or all of the traffic and/or redirect some or all of 975 the traffic to a location to a fixed server. (This feature could be 976 used, for example, to prompt the user to replenish their account.) 977 Blocking of traffic is achieved by either Filter-ID(11) or NAS- 978 Filter-Rule(see Redirect I-d). Redirection is achieved by sending 979 Redirect-Id or Redirect-Rule, HTTP Redirection defined in the 980 Redirect I-d. The time period before the session is blocked/ 981 redirected is specified by the Session-Timeout(27) attribute. 983 Upon receiving an Access-Accept from the PPS, the HAAA appends the 984 usual service attributes and forward the packet to the SAD. The HAAA 985 SHOULD NOT overwrite any attributes already set by the PPS. If the 986 HAAA receives an Access-Reject message, it will simply forward the 987 packet to its client. Depending on site policies, if the HAAA does 988 not receive an Access-Accept or an Access-Reject message from the PPS 989 it MAY do nothing or send an Access-Reject or an Access- Accept 990 message back to the PPC. 992 3.2. Session Start Operation 994 The start of the session is indicated by the arrival of an 995 Accounting-Request(Start) packet. The Accounting-Request (Start) MAY 996 be routed to the PPS such that it can confirm the initial quota 997 allocation. 999 Note that the role of the PPS is not to record accounting messages 1000 and therefore it SHOULD NOT respond with an Accounting Response 1001 packet. If the PPS does not receive the Accounting-Request(start) 1002 message it will only know that the session has started upon the first 1003 reception of a quota replenishment operation. 1005 If the PPS does not receive indication directly (via Accounting- 1006 Request(start)) or indirectly, it SHOULD, after some configurable 1007 time, deduce that the Session has not started. If the SAD supports 1008 termination capabilities, the PPS SHOULD send a Disconnect Message to 1009 the SAD as a measure to ensure that the session is indeed dead. 1011 3.3. Mid-Session Operation 1013 During the lifetime of a prepaid data session the SAD may request the 1014 replenishment of the quotas using Authorize-Only Access-Request 1015 message. Once either the allocated quota has been exhausted or the 1016 threshold has been reached, the SAD MUST send an Access-Request with 1017 Servicetype(6) set to a value of "Authorize Only" and the PPAQ(TBD) 1018 attribute. 1020 The SAD MUST also include NAS identifiers, and Session identifier 1021 attributes in the Authorize Only Access-Request. The Session 1022 Identifier should be the same as the one used during the initial 1023 Access-Request. For example, if the User-Name(1) attribute was used 1024 in the Access-Request it MUST be included in the Authorize Only 1025 Access-Request, especially if the User-Name(1) attribute is used to 1026 route the Access-Request to the Home AAA server. 1028 The Authorize Only Access-Request MUST NOT include a User Password 1029 and MUST NOT include a Chap Password. In order to enable the 1030 receiver to authenticate the message, the SAD MUST include a Message- 1031 Authenticator(80) attribute. The SAD computes the value for the 1032 Message-Authenticator according to RFC 2869. 1034 When the HAAA receives an Authorize-Only Access-Request that contains 1035 a PPAQ(TBD), it SHALL validate the message using the Message- 1036 Authenticator(80), according to RFC 2869. If the HAAA receives an 1037 Authorize Only Access-Request that contains a PPAQ(TBD) and either no 1038 or an invalid Message-Authenticator(80) it SHALL silently discard the 1039 message. An Authorize Only Access-Request message that does not 1040 contain a PPAQ(TBD) is either erroneous or belongs to another 1041 application (for example, a Change of Authorization message 1042 [RFC3576]). In this case the Authorize Only Access-Request is either 1043 silently discarded or handled by another application. 1045 Once the Authorize Only Access-Request message is validated, the HAAA 1046 SHALL forward the Authorize Only Access-Request to the appropriate 1047 PPS. The HAAA MUST forward the Authorize Only Access-Request to the 1048 PPS specified in the PPAQ(TBD). The HAAA MUST add a Message- 1049 Authenticator(80) to the message, according to RFC 2869. As with the 1050 Access-Request message, the HAAA MAY modify the User-Name(1) 1051 attribute such that it identifies the user to the PPS. Note that the 1052 PPS may also use the Quota-ID sub-attribute contained within the 1053 PPAQ(TBD) to locate the user account. 1055 Upon receiving the Authorize Only Access-Request containing a 1056 PPAQ(TBD) attribute, the PPS MUST validate the Message- 1057 Authenticator(80) as described in RFC 2869. If validation fails, the 1058 PPS MUST silently discard the message. If it receives an Authorize 1059 Only Access-Request message that does not contain a PPAQ(TBD), it 1060 MUST silently discard the message. 1062 The PPS locates the prepaid session state using the Quota Id 1063 contained within the PPAQ(TBD). The PPS takes the most recently 1064 allocated quota and subtracts it from the user balance. If 1065 sufficient balance remains, the PPS authorizes the PPS and allocates 1066 additional quota. The PPS may also calculate a new threshold value. 1067 Upon successful re-authorization, the PPS generates an Access-Accept 1068 containing the PPAQ(TBD) attribute. The Access-Accept message MAY 1069 contain Servicetype(6) set to Authorize-Only and MAY contain the 1070 Message-Authenticator(80). 1072 Depending on site policies, upon unsuccessful authorization, the PPS 1073 generates an Access-Reject or an Access-Accept with Filter-Id(11) or 1074 Ascend-Data-Filter (if supported) attribute and the Session- 1075 Timeout(27) attribute such that the subscriber can get access to a 1076 restricted set of locations for a short period of time. This feature 1077 could be used to enable users to replenish their accounts, create new 1078 accounts, or to browse free content. 1080 Upon receiving the Access-Accept from the PPS, the HAAA SHALL return 1081 the packet to its client. If the HAAA receives an Access-Reject 1082 message, it forwards the packet. Depending on site policies, if the 1083 HAAA does not receive an Access-Accept or an Access-Reject message 1084 from the PPS it MAY do nothing or it MAY send an Access-Reject 1085 message back to its client. 1087 Upon receiving an Access-Accept, the SAD SHALL update its quotas and 1088 threshold parameters with the values contained in the PPAQ(TBD) 1089 attribute. Note that the PPS MAY update the PrePaidServer 1090 attribute(s) and these may have to be saved as well. If the Access- 1091 Accept message contains a Filter-Id(11), an Ascend-Data-Filter 1092 attribute, or Session Timeout(27), the SAD SHALL restrict the 1093 subscriber session accordingly. 1095 3.4. Dynamic Operations 1097 The PPS may take advantage of the dynamic capabilities that are 1098 supported by the SAD as advertised in the Dynamic-Capabilities 1099 attribute during the initial Access-Request. There are two types of 1100 action that the PPS may perform. Firstly, it may request the session 1101 to be terminated. Secondly, it may request the attributes associated 1102 with the session to be modified. More specifically, it may modify a 1103 previously sent PPAQ(TBD). 1105 Both of these actions require that the session be uniquely identified 1106 at the SAD. As a minimum, the PPS MUST provide 1108 1. either the NAS-IP-Address(4) or the NAS-Identifier(32), and 1110 2. at least one session identifier such as User-Name(1), Framed-IP- 1111 Address(), the Accounting-Session-Id(44). 1113 Other attributes could also be used to uniquely identify a prepaid 1114 data session. 1116 3.4.1. Unsolicited Session Termination Operation 1118 At anytime during a session the PPS may send a Disconnect Message in 1119 order to terminate a session. This capability is described in detail 1120 in [RFC3576]. The PPS sends a Disconnect Message that MUST contain 1121 identifiers that uniquely identify the data session and the SAD 1122 servicing that session. 1124 If the SAD receives a Disconnect-Message, it responds with either a 1125 Disconnect-ACK message (if it is able to terminate the session) or 1126 with a Disconnect-NAK packet (otherwise). Upon successful 1127 termination of a session the SAD MUST return any unused quota to the 1128 PPS by issuing an Authorize Only Access-Request containing the PPAQ 1129 which contains any unused Quota and the Update-Reason set to "Remote 1130 Forced Disconnection". 1132 3.4.2. Unsolicited Change of Authorization Operation 1134 At any time during the session the PPC may receive a Change of 1135 Authorization (CoA) message. A PPS may send a new Quota to either 1136 add or to remove quota that is allocated to the service. If the 1137 Change of Authorization contains a PPAQ then that PPAQ overrides a 1138 previously received PPAQ. The PPS MUST NOT change the units used in 1139 the PPAQ. 1141 If the newly received PPAQ reduces the amount of allocated quota 1142 beyond what is already used then the SAD accepts the new PPAQ and act 1143 as it normally would when the quota is used up. For example, if the 1144 threshold is reached then is request a quota update . 1146 3.5. Termination Operation 1148 The termination phase is initiated when (i) the subscriber logs off, 1149 (ii) the subscriber balance is exhausted, or (iii) when the SAD 1150 receives a Disconnect Message. 1152 In case the user logged off, or the SAD receives a Disconnect 1153 Message, the SAD sends an Authorize-Only Access-Request message with 1154 a PPAQ and Update-Reason attribute set to either "Client Service 1155 Termination" or "Remote Forced Disconnect". This message indicates 1156 the amount of consumed quota. 1158 In case the currently allocated quota is exhausted, if the PPAQ 1159 contained the Termination-Action field, the SAD follows the specified 1160 action (which would be to immediately terminate the service, request 1161 more quota, or redirect/filter the service). 1163 3.6. Mobile IP Operations 1165 In roaming scenarios with Mobile-IP, the prepaid data session should 1166 be maintained transparently if the HA is acting as the SAD. As the 1167 subscriber device associates with a new SAD (AP or PDSN that supports 1168 PPC capability), the SAD sends a RADIUS Access-Request and the 1169 subscriber is re-authenticated and reauthorized. The SAD MUST 1170 include the PPAC(TBD) attribute in the RADIUS Access-Request. In 1171 this manner, the procedure follows the Authentication and 1172 Authorization procedure described earlier. 1174 If the HA was acting as the SAD before handoff, the prepaid session 1175 does not undergo any change after the handoff because the Mobile IP 1176 session is anchored at the HA and the user's Home IP address does not 1177 change. 1179 In the case of a wireless access point or PDSN acting as the SAD, it 1180 is likely that the user's (care-of) IP address will change. The 1181 prepaid session will be affected by this. In this scenario the SAD 1182 shall send an Access-Request message which is routed to the home 1183 network and MUST reach the PPS that is serving this session. The PPS 1184 correlates the new authorization request with the existing active 1185 session and assigns a quota to the new request. Any outstanding 1186 quota at the old SAD MUST be returned to the PPS if the Mobile-IP 1187 nodes (HA and FA) support registration revocation (Mobile IPv4 only). 1188 Specifically, the quota SHOULD be returned when the SAD sends the 1189 Authorize Only Access-Request with PPAQ(TBD) Update-Reason set to 1190 either "Remote Forced Disconnect" or "Client Service Termination". 1191 In order to trigger the sending of this last Authorize Only Access- 1192 Request, the PPS may issue a Disconnect Message [3576] to the SAD. 1194 Even if the subscriber moves to a SAD that does not have prepaid 1195 capabilities can the prepaid data service continue. This can be done 1196 by requesting the Home Agent (assuming it has such capabilities) to 1197 take over the responsibilities of the SAD (i.e. metering). This 1198 scenario will be discussed in detail in a later version of this 1199 document. 1201 3.7. Operation Considerations for Multiple Services 1203 This section describes the support for multiple prepaid services on a 1204 single SAD. Message flows illustrating the various interactions are 1205 presented in Appendix A. 1207 A SAD that supports prepaid operations for multi-services SHOULD set 1208 the "Multi-Services Supported" bit in the PPAC. When working with 1209 multi-services, we need to differentiate between the services. A 1210 Service-Id attribute is used in the PPAQ(TBD) in order to uniquely 1211 differentiate between the services. The exact definition of the 1212 Service-Id attribute is outside the scope of this document. 1214 A PPAQ that contains a Service-Id is associated with that Service. A 1215 PPAQ that contains a Rating-Group-Id is associated with that Rating- 1216 Group. A PPAQ MUST not contain both a Rating-Group-Id and a 1217 Service-Id. A PPAQ that contains neither a Rating-Group-Id or a 1218 Service-Id applies to the Access Service. 1220 3.7.1. Initial Quota Request 1222 When operations with multi-services is desired, the SAD requests the 1223 initial quota for the Service by sending a PPAQ containing the 1224 Service-Id for that Service in an Authorize-Only Access-Request 1225 packet. Similarly, if the SAD supports Rating-Groups then it may 1226 request a quota for the Rating-Group by sending a PPAQ containing the 1227 Rating-Group-Id. In both cases the Update-Reason is set to "Initial- 1228 Request". 1230 The Authorize-Only Access-Request message may contain more than one 1231 PPAQ. The Authorize-Only Access-Request MUST include one or more 1232 attributes that serve to identify the session so that it can be 1233 linked to the original authentication. Which Session Identifiers are 1234 included is up to specific deployments. The Authorize-Only message 1235 must contain the Message-Authenticator(80) attribute for integrity 1236 protection of the Authorize-Only Access-Request message. 1238 Upon receiving an Authorize-Only Access-Accept message containing one 1239 or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ 1240 is assigned a unique QID that MUST appear in subsequent PPAQ updates 1241 for that service or rating-group. Additionally, the PPAQ MUST 1242 contain the Service-ID or Group-ID, unless the PPAQ is the generic 1243 "Access Service". 1245 3.7.2. Quota Update 1247 Once the services start to utilize their allotted quota they will 1248 eventually need to replenish their quotas (either the threshold is 1249 reached or no more quota remains). In order to replenish the quota, 1250 the PPC sends an Authorize-Only Access-Request message containing one 1251 or more PPAQs. Each PPAQ MUST contain the appropriate QID, 1252 Service-ID or Group-ID (or neither the Service-ID or Group-Id if the 1253 quota replenishment is for the "Access Service"). The Update-Reason 1254 filed indicates either "Threshold reached"(3), or "Quota reached"(4). 1255 The Authorize-Only message must contain session identifiers. 1257 Upon receiving an Authorize-Only Access-Request packet with one or 1258 more PPAQs the PPS responds with a new PPAQ for that service. The 1259 PPAQ contains a new QID, the Service-Id or Rating-Group-Id, a new 1260 Quota. If the PPS does not grant additional quota to the service it 1261 MUST include the Termination-Action subfield in the PPAQ that will 1262 instruct the SAD what to do with the service. 1264 3.7.3. Termination 1266 When the allotted quota for a service is exhausted, the SAD shall act 1267 in accordance to the Termination-Action field set in the Quota. If 1268 the Termination-Action field is absent then the service MUST be 1269 terminated. If the service is to be terminated, then the SAD shall 1270 send a PPAQ with the appropriate QID, the Service-Id, the used quota, 1271 and the Update-Reason set to "Client Service Termination". 1273 If the �Access Service� has terminated, then all other 1274 services must be terminated as well. In this case the SAD MUST 1275 report on all issued quotas for the various services. The Update- 1276 Reason field should be set to "Access Service Terminated". 1278 3.7.4. Dynamic Operations 1280 Dynamic operations for multi-services are similar to dynamic 1281 operations described for single service operations. The prepaid 1282 system may send a COA message containing a PPAQ for an existing 1283 service instance. The SAD matches the PPAQ with the service using 1284 the Service-ID attribute. The new quota could differ from the 1285 previously allocated value. The SAD must react to the new value 1286 accordingly. 1288 A disconnect message terminates the "Access Service". As such the 1289 SAD MUST report all unused quotas by sending an Authorize Only Access 1290 Request message containing a PPAQ for each active service. The 1291 Update-Reason shall indicate that the reason for the update. 1293 3.7.5. Support for Resource Pools 1295 If the PPC supports pools as indicated by setting the "Pools 1296 supported" bit in the PPAC(TBD) then the PPS may associate a Quota 1297 with a Pool by including the Pool-Id and the Pool-Multiplier in the 1298 PPAQ(TBD). When Resource Pools are used, the PPAQ must not use the 1299 threshold field. 1301 3.7.6. One-time Charging 1303 To initiate a One-Time charge the PPC includes the PPAQ attribute in 1304 an Access-Request packet. The Access Request packet MUST include a 1305 Message-Authenticator(80) and an Event-Timestamp(55) attribute. The 1306 Service Id field of the PPAQ identifies the prepaid service. The 1307 amount to be charged is specified using the Resource Quota and 1308 Resource Quota overflow subtypes. If the value specified is negative 1309 then the resources are credited to the user account. 1311 The QID field MUST be set to a unique value and is used by the PPS to 1312 detect duplicates. The Update Reason field MUST be set to One-Time 1313 Charging. Upon receiving a One-Time charge PPAQ, the RADIUS server 1314 authenticates the user and, if successful, passes the PPAQ to the 1315 PPS. The PPS locates the account and debits or credits it 1316 accordingly. The PPS MUST respond to the PPS with an Access-Accept 1317 message if successful, or an Access-Reject message otherwise. 1319 The RADIUS server shall respond to the SAD with an Access Accept 1320 message. Since this is a one-time charge the SAD must not allow the 1321 session to continue. Therefore, the RADIUS server should include in 1322 the Access-Accept a Session-Timeout set to 0. Upon receiving an 1323 Access-Accept response the SAD shall generate an Accounting Stop 1324 message. 1326 A PPAQ used for One-Time charging may appear in an Authorize-Only 1327 Access Request. This is the case when the session already exists. 1328 The PPS responds with an Access-Accept to indicate that the user 1329 account has been debited or an Access-Reject otherwise. 1331 3.7.7. Error Handling 1333 If the PPS receives a PPAQ with an invalid QID it MUST ignore that 1334 PPAQ. 1336 If the PPS receives a PPAQ containing a Service-Id, or a Rating- 1337 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1339 If the PPC receives a PPAQ containing a Service-Id, or a Rating- 1340 Group-Id that it does not recognize, then it must ignore that PPAQ. 1342 If the PPC receives a PPAQ that contains a Pool-Id without a Pool- 1343 Multiplier or a Pool-Multiplier without a Pool-Id it must ignore that 1344 PPAQ. 1346 3.7.8. Accounting Considerations 1348 Although typically generated, accounting messages are not required to 1349 deliver a prepaid data service. When generated, accounting messages 1350 are used for auditing purposes and for billing. Accounting messages 1351 associated with prepaid data sessions should include the PPAQ(TBD) 1352 attribute. 1354 3.7.9. Interoperability with Diameter Credit Control Application 1356 The RADIUS prepaid extensions need to interoperate with the Diameter 1357 protocol. Two interoperability scenarios exist, as follows. Either 1358 the AAA infrastructure is Diameter based and the SAD are RADIUS 1359 based, or the SAD is Diameter based and the AAA infrastructure is 1360 RADIUS based. 1362 The Diameter Credit Control Application [DIAMETERCC] describes how to 1363 implement a prepaid accounting system using a Diameter based 1364 infrastructure. 1366 4. Attributes 1368 This section specifies the attributes that implement the RADIUS 1369 extensions for prepaid. The namespace for these attributes is the 1370 one specified in the RADIUS base protocol [RFC2865]. 1372 4.1. PPAC Attribute 1374 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1375 Access-Request message by a prepaid capable NAS and is used to 1376 describe the prepaid capabilities of the NAS. The PPAC is also 1377 present in an Access-Accept message by the PPS in order to indicate 1378 the type of metering that is to be applied to this session. 1380 0 1 2 3 1381 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 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | TYPE | LENGTH | SUBtype 1 | LENGTH | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | AvailableInClient (AiC) | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 TYPE : value of PPAC 1389 LENGTH: 8 1390 VALUE : String 1392 The value MUST be encoded as follows: 1394 Subtype (=1) : Subtype for AvailableInClient attribute 1395 Length : Length of AvailableInClient attribute 1396 (= 6 octets) 1397 AvailableInClient (AiC): 1399 The optional AvailableInClient Subtype, generated by the PPC, 1400 indicates the metering capabilities of the NAS and shall be bitmap 1401 encoded. The possible values are as follows. 1403 0x00000001 Volume metering supported. 1404 0x00000002 Duration metering supported. 1405 0x00000004 Resource metering supported. 1406 0x00000008 Pools supported 1407 0x00000010 Rating groups supported 1408 0x00000020 Multi-Services supported. 1409 0x00000040 Tariff Switch supported. 1411 Others Reserved 1413 Figure 10: PPAC Attribute 1415 4.2. Session Termination Attribute 1417 The value shall be bitmap encoded rather than a raw integer. This 1418 attribute shall be included RADIUS Access-Request message to the 1419 RADIUS server and indicates whether or not the NAS supports Dynamic 1420 Authorization. 1422 0 1 2 3 1423 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 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | TYPE | LENGTH | String | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 Type : value of Session Termination Capability 1429 Length: = 4 1430 String encoded as follows: 1432 0x00000001 Dynamic Authorization Extensions (rfc3576) is 1433 supported. 1435 Figure 11: Session Termination Attribute 1437 4.3. PPAQ Attribute 1439 One or more PPAQ attributes are sent in an Access Request, Authorize 1440 Only Access-Request and Access-Accept message. In an Access Request 1441 message, the PPAQ attribute is used to facilitate One-Time charging 1442 transactions. In Authorize Only Access-Request messages it is used 1443 for One-Time charging, report usage and the request for further 1444 quota. It is also used in order to request prepaid quota for a new 1445 service instance. In an Access-Accept message it is used in order to 1446 allocate the (initial and subsequent) quotas. 1448 When multiple services are supported, a PPAQ is associated with a 1449 specific service as indicated by the presence of a Service-Id, a 1450 Rating-Group-Id, or the "Access Service" (as indicated by the absence 1451 of a Service-Id and a Rating-Group-Id). 1453 The attribute has type TBD (one octet), a variable length (greater 1454 than 8, encoded into one octet), and consists of a variable number of 1455 subtypes. Unused subtypes are omitted from the message. In the 1456 following subsections the various subtypes of the PPAQ attribute are 1457 specified. 1459 4.3.1. Quota Identifier AVP 1461 The type of the QuotaIDentifier attribute is TBD and its length is 6 1462 octets. This AVP is generated by the PPS together with the 1463 allocation of new quota. The on-line quota update RADIUS Access- 1464 Request message that is sent from the SAD to the PPS shall include a 1465 previously received QuotaIdentifier. 1467 4.3.2. VolumeQuota AVP 1469 The type of the VolumeQuota attribute is TBD and its length is 12 or 1470 18 octets. This AVP is only present if volume-based charging is 1471 used. In a RADIUS Access-Accept message (PPS to SAD direction), it 1472 indicates the volume (in octets) allocated for the session by the 1473 PPS. In an RADIUS Authorize Only Access-Request message (SAD to PPS 1474 direction), it indicates the total used volume (in octets) for both 1475 inbound and outbound traffic. The attribute consists of a Value- 1476 Digits AVP and optionally an Exponent AVP (as indicated in the length 1477 field). The Exponent AVP, if present, MUST NOT encode a negative 1478 number or zero. 1480 4.3.3. VolumeThreshold AVP 1482 The type of the VolumeThreshold attribute is TBD and its length is 12 1483 or 18 octets. This AVP shall optionally be present if VolumeQuota is 1484 present in a RADIUS Access-Accept message (PPS to SAD direction). It 1485 is generated by the PPS and indicates the volume (in octets) that 1486 shall be consumed before a new quota should be requested. This 1487 threshold should not be larger than the VolumeQuota. The attribute 1488 consists of a Value-Digits AVP and optionally an Exponent AVP (as 1489 indicated by the length field). The Exponent AVP, if present, MUST 1490 NOT encode a negative number or zero. 1492 4.3.4. DurationQuota AVP 1494 The type of the DurationQuota attribute is TBD and its length is 6 1495 octets. This optional AVP is only present if duration-based charging 1496 is used. In RADIUS Access-Accept message (PPS to SAD direction), it 1497 indicates the duration (in seconds) allocated for the session by the 1498 PPS. It is encoded as an 32 bit unsigned value, in network byte 1499 order. In an on-line RADIUS Access-Accept message (PPC to PPS 1500 direction), it indicates the total duration (in seconds) since the 1501 start of the accounting session related to the QuotaID of the PPAQ 1502 AVP in which it occurs. 1504 4.3.5. DurationThreshold AVP 1506 The type of the DurationThreshold attribute is TBD and its length is 1507 6 octets. This AVP shall optionally be present if DurationQuota is 1508 present in a RADIUS Access-Accept message (PPS to PPC direction). It 1509 represents the duration (in seconds) after which new quota should be 1510 requested. This threshold should not be larger than the 1511 DurationQuota. It is encoded as a 32 bit unsigned value, in network 1512 byte order. 1514 4.3.6. ResourceQuota AVP 1516 The type of the ResourceQuota attribute is TBD and its length is 12 1517 or 18 octets. This optional AVP is only present if resource-based or 1518 one-time charging is used. In the RADIUS Access-Accept message (PPS 1519 to SAD direction) it indicates the resources allocated for the 1520 session by the PPS. In RADIUS Authorize Only Access-Request message 1521 (SAD to PPS direction), it indicates the resources used in total, 1522 including both incoming and outgoing chargeable traffic. In one-time 1523 charging scenarios, the subtype represents the number of units to 1524 charge or credit the user. The attribute consists of a Value-Digits 1525 AVP and optionally an Exponent AVP (as indicated by the length 1526 field). 1528 4.3.7. ResourceThreshold AVP 1530 The type of the ResourceThreshold AVP is TBD and its length is 12 or 1531 18 octets. The semantics of this AVP follow those of the 1532 VolumeThreshold and DurationThreshold AVPs. It consists of a Value- 1533 Digits AVP and optionally an Exponent AVP. 1535 4.3.8. Value-Digits AVP 1537 The type of the Value-Digits AVP is TBD and its length is 10 octets. 1538 This AVP encodes the most significant digits of a number, encoded as 1539 a 64 unsigned integer, in network byte order. If decimal values are 1540 needed to present the number, the scaling MUST be indicated with a 1541 related Exponent AVP. For example, the decimal number 0.05 is 1542 encoded by a Value-Digits AVP set to 5, and a scaling that is 1543 indicated with the Exponent AVP set to -2. 1545 4.3.9. Exponent AVP 1547 The type of the Exponent AVP is TBD and its length is 6 octets. This 1548 AVP contains the exponent value that is to be applied to the 1549 accompanying Value-Digit AVP. It contains a 32 bit signed value, in 1550 network byte order. 1552 4.3.10. Update-Reason AVP 1554 The type of the Update-Reason AVP is TBD and its length is 4 octets. 1555 This AVP shall be present in the on-line RADIUS Access-Request 1556 message (PPC to PPS direction). It indicates the reason for 1557 initiating the on-line quota update operation. Update reasons 6, 7, 1558 8 and 9 indicate that the associated resources are released at the 1559 client side, and that therefore the PPS shall not allocate a new 1560 quota in the RADIUS Access Accept message. 1562 1. Pre-initialization 1564 2. Initial Request 1566 3. Threshold Reached 1568 4. Quota Reached 1570 5. TITSU Approaching 1572 6. Remote Forced Disconnect 1574 7. Client Service Termination 1576 8. "Access Service" Terminated 1578 9. Service not established 1580 10. One-Time Charging 1582 4.3.11. PrepaidServer AVP 1584 The type of the PrepaidServer AVP is TBD and its length is 6 or 18 1585 octets, for IPv4 and IPv6 addresses respectively. This optional AVP 1586 indicates the address of the serving PPS. If present, the Home 1587 RADIUS server uses this address to route the message to the serving 1588 PPS. The attribute may be sent by the Home RADIUS server. Multiple 1589 instances of this subtype MAY be present in a single PPAQ AVP. 1591 If present in the incoming RADIUS Access-Accept message, the SAD 1592 shall send this attribute back without modifying it in the subsequent 1593 RADIUS Access-Request message, except for the first one. If multiple 1594 values are present, the SAD shall not change their order. 1596 4.3.12. Service-ID AVP 1598 The type of the Service-ID AVP is TBD and its length is undefined. 1599 This AVP encodes an opaque string that uniquely describes the service 1600 instance to which prepaid metering should be applied. A Service-Id 1601 could be an IP 5-tuple (source address, source port, destination 1602 address, destination port, protocol). If a Service-ID AVP is present 1603 in the PPAQ, the entire PPAQ refers to that service. If a PPAQ does 1604 not contain a Service-Id or Rating-Group-ID, then the PPAQ refers to 1605 the Access Service. 1607 4.3.13. Rating-Group-ID AVP 1609 The type of the Rating-Group-ID is TBD and its length is 6 octets. 1611 This AVP indicates that this PPAQ is associated with resources 1612 allocated to a Rating Group with the corresponding ID. This AVP is 1613 encoded as a 32 bit unsigned value, in network byte order. A PPAQ 1614 MUST NOT contain more than one Rating-Group-ID. 1616 4.3.14. Termination-Action AVP 1618 The type of the Termination-Action AVP is TBD and its length is 3 1619 octets. This AVP contains an enumeration of the action to take when 1620 the PPS does not grant additional quota. Valid actions are as 1621 follows. (Note that the value 0 is reserved.) 1623 1. Terminate 1625 2. Request More Quota 1627 3. Redirect/Filter 1629 4.3.15. Pool-ID AVP 1631 The type of the Pool-ID) AVP is TBD and its length is 6 octets. This 1632 AVP identifies the resource pool that the quota included in this PPAQ 1633 is associated with. It is encoded as a 32 bit unsigned value, in 1634 network byte order. 1636 4.3.16. Pool-Multiplier AVP 1638 The type of the Pool-Multiplier AVP is TBD and its length is 12 or 18 1639 octets. The pool-multiplier determines the weight that resources are 1640 inserted into the pool that is identified by the accompanying Pool-ID 1641 AVP, and the rate at which resources are taken out of the pool by the 1642 relevant Service or Rating-Group. The attribute consists of a Value- 1643 Digits AVP and optionally an Exponent AVP (as indicated by the length 1644 field). 1646 4.3.17. Requested-Action AVP 1648 The type of the Requested-Action AVP is TBD and its length is 3 1649 octets. This AVP can only be present in messages sent from the PPC 1650 to the PPS. It indicates that the user or the PPC desires the PPS to 1651 perform the indicated action and to return the result. The PPAQ in 1652 which a Requested-Action AVP occurs MUST NOT contain a QID, and MUST 1653 contain a Service-Identifier that, possibly in combination with other 1654 AVPS, can be used by the PPS to uniquely identify the service for 1655 which the indicated action is requested. The following actions may 1656 be requested. 1658 1. Balance Check 1660 2. Price Enquiry 1662 4.3.18. Check-Balance-Result AVP 1664 The type of the Check-Balance-Result AVP is TBD and its length is 3 1665 octets. This AVP can only be present in messages sent from the PPS 1666 to the PPC. It indicates the balance check decision of the PPS about 1667 a previously received Balance Check Request (as indicated in a 1668 Requested-Action AVP). Possible values are 0 for "success" and 1 for 1669 "failure" and mean that sufficient funds are available (resp. are not 1670 available) in the user's prepaid account. The PPAQ in which a Check- 1671 Balance-Result occurs MUST NOT include a QID, because no quota is 1672 reserved by the PPS. 1674 4.3.19. Cost-Information AVP 1676 The type of the Cost-Information AVP is TBD and its length is 1677 variable. This AVP is used in order to return the cost information 1678 of a service, which the PPC can transfer transparently to the end 1679 user. This AVP is sent from the PPS to the PPC as a response to a 1680 "Price Enquiry", as indicated by the Requested-Action AVP. This AVP 1681 consists of four further AVPs, as follows. 1683 1. Value-Digits ASP: this encodes the most significant digits of the 1684 monetery value that represents the cost in question. 1686 2. Exponent AVP: this encodes the exponent that applies to the 1687 Value-Digits AVP. 1689 3. Currency-Code AVP: the type of this AVP is TBD, and its length is 1690 4 octets. It encodes the currency code, as defined in the ISO 1691 4217 standard. 1693 4. Cost-Unit AVP: the type of this AVP is TBD and its length is 1694 variable. It carries a UTF8String encoded human readable string 1695 that can be displayed to the end user. It specifies the 1696 applicable unit to the Cost-Information when the service cost is 1697 a cost per unit (e.g., cost of the service is $1 per minute). 1698 The Cost-Unit can be minutes, hours, days, kilobytes, megabytes, 1699 etc. 1701 Example: the cost of 7.75 Malawi kwacha per hour would be encoded as 1702 follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, and 1703 Cost-Unit = "hour". 1705 The PPAQ in which a Cost-Information occurs MUST NOT include a QID, 1706 because no quota is actually reserved by the PPS. 1708 NOTES: Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear 1709 in the PPAQ attribute. A PPAQ MUST NOT contain more than one 1710 Service-Id, MUST NOT contain more than one Rating-Group-Id, and MUST 1711 NOT contain both a Service-Id and a Rating-Group-Id. A PPAQ that 1712 does not contain a Service-ID or a Rating-Group-Id refers to the 1713 "Access Service". A PPAQ MUST NOT contain more than one Pool-Id. A 1714 PPAQ that contains a Pool-Id MUST also contain a Pool-Multiplier AVP. 1716 4.4. Prepaid Tariff Switching Attribute (PTS) 1718 This specification defines the PTS attribute which allows for 1719 changeovers from one rate to another during service provision. 1720 Support for tariff switching is optional for both the PPC and the 1721 PPS. PPCs use the flag "Tariff Switching supported" of the 1722 AvailableInClient subtype of the PPAC attribute in order to indicate 1723 support for tariff switching. PPSs employ the PTS attribute in order 1724 to announce their support for tariff switching. Details of this will 1725 be specified after the format of the PTS attribute has been defined. 1727 If a RADIUS message contains a PTS attribute, it MUST also contain at 1728 least one PPAQ attribute. If a RADIUS Access-Request message 1729 contains a PTS attribute or a "Tariff Switching supported" flag, it 1730 MUST also contain an Event-Timestamp RADIUS attribute (see [3]). 1732 The type of the PTS attribute is TBD and its lengh is variable. It 1733 contains one or more subtypes, as follows. Every PTS AVP MUST 1734 include a QuotaIdentifier AVP as specified in Section 4.3.1. In an 1735 online RADIUS Access-Request message sent from the PPC to the PPS, 1736 the QuotaIdentifier AVP must contain a quota identifier that was 1737 previously received from the PPS and MUST be the same as a quota 1738 identifier of one of the PPAQ attributes included the same RADIUS 1739 message. 1741 A PPAQ attribute that is transported along with a PTS attribute and 1742 has the same quota identifier value as the PTS attribute in its own 1743 QID subfield shall be referred to as the "accompanying PPAQ 1744 attribute". If a PPS receives an Access-Request message from a PPC, 1745 it associates a unique quota identifier to this request. Thus, a 1746 quota identifier also identifies a particular service. 1748 The PTS AVP contains a number of other subtype AVPs which are 1749 specified in the following subsections. 1751 4.4.1. VolumeUsedAfterTariffSwitch AVP 1753 The type of the VolumeUsedAfterTariffSwitch attribute is TBD and its 1754 length is 12 or 18 octets. The VolumeUsedAfterTariffSwitch subtype 1755 SHALL be used in online RADIUS Access-Request messages (PPC to PPS 1756 direction). It indicates the volume (in octets) used during a 1757 session after the last tariff switch for the service specified via 1758 the QID subfield and the accompanying PPAQ attribute. The attribute 1759 consists of a Value-Digits AVP and optionally an Exponent AVP (as 1760 indicated in the length field). 1762 4.4.2. TariffSwitchInterval AVP 1764 The type of the TariffSwitchInterval is TBD and its length 6 octets. 1765 This AVP MUST be present in each PTS attribute that is part of a 1766 RADIUS Access-Accept message (PPS to PPC direction). It indicates 1767 the interval (in seconds) between the value of Event-Timestamp RADIUS 1768 attribute (see [3]) of the corresponding RADIUS Access-Request 1769 message and the next tariff switch condition. 1771 4.4.3. TimeIntervalafterTariffSwitchUpdate AVP 1773 The type of the TimeIntervalafterTariffSwitchUpdate (TITSU) AVP is 1774 TBD and its length is 6 octets. The PPS MUST include this AVP if 1775 there is another tariff switch period after the period that ends as 1776 indicated by the TSI attribute. The TITSU attribute encodes the 1777 number seconds of the tariff period that begins immediately after the 1778 period that ends as indicated by the TSI attribute. If the TITSU 1779 attribute is zero or omitted, the PPC assumes that the tariff period 1780 which ends as indicated by the TSI attribute lasts until further 1781 notice. If TITSU is specified, the PPC MUST send a quota update 1782 before the point in time specified by the TITSU attribute (see 1783 Figure 9). 1785 If a RADIUS message contains a PTS attribute, it MUST also contain at 1786 least one PPAQ attribute. The PTS is associated with the PPAQ by the 1787 QID. If multiple services are supported and if the PPAQ is 1788 associated with a service as indicated by the Service-ID AVP, then 1789 the PTS refers to the tariff switch for that service. If the PPAQ 1790 does not have a Service-ID, then the PTS refers to tariff switch for 1791 the Access-Service. 1793 If a PPC supports tariff switching then it MUST set the 0x00000040 1794 (Tariff switching supported) flag of the AvailableInClient subtype of 1795 the PPAC attribute that is contained in the Access-Request packet 1796 starting the session. 1798 5. Translation between RADIUS prepaid and Diameter Credit Control 1800 In scenarios where the service metering device uses the "RADIUS 1801 prepaid" (RPP) protocol for accounting and prepaid charging while the 1802 AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, 1803 a translation agent that enables the interoperation of both systems, 1804 is desirable. This also applies vice versa, i.e. in scenarios where 1805 the AAA infrastructure uses RADIUS and the service metering device 1806 uses Diameter. 1808 The idea of such a translation agent would be to convert incoming RPP 1809 (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It 1810 would be, in principle, desirable for the translation agent to be 1811 stateless. That is, the agent should not be required to internally 1812 maintain information about each ongoing RADIUS or Diameter session. 1813 However, under the current specification of RPP and DCC, this appears 1814 to be impossible due to a number of reasons. These include the 1815 following. 1817 1. The transport mechanism for DCC is TCP, which requires per- 1818 session state to be maintained at both endpoints of the 1819 communication. Note, however, that, in principle, each DCC 1820 message could be sent over a dedicated TCP connection which is 1821 torn down as soon as the message is sent. This, however, is 1822 likely to be unacceptable in terms of efficiency. 1824 2. While RPP messages encode the cumulative amount of consumed/ 1825 requested resources, DCC messages carry the difference from the 1826 previous message. This means that the translation agent has to 1827 maintain the current amount of consumed/requested resources in 1828 order to be able to calculate the correct amount to be put into 1829 an outgoing message. 1831 The translator maps each incoming RPP (resp. DCC) message into an 1832 outgoing DCC (resp. RPP) message, and possibly establishes or updates 1833 local state that is associated with the session. The translated 1834 (i.e. outgoing) message is a function of the incoming message as well 1835 as existing state that is associated with the current session. 1837 Translation occurs on an attribute-by-attribute basis. Certain 1838 attributes are translated without consideration of local per-session 1839 state. Other attributes, namely those that are bound to a particular 1840 session, require such consideration. The translation agent has to 1841 identify the session (and possibly subsession) an incoming message 1842 belongs to in order to consult the appropriate local per-session 1843 state. 1845 Note that certain DCC attributes cannot be translated due to their 1846 semantics not being present in RPP, and vice versa. This results in 1847 the messages, in which these attributes occur, not being delivered to 1848 their intended destination. In such cases it is desirable to inform 1849 the originator about the failure and terminate the session. 1851 In each scenario (i.e. RPP client / DCC AAA infrastructure and DCC 1852 client / RPP AAA infrastructure), the translator operates in two 1853 directions, namely RPP to DCC and vice versa. In the following 1854 sections, the notation c->s means that the attribute in question may 1855 occur only in the direction from the client to the server. The 1856 notation s->c denotes the converse and the notation c<->s denotes 1857 that the attribute may occur in messages that are directed in either 1858 direction. 1860 5.1. Session Identification 1862 The translation agent has to keep per-session state in order to 1863 perform its task. A session may be identified based on the RPP 1864 identifier or the DCC session identifier. That is, the translation 1865 agent should always maintain a pair of (RPP, DCC) session identifiers 1866 and maintain the per-session state in association with that pair. 1867 This per-session state must be addressable by either of these two 1868 identifiers. Moreover, an RPP session identifier must uniquely 1869 correspond to a DCC identifier. (If this holds, the converse also 1870 holds.) Each subsession identifier within an RPP session must also 1871 uniquely correspond to a subsession identifier within its 1872 corresponding DCC session. (If this holds the converse also holds.) 1874 5.2. Translation between RADIUS prepaid client and Diameter Credit 1875 Control AAA infrastructure 1877 This section describes the translator in the "RPP client / DCC AAA 1878 infrastructure" case. In other words, in this section it is assumed 1879 that the client "talks" RPP and the AAA inftrastructure "talks" DCC. 1880 The translator is assumed to sit somewhere in the middle and to 1881 mediate between client and server. 1883 For each RPP AVP (i.e. AVP that is specified in the present 1884 document), the transformation into a semantically equivalent DCC AVP 1885 (if such an AVP exists), along with what per-session state the 1886 translator has to create or consult, is described. For clarity of 1887 exposition, each RPP AVP is addressed in a separate subsection. 1888 Since in this scenario, the PPC is typically the initiator a session, 1889 the focus is on the RPP AVPs. 1891 5.2.1. PPAC (c<->s) 1893 A DCC client is assumed to always support Volume metering, Duration 1894 metering, Resource metering, Pools, Rating groups, and Tariff 1895 Switching. Thus, if a PPAQ that indicates any of the above is sent 1896 client->server, the translator does the following: It lets message go 1897 through but remembers what exactly the client supports. If the 1898 server later requests (servier -> client direction) an unsupported 1899 metering to be performed, send failure to server and cause the 1900 session to be terminated at the client. 1902 If a PPAC indicates support for multiple services (0x00000020), the 1903 translator maps this onto a DCC Multiple-Services- Indicator AVP. 1905 5.2.2. Service Termination Attribute (c->s) 1907 The Diameter base protocol assumes that the client always supports 1908 dynamic session termination. If this AVP is present, the translator 1909 does not need to do anything, i.e. there exists no DCC AVP that this 1910 AVP can be mapped to. If this AVP is absent, the message in which it 1911 appears should either be discarded and originator should be informed 1912 of a failure, or the message can be passed on (without this AVP being 1913 mapped onto a DCC AVP). However, in the latter case, the translator 1914 has to remember that the client does not support dynamic termination. 1915 Thus, the translatior has to initiate the normal session termination 1916 procedure with the client when (if) dynamic termination is later 1917 initiated by the server. 1919 5.2.3. Quota Identifier Attribute (c<->s) 1921 When quota is allocated for the first time by the DCC server, the 1922 translator has to create a QID AVP, as required by this 1923 specification. The translator later uses a QID AVP that is sent in 1924 the client-to-server direction in order to identify the corresponding 1925 DCC session. The QID has to be saved in the translator's per session 1926 state. 1928 5.2.4. Volume Quota Attribute (c<->s) 1930 If this AVP occurs in a message that is sent in the server-to-client 1931 direction, it is translated into a Granted-Service-Unit AVP with an 1932 embedded CC-Total-Octets AVP. [editor's note: this sentence belongs 1933 to the other translation type, i.e. AAA = RPP and client = DCC.] 1935 If this AVP occurs in a message that is sent in the client-to-server 1936 direction, then it is translated into a Used-Service-Unit AVP with an 1937 embedded CC-Total-Octets AVP. Note that only the difference between 1938 current cumulative quota for the (sub)session and the quota in 1939 incoming messages is indicated in the translated DCC message. Local 1940 state is updated with cumulative consumed resources. 1942 Conversely, if the server grants quota using the DCC Granted-Service- 1943 Unit AVP with an embedded CC-Total-Octets AVP, then the translation 1944 agent must translate this into a Volume Quota Attribute. Again, 1945 local state must be consulted so that the cumulative amount of octets 1946 is indicated in the Volume Quota attribute. 1948 5.2.5. Duration Quota Attribute (c<->s) 1950 If this AVP occurs in a message that is sent in the server-to-client 1951 direction, it is translated into a Granted-Service-Unit AVP with an 1952 embedded CC-Time AVP. [editor's note: this sentence belongs to the 1953 other translation type, i.e. AAA = RPP and client = DCC.] 1955 If this AVP occurs in a message that is sent in the client-to-server 1956 direction, then it is translated into a Used-Service-Unit AVP with an 1957 embedded CC-Time AVP. Note that only the difference between current 1958 cumulative quota for the (sub)session and the quota in incoming 1959 messages is indicated in the translated DCC message. Local state is 1960 updated with cumulative consumed resources (i.e. time). 1962 Conversely, if the server grants quota using the DCC Granted-Service- 1963 Unit AVP with an embedded CC-Time AVP, then the translation agent 1964 must translate this into a Duration Quota attribute. Again, local 1965 state must be consulted so that the cumulative amount of seconds is 1966 indicated in the Duaration Quota attribute. 1968 5.2.6. Resource Quota Attribute (c<->s) 1970 If this AVP occurs in a message that is sent in the server-to-client 1971 direction, it is translated into a Granted-Service-Unit AVP with an 1972 embedded CC-Service-Specific-Units AVP. [editor's note: this sentence 1973 belongs to the other translation type, i.e. AAA = RPP and client = 1974 DCC.] 1976 If this AVP occurs in a message that is sent in the client-to-server 1977 direction, then it is translated into a Used-Service-Unit AVP with an 1978 embedded CC-Service-Specific-Units AVP. Note that only the 1979 difference between current cumulative quota for the (sub)session and 1980 the quota in incoming messages is indicated in the translated DCC 1981 message. Local state is updated with cumulative consumed resources 1982 (i.e. resources). 1984 Conversely, if the server grants quota using the DCC Granted-Service- 1985 Unit AVP with an embedded CC-Service-Specific-Units AVP, then the 1986 translation agent must translate this into a Resource Quota 1987 attribute. Again, local state must be consulted so that the 1988 cumulative amount of resource units is indicated in the Resource 1989 Quota attribute. 1991 Note that the "resource" type is application dependent. This means 1992 that a DCC application unit corresponds to n RPP application units, 1993 where n may be any real number. If n is not 1, then the RPP/DCC 1994 translator must be aware of that and translate resource units 1995 accordingly. 1997 5.2.7. Value Digits Attribute (c<->s) 1999 The encoding of this AVP is similar in RPP and DCC, and the value it 2000 holds may have to be evaluated in conjunction with an acommpanying 2001 "Exponent" AVP. It should be kept in mind that, in RPP the 2002 cumulative amount of granted/consumed quota is typically encoded into 2003 an AVP of this type, while in DCC only the difference from a previous 2004 message. 2006 5.2.8. Exponent Attribute (c<->s) 2008 The encoding of this AVP is similar in RPP and DCC, and the value it 2009 holds may have to be evaluated in conjunction with an acommpanying 2010 "Value Digits" AVP. It should be kept in mind that, in RPP the 2011 cumulative amount of granted/consumed quota is typically encoded into 2012 a related "Value Digits" and "Exponent" AVP pair, while in DCC only 2013 the difference from a previous message is encoded into such a pair. 2015 5.2.9. Volume/Duration/Resource Threshold Attributes (s->c) 2017 In DCC the concept of "threshold" does not exist. Instead, the DCC 2018 client is assumed to ask for the replenishment of quota in good time. 2019 In RPP, on the other hand, the server may optionally include a 2020 threshold AVP, as an indication to the PPC about when to ask for 2021 quota replenishment. 2023 Thus, in this scenario, there is no need for the translator to ever 2024 include a threshold attribute into the messages that it sends to the 2025 PPC. If, however, there is a need for a threshold attribute to be 2026 present in order to avoid a possible service provision 2028 5.2.10. Update Reason Attribute (c->s) 2030 The DCC AVP that is semantically closer to the Update Reason AVP than 2031 any other AVP is the CC-Request-Type AVP. This AVP indicates whether 2032 the message is which it appears is intended to indicate an "initial", 2033 an "intermediate" or a "final interrogation". Morever, in case of 2034 the session being terminated at the client, it indicates the reason 2035 for this termination. 2037 The following list lists the possible values of an "Update Reason" 2038 attribute, along with corresponding values for the CC-Request-Type 2039 AVP. 2041 o Pre-initialization: No action/value defined. 2043 o Initial Request: Typically an "intial interrogation" is triggered 2044 as a result of the reception of the message that contains this 2045 Update Reason AVP. Hence, CC-Request-Type AVP indicates 2046 "INITIAL_REQUEST". 2048 o Threshold Reached: The reception of the message containing this 2049 Update Reason AVP typically triggers an "intermediate 2050 interrogation". Hence, CC-Request-Type AVP indicates 2051 "UPDATE_REQUEST". 2053 o Quota Reached: The reception of the message containing this Update 2054 Reason AVP typically triggers an "intermediate interrogation". 2055 Hence, CC-Request-Type AVP indicates "UPDATE_REQUEST". 2057 o TITSU Approaching: The reception of the message containing this 2058 Update Reason AVP typically triggers an "intermediate 2059 interrogation". Hence, CC-Request-Type AVP indicates 2060 "UPDATE_REQUEST". 2062 o Remote Forced Disconnect: Reception of such an Update Reason 2063 indicates that the client has terminated the session. The 2064 corresponding value for the CC-Request-Type AVP is 2065 "TERMINATION_REQUEST". 2067 o Client Service Termination: Reception of such an Update Reason 2068 indicates that the client has terminated the session. The 2069 corresponding value for the CC-Request-Type AVP is 2070 "TERMINATION_REQUEST". 2072 o "Access Service" Terminated: Reception of such an Update Reason 2073 indicates that the client has terminated the session. The 2074 corresponding value for the CC-Request-Type AVP is 2075 "TERMINATION_REQUEST". 2077 o Service not established: Reception of such an Update Reason 2078 indicates that the client has terminated the session. The 2079 corresponding value for the CC-Request-Type AVP is 2080 "TERMINATION_REQUEST". 2082 o One-Time Charging: Such an Update Reason indicates that a one-time 2083 charging event is initiated by the client. The corresponding 2084 value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a 2085 "Requested-Action: AVP MUST also be included in the outgoing DCC 2086 message. Typically, this would be of the type "DIRECT_DEBITING", 2087 or "REFUND_ACCOUNT", depending on other AVPs present in the 2088 message. 2090 5.2.11. PrepaidServer Attribute (s<->c) 2092 The PPC typically never sets the value of a PrepaidServer attribute. 2093 Instead, it repeats those values that it receives from the AAA 2094 infrastructure, in this scenario from the translator. This attribute 2095 is therefore not used in a translation scenario. Nevertheless, the 2096 translator must make sure that messages about the same RPP session 2097 are forwarded to the same DCC server, throughout the whole session. 2098 This may be easy to guarantee since the transport of Diameter is TCP. 2100 5.2.12. Service-ID Attribute (s<->c) 2102 The DCC equivalent of a RPP "Service-ID" AVP is the combination of 2103 Service-Context-Id and Service-Identifier AVPs. The translator must 2104 keep a static equivalence table of the RPP Service-ID and the 2105 corresponding DCC combination in order to correctly translate an RPP 2106 service identifier into DCC and back. 2108 5.2.13. Rating-Group-ID Attribute (s<->c) 2110 The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a 2111 "Rating-Group-ID". Depending on the configuration, this AVP may 2112 contain the same value on both the RPP and the DCC side of the 2113 communication. If, however, static rating groups are configured 2114 between the RCC client and the translator, and different rating 2115 groups between the DCC server and the translator, then the translator 2116 has to maintain a static translation table for the rating group 2117 identifier. In any case, the translation of a rating group AVP, is 2118 not a function of the translator's local per-session state. 2120 5.2.14. Termination-Action Attribute (s->c) 2122 The DCC equivalent of the "Termination-Action" AVP is called the 2123 "Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA 2124 infrastructure), a DCC "Final-Unit-Action" AVP is translated into a 2125 "Termination-Action" AVP. The following list contains the possible 2126 "Final-Unit-Action" values along with their "Termination-Action" 2127 equivalent. 2129 o TERMINATE (DCC): This value has a direct equivalent in RPP, also 2130 called "Terminate". 2132 o REDIRECT (DCC): If this value appears in a "Final-Unit-Action" 2133 AVP, then a "Redirect-Server-Address" AVP must also appear in the 2134 same DCC message. The translator translates these two AVPs into a 2135 "Termination-Action" with value "Redirect/Filter" and an 2136 eqiovalent NAS-Filter-Rule attribute (specified in http:// 2137 www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt). 2139 o RESTRICT_ACCESS (DCC): If this value appears in a "Final-Unit- 2140 Action" AVP, then a "Restriction-Filter-Rule" AVP must also appear 2141 in the same DCC message. The translator translates these two AVPs 2142 into a "Termination-Action" with value "Redirect/Filter" and an 2143 eqiovalent Filter-ID attribute (specified in http://www.ietf.org/ 2144 internet-drafts/draft-ietf-radext-ieee802-00.txt). 2146 o In the absence of a "Final-Unit-Action" AVP, the DCC server 2147 assumes that the DCC client will ask for replenishment of quota at 2148 some suitable time. In RPP, this is explicitly conveyed via a 2149 "Termination-Action" AVP with the value "Request More Quota". 2150 Thus, in the absence of a "Final-Unit-Action" AVP, the translator 2151 in this scenario appends such an AVP into the outgoing RPP 2152 message. 2154 5.2.15. Pool-ID Attribute (s<->c) 2156 The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID". 2157 Typically, no translation needs to be done to the "Pool-ID" 2158 attribute. 2160 5.2.16. Multiplier Attribute (s<->c) 2162 The multiplier attribute, which is a pair of "Value-Digits" and 2163 "Exponent" AVPs, typically needs no translation, since the value it 2164 carries (inside a "Value-Digits" and an "Exponent" AVP) represents 2165 the rating of the service or rating group to which it refers, with 2166 respect to abstract units. As such, the same multiplier value would 2167 typically applyt be conveyed from a DCC server to an PPC, and vice 2168 versa. 2170 5.2.17. Requested-Action Attribute (c->s) 2172 The "Requested Action" AVP can be directly translated into its DCC 2173 equivalent, which carries the same name. 2175 1. Balance Check (PCC): CHECK_BALANCE (DCC) 2177 2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC) 2179 5.2.18. Check-Balance-Result Attribute (s->c) 2181 This attribute carries only a binary value. Hence, its translation 2182 is straightforward. 2184 5.2.19. Cost-Information Attribute (s->c) 2186 This attribute consists of a Value-Digits AVP, an Exponent AVP, a 2187 Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise 2188 exist in DCC, and carry identical semantics in the context of the 2189 "Cost-Information" AVP. Thus, the translation of this attribute is 2190 straightforward. 2192 5.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) 2194 This attribute carries the amount of octets that were consumed after 2195 a tariff change. It always appears in a message with an accompanying 2196 PPAQ attribute in which the total amount of octets (i.e. those that 2197 were consumed both before and after the tariff switch) is reported. 2198 Thus, the translation agent can compute the amount of octets that 2199 were consumed before the tariff change. 2201 In DCC, the two amounts, i.e. the octets that were consumed before a 2202 tariff change and those that were consumed afterwards, are reported 2203 in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs 2204 have an embedded CC-Total-Octets AVP that indicates the appropriate 2205 amount of octets. Furthermore, the Used-Service-Unit AVP that 2206 carries the amount that was consumed before the tariff switch also 2207 carries an embedded Tariff-Change-Usage AVP with the value 2208 UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP 2209 that carries the amount that was consumed after the tariff switch 2210 also carries an embedded Tariff-Change-Usage AVP with the value 2211 UNIT_AFTER_TARIFF_CHANGE (1). 2213 6. Security Considerations 2215 [Editor's Note: A future version of this document will provide a 2216 description of the security threats and the countermeasures.] 2218 7. IANA Considerations 2220 This document requires the assignment of new Radius attributes type 2221 numbers for the following attributes: Prepaid-Accounting-Capability 2222 (PPAC), AvailableInClient, Prepaid-Accounting-Operation (PPAQ), 2223 QuotaIdentifier, (QID), VolumeQuota (VQ), VolumeTreshold (VT), 2224 DurationQuota (DQ), DurationTreshold (DT), UpdateReason (UR), 2225 PrePaidServer (PPS), ServiceID (SID), Rating-Group-ID (RGID), 2226 TerminationAction (TA), PoolID (PID), PoolMultiplier (PM), Cost- 2227 Information (COST), Session-Termination-Capability (STC), 2228 PrepaidTariffSwitch (PTS) and TariffSwitchInterval (TSI). 2230 8. Contributors 2232 The authors would like to thank Christian Guenther and Yong Li for 2233 their contribution to earlier draft versions. 2235 9. References 2237 9.1. Normative References 2239 [1] Bradner, S., "RFC 2119: Key words for use in RFCs to Indicate 2240 Requirement Levels", March 1997. 2242 [2] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2865: 2243 Remote Authentication Dial In User Server (RADIUS)", June 2000. 2245 [3] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS 2246 Extensions", June 2000. 2248 [4] Bradner, S., "RFC 2026: The Internet Standards Process -- 2249 Revision 3", October 1996. 2251 [5] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. 2253 [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and 2254 I. Goyret, "RFC 2868: RADIUS Attributes for Tunnel Protocol 2255 Support", June 2000. 2257 [7] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Adoba, 2258 "RFC 3576: Dynamic Authorization Extensions to Remote 2259 Authentication Dial-In User Service (RADIUS)", February 2003. 2261 [8] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2262 Levkowetz, "RFC 3748: Extensible Authentication Protocol", 2263 June 2004. 2265 9.2. Informative References 2267 [9] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 2268 Loughney, "RFC 4006: Diameter Credit Control Application", 2269 August 2005. 2271 Appendix A. Example flows 2273 This section presents certain example flows that involve the RADIUS 2274 prepaid extensions. By no means is the intent of this section to 2275 specify or recommend business logic, rating strategies, and 2276 application-level behaviour. The intent of this section is purely to 2277 illustrate some fictive scenarios and the RADIUS prepaid message 2278 flows that could be associated with these scenarios. The contents of 2279 this section should be regarded as a collection of informative 2280 examples that aim to provide guidance to implementors. 2282 A.1. A simple flow 2284 End user PPC AAA Server PPS 2286 user logs on 2287 ------(1)---------> 2289 Access Request 2290 {RADIUS BASE AVPS, 2291 PPAC=00...00011} 2292 -------(2)--------> 2294 RADIUS authentication 2295 <--------------(3)----------------------> 2297 Access Request 2298 {RADIUS BASE AVPS, 2299 PPAC=00...00011} 2300 ------(4)---------> 2302 [allocates 2303 5MB quota] 2305 Access Response 2306 {RADIUS BASE AVPS, 2307 PPAQ={QID=5, VQ = 5MB, 2308 VTH = 4.5 MB}} 2309 <-------(5)-------- 2310 forwards message 2311 <-----(6)----------- 2313 service provision/metering 2314 -------(7)---------> 2316 4.5 MB consumed 2317 Access Request 2318 {RADIUS BASE AVPS, 2319 PPAQ={QID=5, VQ=4.5MB, 2320 REASON=THRESHOLD REACHED}} 2321 -------(8)---------> 2323 forwards message 2324 -------(9)-------> 2326 [allocates another 7MB 2327 to the access service] 2329 Access Response 2330 {RADIUS BASE AVPS, 2331 PPAQ={QID=8, VQ=12MB, 2332 VTH = 11.5 MB}} 2333 <----------(10)-------------- 2334 forwards message 2335 <------(11)-------- 2337 user logs off 2338 ------(12)------- 2340 Access Request 2341 {RADIUS BASE AVPS, 2342 PPAQ={QID=8, VQ=7 MB, 2343 REASON=ACCESS SERV TERMINATED}} 2344 -------(13)---------> 2346 forwards message 2347 -------(14)-------> 2349 [reimburses 2350 user account] 2352 AA Response 2353 {RADIUS BASE AVPS} 2354 <------(15)-------- 2355 AA Response 2356 {RADIUS BASE AVPS} 2357 <------(16)-------- 2359 Figure 12: A simple example message flow 2361 The user logs on (1). The PPC sends a RADIUS Access Request message 2362 to the home AAA server (2), and includes the prepaid-specific PPAC 2363 AVP. This AVP indicates that both duration-based and volume-based 2364 metering is supported. However, it also indicated that multiple 2365 services, rating groups and resource pools are not supported. Note 2366 that, since this is not an "Authorize Only" message, no PPAQ AVP with 2367 Update Reason="initial request" is included (see Section 3.7.1). The 2368 home AAA server then authenticates the user and authorizes the access 2369 service, as is usual in RADIUS (3). Note that the PPAC AVP is 2370 appended by the PPC in at least the last message that is sent to the 2371 home AAA server during this possibly multiple-round exchange. 2373 If authentication and authorization is successful (in this example 2374 this is assumed), the home AAA server forwards the final Access 2375 Request to the PPS (4). The PPS identifies the user's prepaid 2376 account from the included base RADIUS AVPs, and determines the 2377 capabilities of the PPC from the PPAC attribute. Assuming that 2378 sufficient funds are available in the user's prepaid account, the PPS 2379 reserves some of these and rates the service. In this example, the 2380 PPS reserves, say, 2 Euros and determines that the access service is 2381 rated at 0.4 Euro per MB. This results in 5 MB of quota being 2382 granted. The PPS also determines that the PPC should ask for this 2383 quota to be replenished once 4.5 MB have been consumed. Thus, it 2384 creates an Access Accept message with a Volume-Threshold indication 2385 of 4.5MB. It further associates the QuotaIdentifier QID=5 to this 2386 quota reservation. This identifier can be used to later uniquely 2387 identify the prepaid session, user, account, etc. The resulting 2388 Access Accept message is sent to the home AAA server (5) and 2389 forwarded to the PPC (6). 2391 Upon reception of message (6), the PPC provides the access service to 2392 the user and meters it accordingly. 2394 At some point in time, the threshold is reached, i.e. 4.5MB of 2395 "access service" have been consumed by the user. At that point, the 2396 PPC generates an Authorize Only Access Request that contains the 2397 usual RADIUS attributes and a PPAQ AVPs that reports the amount of 2398 consumed quota, and the request for replenishment, i.e. the Update- 2399 Reason= THRESHOLD REACHED (8). Note that the QID in this message is 2400 the same as the one previously received from the user's home AAA 2401 server. This message is forwarded to the PPS (9). 2403 Upon reception of message (9), the PPS identifies the user and his 2404 account from the QID. In also determines that a prepaid session is 2405 ongoing, and that enough credit remains in the prepaid account in 2406 order for the access service to continue being provided. Since 4.5 2407 MB have been consumed, the PPS subtracts 1.8 Euros from the user's 2408 prepaid account. The PPS decides to reserve another 2.8 euros from 2409 the user's account. (This results in 3 euros being reserved in total 2410 at this point in time.) As the access service is rated at 0.4 euros 2411 per MB, the PPS determines that another 7 MB of quota should be 2412 granted. This results in a total cumulative quota allocation of 12 2413 MB for the access service. The PPS further calculates the new 2414 threshold value of 11.5 MB. Since this is a new quota reservation, 2415 the PPS also allocates a new QuotaIdentifier to it, in this example 2416 QID=8. The resulting RADIUS message is sent to the home AAA server 2417 (10) and forwarded to the PPC (11). 2419 Upon reception of message (11), the PPC updates its records and 2420 continues provisioning access to the user. At some point the user 2421 logs off (12). The PPC must then report how many resources were 2422 consumed, so that the PPC can subtract the appropriate monetary 2423 amount from the user's prepaid account. To this end the PPC 2424 constructs an Authorize Only Access Request message with a PPAQ AVPs 2425 for the access service. In this example, 7 MB were consumed by the 2426 access service in total. The PPC reports 7 MB its final message 2427 (13). This is forwarded to the PPS (14) which correlates the report, 2428 using the QID, to the previous session state. It determines, from 2429 the previous records, that the access service had consumed another 2430 4.5 MB before (as indicated in message (9)). This means that, of the 2431 7 MB, only 3.5 MB have not yet been subtracted from the user's 2432 account. Thus, the PPS subtracts another 1.4 euros from the user's 2433 account and, since the session is to be terminated (REASON=ACCESS 2434 SERVICE TERMINATED), releases any reserved monetary amount. 2436 The PPS responds with an Access Response as required by the RADIUS 2437 base specification (15). So does the home AAA server (16). 2439 A.2. A flow with prepaid tariff switching 2441 End user PPC AAA Server PPS 2443 user logs on 2444 ------(1)---------> 2446 Access Request 2447 {RADIUS BASE AVPS, 2448 PPAC=00...00111} 2449 -------(2)--------> 2451 RADIUS authentication 2452 <--------------(3)----------------------> 2454 Access Request 2455 {RADIUS BASE AVPS, 2456 PPAC=00...00011} 2457 ------(4)---------> 2459 [allocates 2460 20MB quota] 2462 Access Response 2463 {RADIUS BASE AVPS, 2464 PPAQ={QID=5, VQ = 20MB, 2465 VTH = 18 MB}, PTS={ 2466 QID=5, PTS{TSI=300sec, 2467 TITSU=6000sec}} 2468 <-------(5)-------- 2469 forwards message 2470 <-----(6)----------- 2472 service provision/metering 2473 -------(7)---------> 2475 5900 seconds have passed 2477 Access Request 2478 {RADIUS BASE AVPS, 2479 PPAQ={QID=5, VQ=14MB, 2480 REASON=TITSU APPROACH.}, 2481 TSI={QID=5, VUATS=11MB}} 2482 -------(8)---------> 2484 forwards message 2485 -------(9)-------> 2487 [allocates another 10MB 2488 to the access service] 2490 Access Response 2491 {RADIUS BASE AVPS, 2492 PPAQ={QID=8, VQ=30MB, 2493 VTH = 28 MB},PTS={ 2494 QUD=8, PTS=95 sec}} 2495 <----------(10)-------------- 2496 forwards message 2497 <------(11)-------- 2499 user logs off 2500 ------(12)------- 2502 Access Request 2503 {RADIUS BASE AVPS, 2504 PPAQ={QID=8, VQ=17 MB, 2505 REASON=ACCESS SERV TERMINATED}, 2506 PTS={QID=8, VUATS=2.5 MB} 2507 -------(13)---------> 2509 forwards message 2510 -------(14)-------> 2512 [reimburses 2513 user account] 2515 AA Response 2516 {RADIUS BASE AVPS} 2517 <------(15)-------- 2518 AA Response 2519 {RADIUS BASE AVPS} 2520 <------(16)-------- 2522 Figure 13: Example message flow with Tariff Switch 2524 The user logs on (1). The PPC sends a RADIUS Access Request message 2525 to the home AAA server (2), and includes the prepaid-specific PPAC 2526 AVP. This AVP indicates that both duration-based and volume-based 2527 metering is supported, as well as tariff switching. The home AAA 2528 server then authenticates and user and authorizes the access service, 2529 as is usual in RADIUS (3). Note that the PPAC AVP is appended by the 2530 PPC in at least the last message that is sent to the home AAA server 2531 during this possibly multiple-round exchange. 2533 If authentication and authorization is successful (in this example 2534 this is assumed), the home AAA server forwards the final Access 2535 Request to the PPS (4). The PPS identifies the user's prepaid 2536 account from the included base RADIUS AVPs, and determines the 2537 capabilities of the PPC from the PPAC attribute. In this example, it 2538 is assumed that a tariff switch is about to occur in 300 seconds from 2539 the current time. Suppose that the access service is currently rated 2540 at 0.5 euros per MB and in the next tariff period it is rated at 0.6 2541 euros per MB. Suppose further that a third tariff period is about to 2542 start in 6000 seconds from current time and that that access service 2543 is rated at 0.8 euros per MB in that period. The PPS then decides to 2544 reserve 12 euros from the user's account. Since it is conceivable 2545 that the user may consume all allocated quota in the (more expensive) 2546 "0.6-euro" period, the PPS reserves 20 MB of quota, and determines a 2547 threshold value of 18 MB. It constructs a Radius Access Accept 2548 message with a PPAQ attribute that reflects these choices, and 2549 carries a QuotaIdentifier QID=5. It further adds a PTS AVP in the 2550 message which is linked to the PPAQ via the common QID value. The 2551 PTS AVP contains a TSI attribute indicating that a tariff switch will 2552 occur in 300 seconds. It also includes a TITSU attribute with the 2553 value of 6000 seconds. This is included in order to make sure that 2554 the PPC will report the consumed quota before the "2-euro" tariff 2555 period will start. The message is sent to the AAA server (5) and 2556 forwarded to the PPC (6). 2558 Upon reception of message (6), the PPC provides the access service to 2559 the user and meters it accordingly (7). It also keeps track of time. 2560 That is, it remembers how many octets are consumed before and how 2561 many after the tariff switch that will take place in 300 seconds. 2563 In this example it is assumed that the user consumes the allocated 2564 quota rather slowly. In particular, nearly 6000 seconds (the value 2565 indicated by TITSU) pass without the threshold of 18 MB being 2566 reached. The PPC notices this and must therefore report usage and 2567 request the quota to be replenished despite the fact that the 2568 threshold has not been reached. In this example, it decides to do so 2569 100 seconds before the 6000 seconds are reached. To this end, it 2570 constructs an Authorization Access Request message including a PPAQ 2571 that indicates that 14 MB have been consumed up to now. It also 2572 includes a PTS AVP in order to indicate, using the VUATS AVP, that 11 2573 MB of these were consumed after the tariff switch. The message is 2574 sent to the AAA server (8) and forwarded to the PPS (9). 2576 The PPS can link the message to previous session state via the QID. 2577 It now rates the consumed volume as follows. The 11 MB that were 2578 consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros 2579 and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS 2580 subtracts the amount of 6.6+1.5=8.1 euros from the user's account, 2581 which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved. 2583 The PPS now determines that message (9) was sent in order to 2584 replenish the quota for this prepaid session. This can be deduced 2585 from the UPDATE REASON field, which indicates that the PPC sent this 2586 message because the time indicated by the TITSU AVP is approacing. 2587 The PPS now determines that enough credit remains in the user's 2588 prepaid account in order for the access service to continue being 2589 provided and decides to reserve another 8.9 euros from the user's 2590 account. Since it is conceivable that the user will consume the 6 2591 unused MB of quota from the previous allocation, as well as the 2592 entire quota that is to be allocated now, entirely in the "0.8-euro" 2593 period, the quota that should now be granted in addition to the 2594 previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros 2595 are being reserved in order to "cover the worst case scenario". The 2596 fact that 0.9 euros are reserved for this purpose is due to the fact 2597 that the unused 6 MB from the previous allocation correspond to 4.8 2598 euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more 2599 than the amount of funds that are still "reserved" from the previous 2600 allocation. (After this reservation, the total amount of reserved 2601 money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB 2602 being consumed in the "0.8-euro" period.) 2604 Since quotas are encoded in a cumulative way in RADIUS, the PPS 2605 includes a VolumeQuota of 30 MB into the Access Accept message (10). 2606 The PPS further calculates the new threshold value of 28 MB. Since 2607 this is a new quota reservation, the PPS also allocates a new 2608 QuotaIdentifier to it, in this example QID=8. The resulting RADIUS 2609 message is sent to the home AAA server (10) and forwarded to the PPC 2610 (11). 2612 Upon reception of message (11), the PPC updates its records and 2613 continues providing access to the user. At some point the user logs 2614 off (12). The PPC must then report how many resources were consumed, 2615 so that the PPC can subtract the appropriate monetary amount from the 2616 user's prepaid account. To this end the PPC constructs an Authorize 2617 Only Access Request message with a PPAQ AVPs for the access service. 2618 In this example, 17 MB were consumed by the access service in total. 2619 The PPC reports 17 MB its final message (13). This is forwarded to 2620 the PPS (14) which correlates the report, using the QID, to the 2621 previous session state. It determines, from the previous records, 2622 that the access service had consumed 14 MB before (as indicated in 2623 message (9)). This means that, of the 17 MB, only the monetary 2624 equivalent for 3 MB have not yet been subtracted from the user's 2625 account. The PPS calculates how much should be deducted from the 2626 user's account as follows. Since the VUATS AVP indicates that 2.5MB 2627 were consumed after the tariff switch, only 0.5 MB were consumed 2628 before that. Thus, the monetary equivalent is 0.5 * 0.6 + 2.5 * 0.8 2629 = 3.6 euros. That is, the PPS subtracts 3.6 euros from the user's 2630 prepaid account. Since the session has by now be terminated by the 2631 PPC (REASON=ACCESS SERVICE TERMINATED), the PPS now releases any 2632 reserved monetary amount, in this example 12.8 - 3.6 = 9.2 euros. 2634 The PPS responds with an Access Response as required by the RADIUS 2635 base specification (15). So does the home AAA server (16). 2637 Remark: In this example, two tariff switches take place. In other 2638 scenarios, of course, only one tariff switch may occur. In such 2639 scenarios the TITSU AVP is not used. 2641 A.3. Resource pools and Rating Groups 2643 End user PPC AAA Server PPS 2644 user logs on 2645 ------(1)---------> 2647 Access Request 2648 {RADIUS BASE AVPS, 2649 PPAC=00...00101111} 2650 -------(2)--------> 2652 RADIUS authentication 2653 <--------------(3)----------------------> 2655 Access Request 2656 {RADIUS BASE AVPS, 2657 PPAC=00...00101111} 2658 ------(4)---------> 2660 [allocates 2661 5MB quota] 2663 Access Response 2664 {RADIUS BASE AVPS, 2665 PPAQ={QID=5, VQ = 5MB, 2666 poolID=1,mult=1}} 2667 <-------(5)-------- 2668 forwards message 2669 <-----(6)----------- 2671 service provision/metering 2672 -------(7)---------> 2674 user requests service A 2675 -------(8)---------> 2677 Access Request 2678 {RADIUS BASE AVPS,PPAQ={ 2679 SID="A", RGROUP=1}} 2680 -------(9)--------> 2681 forwards message 2682 -----(10)---------> 2684 [allocates 50 min 2685 quota] 2687 Access Response 2688 {RADIUS BASE AVPS, 2689 PPAQ={QID=7, DQ=3000sec 2690 poolID=1,RGROUP=1, SID="A" 2691 mult=1747.63}} 2693 <---------(11)--------------- 2694 forwards message 2695 <----(12)-------- 2697 user requests service B 2698 -------(13)--------> 2700 Pool 1 close to exhaustion 2702 Access Request 2703 {RADIUS BASE AVPS, 2704 PPAQ={QID=5, VQ=4MB, 2705 REASON=QUOTA REACHED, 2706 PoolID=1, mult=1} 2707 PPAQ={QID=7, DQ=3300sec 2708 REASON=QUOTA REACHED, 2709 PoolID=1, mult=1747.63, 2710 SID="A",RGROUP=1}} 2711 -------(14)---------> 2713 forwards message 2714 -------(15)-------> 2716 [allocates another 2717 3 MB to access service 2718 and 30 minutes to 2719 service "A"] 2721 Access Response 2722 {RADIUS BASE AVPS, 2723 PPAQ={QID=8, VQ=8MB, 2724 PoolID=1, mult=1, RGROUP=1}, 2725 PPAQ={QID=9, DQ=4800sec 2726 PoolID=1, mult=1747.63, 2727 SID="A"}} 2728 <----------(16)-------------- 2729 forwards message 2730 <------(17)-------- 2732 user logs off 2733 ------(18)------- 2735 Access Request 2736 {RADIUS BASE AVPS, 2737 PPAQ={QID=8, VQ=6.5MB, 2738 REASON=ACCESS SERV TERMINATED, 2739 PoolID=1, mult=1} 2740 PPAQ={QID=9, DQ=5400sec 2741 REASON=ACCESS SERV TERMINATED, 2742 PoolID=1, mult=1747.63, 2743 SID="A",RGROUP=1}} 2744 -------(19)---------> 2746 forwards message 2747 -------(20)-------> 2749 [reimburses 2750 user account] 2752 AA Response 2753 {RADIUS BASE AVPS 2754 <------(21)-------- 2755 AA Response 2756 {RADIUS BASE AVPS 2757 <------(22)-------- 2759 Figure 14: Example message flow with resource pools and rating groups 2761 The user logs on (1). The PPC sends a RADIUS Access Request message 2762 to the home AAA server (2), and includes the prepaid-specific PPAC 2763 AVP, indicating that multiple services, rating groups and resource 2764 pools are supported. Note that, since this is not an "Authorize 2765 Only" message, no PPAQ AVP with Update Reason="initial request" is 2766 included (see Section 3.7.1). The home AAA server then authenticates 2767 the user and authorizes the access service, as is usual in RADIUS 2768 (3). Note that the PPAC AVP is appended by the PPC in at least the 2769 last message that is sent to the home AAA server during this possibly 2770 multiple-round exchange. 2772 If authentication and authorization is successful (in this example 2773 this is assumed), the home AAA server forwards the final Access 2774 Request to the PPS (4). The PPS identifies the user's prepaid 2775 account from the included base RADIUS AVPs, and determines the 2776 capabilities of the PPC from the PPAC attribute. Assuming that 2777 sufficient funds are available in the user's prepaid account, the PPS 2778 reserves some of these and rates the service. In this example, the 2779 PPS reserves 5 Euros and determines that the access service is rated 2780 at 1 Euro per MB. In anticipation that the user requests more 2781 chargeable services throughout this prepaid session, and since this 2782 is supported by the PPC, the PPS further associates a resource pool 2783 with this reservation, in this example PoolID=1. The PPC also 2784 specifies the multiplier = 1 for the access service. Note that, 2785 since 5MB = 5242880 octets, 1 unit in the resource pool corresponds 2786 to 5 / 5242880 euros, which is about 0.000095367431640625 Eurocents. 2788 (However, the PPC does not need to know that.) Moreover, the PPS 2789 associates the QuotaIdentifier QID=5 to this quota reservation. This 2790 identifier can be used to later uniquely identify the prepaid 2791 session, user, account, etc. The resulting Access Accept message is 2792 sent to the home AAA server (5) and forwarded to the PPC (6). 2794 Upon reception of message (6), the PPC provides the access service to 2795 the user and meters it accordingly. That is, for every octet 2796 consumed, the PPC subtracts 1 unit (since the multiplier is 1) from 2797 the resouce pool with PoolID=1. 2799 At some point in time, the user requests another chargeable service, 2800 namely service A (8). The PPC generates an Authorize Only Access 2801 Request that contains the usual RADIUS attributes and the Service-ID 2802 identifying service A (9). The PPC has determined that service A is 2803 rated in an identical way as at least one more service. Thus, 2804 service A has been configured to belong to a rating group, in this 2805 example the group with Rating-Group-ID=1. This identifier is 2806 included is message (9), which is then forwarded to the PPS (10). 2808 Upon reception of message (10), the PPS identifies the user and his 2809 account from the base RADIUS attributes, the fact that a prepaid 2810 session is ongoing, and determines that enough credit remains in the 2811 prepaid account in order for service A to be provided. The PPS also 2812 determines that service A is rated at 0.10 euros per minute. The PPS 2813 decides to reserve another 5 euros from the users account; this 2814 corresponds to 50 minutes or, as encoded in the DurationQuota AVP, 2815 3000 seconds. As service A draws from the same prepaid account as 2816 the access service, the PPS associates this reservation with the same 2817 resource pool as the previous reservation (QID=5), namely the pool 2818 with PoolID=1. Note that, in order for the abstract units in the 2819 pool to be consistent, the multiplier has to be 1747.63. This is 2820 because each second corresponds to about 0.10 / 60 = 0.00167 euros, 2821 which is about 1747.63 times the value of an abstract resource pool 2822 unit, as this was determined by the first allocation of quota to the 2823 pool (i.e. 0.000095367431640625 Eurocents). Since this is a new 2824 quota reservation, the PPS also allocates a new QuotaIdentifier to 2825 it, in this example QID=7. The resulting RADIUS message is sent to 2826 the home AAA server (11) and forwarded to the PPC (12). 2828 Upon reception of message (12), the PPC adjusts the units in resource 2829 pool 1. That is, it first determines how much quota had been 2830 allocated to service A in the past, and subtracts this from the quota 2831 reservation found in the message. Since this is the first quota 2832 reservation for service A, there is nothing to subtract. Thus, it 2833 adds 3000 * 1747.63 = 5242890 units to the pool and remembers that 2834 3000 seconds have been allocated to service A during this prepaid 2835 session. The PPC then provides service A to the user, and meters it 2836 against resource pool 1. That is, for every second it subtracts 2837 1747.63 units from the pool. 2839 At some point in time, the user requests service B (13). The PPC 2840 determines that service B is rated exactly in the same way as service 2841 A, i.e. that they belong to the same rating group, namely the one 2842 with Rating-Group-ID=1. Since this rating group has been effectively 2843 authorised by the allocation of quota with QID=7, the PPC provides 2844 service B to the user immediately. It is rated in the same way as 2845 service A, i.e. for every second provided, 1747.63 units are 2846 subtracted from credit pool 1. 2848 At some point in time, resource pool 1 is close to exhaustion. (For 2849 example, the PPC may determine that the pool is "close to exhaustion" 2850 when has less than 10% its initial amount of units.) At that point, 2851 the PPC needs to ask for replenishment for the pool. Suppose that, 2852 at that point in time, 4MB of "access service", 45 minutes of 2853 "service A", and 10 minutes of "service B" were provided to the user. 2854 Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304 2855 + 5767179 = 9961483 abstract service units from the pool. The PPC 2856 constructs an Authorize Only Access Request message that reports the 2857 usage for the "access service" and "service A". This message 2858 contains two PPAQ AVPS, is sent to the home AAA server (14) and 2859 forwarded to the PPS (15). Note that is the message it appears that 2860 "service A" has consumed more than it was allocated (i.e. 55 minutes 2861 although only 50 minutes were initially allocated to it). This is 2862 not a a problem since the PPS knows that "service A" was drawing from 2863 the same pool as the "access service" and that the "access service" 2864 did only consume 4 out of the 5 MB it was allocated. 2866 Upon reception of message (15), the PPS subtracts 4 euros from the 2867 user's account for the "access service" and another 5.5 euros for 2868 "service A". (This includes the charge incurred by "service B" up to 2869 that point in time, although the PPS is not aware of "service B" 2870 being provisioned to the user.) The PPS then determines that 2871 sufficient funds remain in the prepaid account in order for both 2872 services to be continued. The PPS decides to reserve another 3MB for 2873 the access service and 30 minutes for "service A". This corresponds 2874 to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a 2875 cumulative manner, the PPAQ attribute that grants the quota for the 2876 "access service" contains a Volume-Quota AVP of 8MB (8388608 octets), 2877 which is the 5MB that were initially allocated, plus the 3MB 2878 allocated now. The resource pool identifier is, as previously, 2879 PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants 2880 quota for "service A" contains 4800 seconds (the initial 3000 plus 2881 1800 that correspond to the 30 additional minutes). Again, the 2882 PoolID=1 and multiplier=1747.63. The resulting Access Response 2883 message is sent to the home AAA server (16) and forwarded to the PPC 2884 (17). 2886 When the PPC received message (17) it checks how much quota has been 2887 allocated previously to the "access service". It finds that the 2888 answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets) 2889 that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets) 2890 have not yet been added to resource pool 1. The PPC thus adds 2891 3145728 abstract units to resource pool 1 (since the multiplier is 2892 1). The PPC then acts similarly on the other PPAQ attribute that 2893 exists in message (17). That is, the PPC determines that 3000 2894 seconds of quota for "service A" had already been added to the pool. 2895 Thus only 1800 out of the 4800 should be additionally added to the 2896 pool. Since the applicable multiplier here is 1747.63, the PPC adds 2897 further 3145734 abstract units to the pool 1. 2899 The PPC then continues to provide the access service, "service A" and 2900 "service B" to the user, and meters them against the pool, as 2901 previously. 2903 At some point the user logs off (18). The PPC must then report how 2904 many resources were consumed, so that the PPC can subtract the 2905 appropriate monetary amount from the user's prepaid account. To this 2906 end the PPC constructs an Authorize Only Access Request message with 2907 two PPAQ AVPs; one for the access service and one for "service A". 2908 Suppose that, in total, 6.5MB were consumed by the access service, 70 2909 minutes were consumed by "service A" and 20 minutes by "service B". 2910 The PPC reports 6.5MB (6815744 octets) and 90 minutes (5400 seconds) 2911 in its final message (19). This is forwarded to the PPS which 2912 determines, from the previous records, that the access service 2913 consumed another 2.5MB (since 4MB out of the 6.5MB were already 2914 reported in message (15), and that "service A" consumed further 600 2915 seconds. This corresponds to 2.5 + (600/60)*0.1 = 2.5+1=3.5 euros. 2916 Thus, the PPS only subtracts 2.5 out of the 6 previously reserved 2917 euros from the user's prepaid account and responds with an Access 2918 Response as required by the RADIUS base specification. 2920 The home AAA server likewise responds with an Access Response. 2922 Authors' Addresses 2924 Avi Lior 2925 Bridgewater Systems 2926 303 Terry Fox Drive 2927 Ottawa, Ontario Suite 100 2928 Canada 2930 Email: avi@bridgewatersystems.com 2932 Parviz Yegani 2933 Cisco 2934 Mobile Wireless Group, Cisco Systems 2935 3625 Cisco Way, San Jose, California 95134 2936 USA 2938 Email: pyegani@cisco.com 2940 Kuntal Chowdhury 2941 Starent Networks 2942 30 International Place, 3rd Floor 2943 Tewksbury, MA 01876 2944 USA 2946 Email: kchowdhury@starentnetworks.com 2948 Hannes Tschofenig 2949 Siemens 2950 Otto-Hahn Ring 6 2951 Munich, Bavaria 81739 2952 Germany 2954 Email: hannes.tschofenig@siemens.com 2956 Andreas Pashalidis 2957 Siemens 2958 Otto-Hahn Ring 6 2959 Munich, Bavaria 81739 2960 Germany 2962 Email: andreas.pashalidis@siemens.com 2964 Intellectual Property Statement 2966 The IETF takes no position regarding the validity or scope of any 2967 Intellectual Property Rights or other rights that might be claimed to 2968 pertain to the implementation or use of the technology described in 2969 this document or the extent to which any license under such rights 2970 might or might not be available; nor does it represent that it has 2971 made any independent effort to identify any such rights. Information 2972 on the procedures with respect to rights in RFC documents can be 2973 found in BCP 78 and BCP 79. 2975 Copies of IPR disclosures made to the IETF Secretariat and any 2976 assurances of licenses to be made available, or the result of an 2977 attempt made to obtain a general license or permission for the use of 2978 such proprietary rights by implementers or users of this 2979 specification can be obtained from the IETF on-line IPR repository at 2980 http://www.ietf.org/ipr. 2982 The IETF invites any interested party to bring to its attention any 2983 copyrights, patents or patent applications, or other proprietary 2984 rights that may cover technology that may be required to implement 2985 this standard. Please address the information to the IETF at 2986 ietf-ipr@ietf.org. 2988 Disclaimer of Validity 2990 This document and the information contained herein are provided on an 2991 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2992 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2993 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2994 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2995 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2996 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2998 Copyright Statement 3000 Copyright (C) The Internet Society (2005). This document is subject 3001 to the rights, licenses and restrictions contained in BCP 78, and 3002 except as set forth therein, the authors retain all their rights. 3004 Acknowledgment 3006 Funding for the RFC Editor function is currently provided by the 3007 Internet Society.