idnits 2.17.00 (12 Aug 2021) /tmp/idnits53701/draft-lior-radius-prepaid-extensions-12.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3173. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3197. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2007) is 5439 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TS32240' is mentioned on line 262, but not defined == Unused Reference: 'RFC3748' is defined on line 2039, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 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 Intended status: Informational P. Yegani 5 Expires: December 31, 2007 Cisco 6 K. Chowdhury 7 Starent Networks 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Pashalidis 11 NEC 12 June 29, 2007 14 Prepaid Extensions to Remote Authentication Dial-In User Service 15 (RADIUS) 16 draft-lior-radius-prepaid-extensions-12.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on December 31, 2007. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 This document specifies an extension to the Remote Authentication 50 Dial-In User Service (RADIUS) protocol that enables service providers 51 to charge for prepaid services. The supported charging models 52 supported are volume-based, duration-based, and based on one-time 53 events. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7 61 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 9 62 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11 63 1.4. Example Use Case . . . . . . . . . . . . . . . . . . . . . 11 64 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 14 65 2.1. Services and Quotas . . . . . . . . . . . . . . . . . . . 14 66 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 14 67 2.3. Rating Groups . . . . . . . . . . . . . . . . . . . . . . 16 68 2.4. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 17 69 2.5. Support for Roaming . . . . . . . . . . . . . . . . . . . 18 70 2.6. Dynamic Termination . . . . . . . . . . . . . . . . . . . 19 71 2.7. One Time Event . . . . . . . . . . . . . . . . . . . . . . 19 72 2.7.1. One-Time Charging . . . . . . . . . . . . . . . . . . 19 73 2.7.2. Service Price Enquiry . . . . . . . . . . . . . . . . 20 74 2.7.3. Balance Check . . . . . . . . . . . . . . . . . . . . 20 75 2.7.4. Refund . . . . . . . . . . . . . . . . . . . . . . . . 21 76 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22 77 3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 22 78 3.2. Authentication and Authorization Operation . . . . . . . . 22 79 3.3. Session Start Operation . . . . . . . . . . . . . . . . . 23 80 3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24 81 3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 25 82 3.5.1. Unsolicited Session Termination Operation . . . . . . 26 83 3.5.2. Unsolicited Change of Authorization Operation . . . . 26 84 3.6. Termination Operation . . . . . . . . . . . . . . . . . . 26 85 3.7. Operation Considerations for Multiple Services . . . . . . 27 86 3.7.1. Initial Quota Request . . . . . . . . . . . . . . . . 27 87 3.7.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 27 88 3.7.3. Termination . . . . . . . . . . . . . . . . . . . . . 28 89 3.7.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 28 90 3.7.5. Support for Resource Pools . . . . . . . . . . . . . . 28 91 3.7.6. One-time Charging . . . . . . . . . . . . . . . . . . 29 92 3.7.7. Error Handling . . . . . . . . . . . . . . . . . . . . 29 93 3.7.8. Accounting Considerations . . . . . . . . . . . . . . 30 95 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 31 97 4.2. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 32 98 4.3. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 39 99 5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 43 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 101 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 45 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 103 8.1. New RADIUS Attributes . . . . . . . . . . . . . . . . . . 46 104 8.2. New Registry: Prepaid SubTypes . . . . . . . . . . . . . . 46 105 8.3. New Registry: Update-Reason . . . . . . . . . . . . . . . 48 106 8.4. New Registry: Termination-Action . . . . . . . . . . . . . 48 107 8.5. New Registry: Requested-Action . . . . . . . . . . . . . . 48 108 8.6. New Registry: Check-Balance-Result . . . . . . . . . . . . 49 109 8.7. New Registry: AvailableInClient-Extended . . . . . . . . . 49 110 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 112 10.1. Normative References . . . . . . . . . . . . . . . . . . . 51 113 10.2. Informative References . . . . . . . . . . . . . . . . . . 51 114 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 52 115 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 52 116 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 54 117 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 58 118 A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 63 119 A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 64 120 A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 65 121 Appendix B. Translation between RADIUS Prepaid and Diameter 122 Credit Control . . . . . . . . . . . . . . . . . . . 67 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 124 Intellectual Property and Copyright Statements . . . . . . . . . . 77 126 1. Introduction 128 This document specifies an extension to the RADIUS protocol that 129 enables service providers to perform accounting and charging in an 130 "online" fashion. In particular, they enable the service provider to 132 (a) ensure that subscriber's remaining funds suffice before the 133 service is delivered, and 135 (b) interrupt service provision when the funds are exhausted. 137 Note that these capabilities are typically used in scenarios where 138 the subscriber maintains a prepaid account with the service provider; 139 hence, this extension is called the "prepaid" extension for RADIUS. 140 The functionality described in this document is often referred as 141 "online charging" in comparison to "offline charging" support 142 provided by RFC 2866 [RFC2866]. 144 The extensions were designed with the following goals in mind: 146 o Make use of existing infrastructure as much as possible (including 147 enabling the interworking of RADIUS-based and Diameter-based 148 infrastructures), and thereby limit the amount of necessary 149 capital expenditures, 151 o provide the ability to rate service requests in an "online" 152 fashion, 154 o provide the ability to charge the user's account prior to service 155 provision, 157 o protect against revenue loss, i.e., to prevent an end user from 158 obtaining service when the available funds do not suffice, 160 o protect against fraud, and 162 o be deployable for a number of services independent of the access 163 network technology. 165 The architecture between the entities that execute the RADIUS 166 protocols, with the extensions defined in this document, assumes that 167 the rating of chargeable events does not occur in the element that 168 provides the service. Instead, the rating may be performed at a 169 dedicated server, termed the "prepaid-enabled AAA server" or simply 170 "prepaid server" (PPS). Alternatively, the actual rating may occur 171 in an entity related to this prepaid server. 173 Furthermore, this document assumes that a "quota server" is available 174 which, through co-ordination with the rating entity and an account 175 balance manager, is able to provide a quota indication for a 176 particular user when requested. This quota server may or may not 177 coexist in the prepaid server. 179 1.1. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC 2119 [RFC2119]. 185 Prepaid Client (PPC): 187 The entity which triggers the RADIUS message exchange, including 188 the prepaid extensions defined in this document. The PPC provides 189 the service to the users, and executes the RADIUS client which, 190 for the purposes of this document, is termed the "PrePaid Client" 191 (PPC). When the prepaid service is used the PPC collects service 192 event information and reports it while the services is provided to 193 the user. This event information is sent to the PPS using the 194 extensions defined in this document. 196 Prepaid Server (PPS): 198 The entity that interacts with the PPC using the RADIUS prepaid 199 extensions defined in this document. 201 Rating Entity: 203 This entity converts the credit that is allocated by the PPS into 204 a "quota". This quota is then returned to the requesting PPC via 205 the PPS. The rating entity may also determine that during service 206 provision a tariff switch will occur. In this case the rating 207 entity will include details of when exactly tariff switch will 208 occur. 210 Quota: 212 A quota denotes the amount of granted units to be consumed without 213 performing another credit control interaction. 215 Home Network: 217 The network which contains the user profile and the user's prepaid 218 account. 220 Authorize-Only Access Request: 222 A RADIUS message of type "Access Request" (code field = 1) that 223 contains a "Service-Type" AVP (type = 6) with value "Authorize- 224 Only". 226 Offline Charging: 228 Offline charging is a process where charging information for 229 resource usage is collected concurrently with that resource usage. 230 The charging information is then passed through a chain of logical 231 charging functions. At the end of this process, Charging Data 232 Record (CDR) files are generated, which are then transferred to 233 the operator's billing domain for the purpose of subscriber 234 billing and/or inter-operator accounting (or additional functions, 235 e.g., statistics, at the operator's discretion). The billing 236 domain typically comprises post-processing systems, such as the 237 operator's billing system or billing mediation device. In 238 conclusion, offline charging is a mechanism where charging 239 information does not affect, in real-time, the service rendered. 240 [TS32240] 242 Online Charging: 244 Online charging is a process where charging information for 245 resource usage is collected concurrently with that resource usage 246 in the same fashion as in offline charging. However, 247 authorization for the network resource usage must be obtained 248 prior to the actual resource usage to occur. This authorization 249 is granted by the PPS upon request from the PPC. When receiving a 250 resource usage request, the PPS assembles the relevant charging 251 information and generates a charging event in real-time. The PPS 252 then returns an appropriate resource usage authorization. The 253 resource usage authorization may be limited in its scope (e.g., 254 volume of data or duration), therefore the authorization may have 255 to be renewed from time to time as long as the resource usage 256 persists. Note that the charging information utilized in online 257 charging is not necessarily identical to the charging information 258 employed in offline charging. In conclusion, online charging is a 259 mechanism where charging information can affect, in real-time, the 260 service rendered and therefore a direct interaction of the 261 charging mechanism with the control of resource usage is required. 262 [TS32240] 264 1.2. Overview 266 This section provides an overview of the prepaid charging models and 267 architectures, which are supported by the extensions described in 268 this document. 270 A number of models of how to charge customers for services in a 271 prepaid manner are supported: 273 o Volume-based charging (e.g., 2 Cents/KiloByte). 275 o Duration-based charging (e.g., 3 Cents/minute). 277 o Resource-based charging (e.g., 3 videos for 10 Euros) 279 o Event-based charging (e.g., 7 Cents/ring tone) . 281 This draft assumes that the user maintains a prepaid account with his 282 home network. This account may be used to fund multiple services, 283 some of which may use the extensions defined in this document, and 284 some may use other mechanisms. The interworking of these mechanisms 285 is outside the scope of this document. Similarly, the means by which 286 the subscriber obtains funds is also outside the scope of this 287 document. 289 1.2.1. Architectural Model 291 This section describes the architectural model of the protocol 292 extensions described in this document. Figure 1 describes the 293 involved entities. 295 The end user establishes a connection with one of possibly multiple 296 PPCs during service access. The selected PPC communicates with a 297 HAAA server (directly or indirectly via a broker network). 299 The interface between the HAAA and the PPS is implemented using the 300 RADIUS protocol together with the extensions described in this 301 document. However, in cases where the PPS does not implement the 302 RADIUS protocol, the implementation would have to map the 303 requirements defined in this document to a functionally equivalent 304 protocol. 306 The requesting PPC meters the consumption of the service according to 307 the instructions provided by the PPS. After service completion, or 308 on reception of a subsequent request for service, the PPS deducts the 309 corresponding amount of credit from the user account. When a user 310 terminates an on-going service, the PPC informs the PPS with a 311 suitable indication about the unused portion of the allocated quota. 312 The PPS then refunds the user account accordingly. Note that 313 multiple PPSs may be deployed for reasons of redundancy and load 314 sharing. The system may also employ multiple rating servers. 316 Service AAA and 317 Element Prepaid 318 +----------+ +---------+ Protocol +----------+ 319 | End |<---->|+-------+|<------------>| Home AAA | 320 | User | +->|| PCC || | Server | 321 | | | || Client||<----+ | (HAAA) | 322 +----------+ | |+-------+| | +----------+ 323 | +---------+ | Prepaid ^ 324 +----------+ | | Protocol| 325 | End |<--+ | v 326 | User | | +----------+ 327 +----------+ +------->| | 328 Prepapid | PPS | 329 Protocol | | 330 +----------+ 332 Figure 1: Basic Prepaid Architecture 334 The PPS and the accounting server in this architecture may be 335 combined. The PPC must have the ability to meter the consumption of 336 a prepaid data session. This metering is typically based on time 337 (i.e., seconds) or volume (i.e., octets). 339 The device running the PPC may also have "Dynamic Session 340 Capabilities", such as the ability to terminate a data session or to 341 change the filters associated with a specific data session by 342 processing "Disconnect" messages and "Change of Authorization" 343 messages as per RFC 3576 [RFC3576]. 345 This document assumes that the PPS is used as the AAA server. There 346 are three types of AAA server, as follows. 348 The AAA server in the home network (HAAA) is responsible for 349 authentication of the subscriber. In addition, the HAAA communicates 350 with the PPS using the RADIUS protocol in order to authorize 351 subscribers. 353 This document assumes that the PPS communicates with the HAAA for the 354 purposes of authentication and authorisation. The PPS, in turn, 355 interfaces to entities which 357 o keep the subscriber's account balance (balance manager), 359 o rate access service requests in real-time (rating engine), and 361 o manage quota for a particular prepaid service (quota server). 363 The balance manager, the rating engine and the quota server belong to 364 the service provider's backend infrastructure and are outside the 365 scope of this specification. In particular, as far as this 366 specification is concerned, they are assumed to exist in the PPS. 368 Accounting messages are not needed to deliver a prepaid service. 369 However, accounting messages can be used to keep the PPS up-to-date 370 as to what is happening with the prepaid data session. 372 1.2.2. Motivation 374 Why not use existing RADIUS attributes to construct a protocol for 375 prepaid scenarios? This could lead to a solution where no code has 376 to be modified at existing devices. 378 It is indeed possible to construct a solution for prepaid scenarios 379 using existing RADIUS attributes. The RADIUS server would send an 380 Access-Accept message containing a Session-Timeout(27) and include a 381 Termination-Action(29) in the RADIUS-request. Upon receiving the 382 Access-Accept message, the NAS would meter the duration of the 383 session and upon termination of the session the NAS would generate an 384 Access-Request message again. The RADIUS server would then re- 385 authenticate the session and reply with an Access-Accept message 386 indicating the amount of additional time in a Session-Timeout(27). 387 Alternatively, it could respond with an Access-Reject message if 388 there were no more resources in the user account. 390 Moreover, if the user terminates the session prematurely, the NAS 391 could indicate this in the accounting stream so that unused funds can 392 be returned into the prepaid user account. 394 Unfortunately, the above "solution" has a number of drawbacks, 395 including the following. 397 o It only supports time-based charging. The solution presented in 398 this document supports multiple charging metrics. 400 o Using accounting messages to recoup unused time may be problematic 401 because RADIUS accounting messages are not delivered in real-time. 402 A RADIUS server may store-and-forward accounting messages in 403 batches. Thus, relying on accounting messages for the purposes of 404 prepaid may cause revenue leakage. The solution presented in this 405 document does not rely on Accounting packets at all. It uses 406 Access-Request messages, which are required to flow through any 407 network in real-time. 409 o Session-Timeout(27) is not a mandatory attribute. If a prepaid 410 subscriber is served by a NAS that does not adhere to Session- 411 Timeout then that subscriber may use the service for an 412 undetermined period of time. 414 o Termination-Action(29) presents its own issues. Firstly, the 415 behaviour of Termination-Action(29) is not mandatory. Secondly, 416 according to RFC 2865 [RFC2865], Termination-Action fires when the 417 provision of the service has completed. However, service should 418 not be terminated when negotiating additional quota, because this 419 should happen in a manner transparent to the subscriber. Due to 420 the fact that Termination-Action occurs when the service is 421 completed, it is unclear whether or not user experience would be 422 affected if this attribute would be used in a prepaid scenario. 423 The RADIUS server might even allocate a new IP address to the 424 subscriber device after a Termination-Action. Also, the RADIUS 425 server has no way of telling why a given Access-Request message 426 was generated. The RADIUS server might have to wait for the 427 corresponding accounting packet to determine the reason. Finally, 428 re-authenticating the subscriber may take too long. The solution 429 presented in this document allows quota replenishing to occur 430 without affecting user experience. No re-authentication is 431 required and quotas can be negotiated before the available credit 432 actually runs out. 434 o Due to the fact that the standard RADIUS attributes are not 435 mandatory, the correct prepaid operation is really an act of faith 436 on the part of the RADIUS server. If Session-Timeout(27) and/or 437 Termination-Action(29) are not supported, the prepaid subscriber 438 might be able to obtain the service for free. The solution 439 described in this document requires that a PPC informs the RADIUS 440 server, regardless of whether or not the latter supports the 441 prepaid extensions. The RADIUS server can then determine whether 442 or not service should be granted. For example, if a prepaid 443 subscriber is connected to a NAS that does not support prepaid, 444 the RADIUS server can either instruct the NAS to tunnel the 445 traffic to another entity in the home network (e.g., an Home 446 Agent) that supports prepaid, or cause it to provide only a 447 restricted service. 449 The solution presented in this document requires the support of two 450 mandatory and one optional attribute. Furthermore, it does not 451 require a great amount of additional code at a NAS (or similar 452 device) that already supports time or volume-based metering. The 453 solution requires that RADIUS entities advertise their prepaid 454 capabilities in an Access-Request and that they generate an Access- 455 Request packet with Service-Type="Authorize-Only" in order to obtain 456 more quota when or before the current quota is used up. It also 457 requires the NAS to send an Access-Request with Service- 458 Type="Authorize-Only" when the session terminates in order to refund 459 the subscriber account. 461 1.3. Assumptions 463 This document makes the following assumptions. 465 o The values carried in the Service Identifiers are pre-configured 466 between the PPC and the PPS. 468 o The decision about the service rating happens at the PPS. 470 o The decision whether credit control requests for two services are 471 placed in a resource pool are made by the PPS. 473 o The decision which services belong to the same rating group are 474 pre-configured at the PPC. Once a rating group is authorized it 475 is not necessary to re-authorize an additional service that 476 belongs to the same rating group at the PPS again. 478 o A price enquiry is done purely for the purpose of providing AoC 479 for the end user, not for processing at the PPC nor to trigger any 480 specific actions. 482 1.4. Example Use Case 484 This section describes the sequence of events in an example RADIUS 485 prepaid transaction. 487 1. When an end host attaches to a network (for example, using IEEE 488 802.1X), as usual, the PPC that is servicing the subscriber uses 489 the AAA infrastructure in order to authenticate and authorize the 490 subscriber with respect to the requested service. In order to do 491 this, it sends a RADIUS Access-Request to the AAA server. This 492 Access-Request contains the subscriber's credentials and may 493 contain the prepaid capabilities of the PPC. 495 2. The authentication procedure proceeds. This may involve several 496 message exchanges, as it is the case with the Extensible 497 Authentication Protocol (EAP) [RFC2284]. Once the subscriber has 498 been successfully authenticated, the home AAA server determines 499 that the subscriber is a prepaid subscriber and requests 500 authorisation from the PPS. This request MUST include the 501 prepaid capabilities of the serving PPC. 503 3. The PPS, possibly with the help of the backend infrastructure, 504 validates that the subscriber has a prepaid account and that the 505 account is active. It further validates that the PPC has the 506 appropriate prepaid capabilities. If all is in order, the PPS 507 authorises the subscriber to use the network. Otherwise it 508 rejects the request. The decision is sent to the AAA system in 509 the form of a response message. In the case of success, this 510 message contains attributes that indicate the allocation of a 511 portion of the subscriber credit. This portion is called the 512 "initial quota" and is expressed in units of time or volume. The 513 response may also include a threshold value. Note that only a 514 portion of the user's funds is allocated because the user may be 515 engaged in other services that may draw on the same account. For 516 example, the user may be engaged in a data session and a voice 517 session. Although these two services would draw from the same 518 account, they form separate parts of the overall system. If the 519 entire quota was allocated to the data session then the user 520 would have no more funds for a voice session. 522 4. The AAA system incorporates the attributes received from the PPS 523 into an Access-Accept message that it sends to the PPC. Note 524 that the AAA system is responsible for authorizing the service 525 whereas the prepaid system is responsible for prepaid 526 authorization. 528 5. Upon receiving the Access-Response, the PPC starts the prepaid 529 data session and meters the session based on time or volume, as 530 indicated in the message. 532 6. Once the consumption approaches the allocated limit (as expressed 533 by the threshold), the PPC will request additional quota. Re- 534 authorization for additional quota flows through the AAA system 535 to the PPS. The PPS revalidates the subscriber account and 536 subtracts the previously allocated quota from the current 537 balance. If there is remaining balance, it reauthorizes the 538 request with an additional quota allotment. Otherwise, the PPS 539 rejects the request. Note that the replenishment of the quota is 540 a re-authorization procedure and does not require the subscriber 541 to authenticate himself again. 543 7. Upon receiving a re-allotment of the quota, the PPC continues to 544 provide the requested service until the new threshold is reached. 545 If the request for additional quota cannot be fulfilled then the 546 PPC lets the subscriber use the remaining quota and terminates 547 the session. Alternatively, instead of terminating the session, 548 the PPC may restrict service access in such a way that the 549 subscriber can only reach a particular web server. This web 550 server maybe used to allow the subscriber to replenish his 551 account. This restriction can also be used to allow new 552 subscribers to set up prepaid accounts in the first place. 554 8. Should the subscriber terminate the session before the quota is 555 exhausted, the remaining balance allotted to the session is 556 refunded into his account. 558 Note that the subscriber may have disconnected while the PPC is 559 waiting for the initial quota. The entire allocated quota will have 560 to be credited back to the subscribers account in this case. Also 561 note that the PPS maintains session state for the subscriber. This 562 state includes how much account balance was allocated during the last 563 quota enquiry and how much is left in the account. Therefore, it is 564 required that all messages about the session reach the same (and 565 correct) PPS. 567 For a simple message flow, along the lines of this use case, please 568 see Appendix A. 570 2. Supported Features 572 This section describes the features that are supported by the 573 extensions specified in this document. 575 2.1. Services and Quotas 577 Examples of services that the user may be using are browsing the web, 578 participating in a VoIP conversation, watching streaming video and 579 downloading a ring tone. Some operators may want to distinguish 580 between these services and to charge them at different rates and 581 meters them differently. Therefore, the prepaid solution needs to be 582 able to distinguish services, and allocate quota to the services 583 using different unit types (time, volume) and allow for those quotas 584 to be consumed at different rates. 586 +---------+ +---------+ +-------+ 587 | | N 1 | | M 1 | | 588 | Session |<---------->| Service |<---------->| Quota | 589 | | | | | | 590 +---------+ +---------+ +-------+ 592 Figure 2: Multiple services within a single session 594 As shown in Figure 2, a session may be associated with multiple 595 services. Each service is identified by a service identifier 596 (Service-ID). The format of the Service-ID is not in the scope of 597 this document. It may, for example, be expressed as a 5-tuple {i.e., 598 source IP address, destination IP address, source port, destination 599 port, and protocol type}. Each service is associated with a quota 600 whereby a quota might be applicable to multiple services. An example 601 message flow that involves multiple services within a single session 602 is given in the Appendix A. 604 2.2. Resource Pools 606 When working with multiple services a new problem arises because one 607 service may consume its quota faster than another service. When the 608 user balance is close to exhaustion, a situation could arise where 609 one service is unable to obtain quota while another service has 610 plenty of quota remaining. Unless the quotas can be rebalanced, the 611 PPC would then have to terminate the former service. Moreover, each 612 service generates a certain amount of RADIUS prepaid traffic. In an 613 environment with many users and many chargeable services, this amount 614 of traffic may be considerable. 616 To avoid a situation where several parallel (and typically also 617 small) credit reservations must be made on the same account, and also 618 to avoid unnecessary load on the prepaid server, it is possible to 619 provide service units as a "resource pool". Resource pools enable 620 the allocation of resources to multiple services of a session by 621 allocating resources to a pool and have services draw their quota 622 from the pool at a rate appropriate to that service. When the quota 623 that has been allocated to the pool is close to exhaustion, the 624 entire pool (rather than individual services) is replenished. 626 The reference includes a multiplier derived from the rating 627 parameter, which translates from service units of a specific type to 628 the abstract service units in the pool. 630 Figure 3 shows the concept of resource pools graphically. 632 +---------+ +---------+ +----------+ 633 | | N 1 | | M 1 | | 634 | Service |<---------->| Quota |<---------->| Resource | 635 | | | | | Pool | 636 +---------+ +---------+ | | 637 +----------+ 639 Figure 3: Resource Pools 641 If S is the total service units within the pool, M1, M2, ..., Mn are 642 the multipliers provided for services 1, 2, ..., n, and C1, C2, ..., 643 Cn are the used resources within the session, then the pool credit is 644 exhausted and re-authorization MUST be sought when: 646 C1*M1 + C2*M2 + ... + Cn*Mn >= S 648 The total credit in the pool, S, is calculated from the quotas, which 649 are currently allocated to the pool as follows: 651 S = Q1*M1 + Q2*M2 + ... + Qn*Mn 653 For example, if the rating parameter for service 1 is $1/MB and the 654 rating parameter for service 2 is $0.1/min, the multipliers could be 655 10 and 1 for services 1 and 2, respectively. 657 That is, service 1 can be rated at $1 per MB and service 2 can rated 658 at $0.10 per minute. In this case if $5 worth of resources are 659 allocated for service 1 to the pool and if Ma = 10, then 50 units 660 would be placed into the pool. If a further $5 are allocated for 661 service 2 to the pool, then Mb=1 and 50 units are deposited into the 662 pool. The pool would then have a sum of 100 units to be shared 663 between the two services. The PPC would then meter the services such 664 that each Mbyte used by service 1 will draw 10 units from the pool 665 and each minute used by service 2 will draw 1 unit from the pool. 667 2.3. Rating Groups 669 A Rating Group gathers a set of services, identified by a service 670 identifier, and subject to the same cost and rating type (e.g., $0.1/ 671 minute). 673 The rating of a service can be quite complex. While some operators 674 follow linear pricing models, others may wish to apply more complex 675 functions. For example, a service provider may wish to rate a 676 service such that the first N MBytes are free, then the next M Mbytes 677 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 678 per MB. Such a function could be implemented by repeated message 679 exchanges in the prepaid system. 681 To avert the need to exchange many messages while still supporting 682 such complex rating functions, the concept of the Rating Group was 683 introduced. 685 As shown in Figure 6, a Rating Group is associated with one or more 686 services and defines the rate that the services associated with the 687 Rating Group consume an allocated amount of quota. 689 +---------+ +---------+ +----------+ 690 | | N 1 | | M 1 +-------+ P 1 | | 691 | Service |<----->| Rating |<----->| Quota |<----->| Resource | 692 | | | Group | +-------+ | Pool | 693 +---------+ | | | | 694 +---------+ +----------+ 696 Figure 6: Rating Group 698 During the usage of a service that is associated with a Rating Group, 699 the PPC sends the ID of the Rating Group to the PPS. The PPS 700 authorises the Rating Group by allocating a quota to it and assign it 701 to a Resource Pool. When an additional service that belongs to an 702 already authorised Rating Group is instantiated, the PPC does not 703 need to re-authorize this service. This effectively means that the 704 PPC meters the service such that it draws from the already allocated 705 quota. Therefore, no RADIUS messages need to be exchanged in this 706 case. This limits the amount of traffic between the PPC and the PPS. 707 An example of a flow that uses Rating Groups is given in Appendix A.3 709 2.4. Tariff Switching 711 Tariff is the set of parameters defining the utilization charges for 712 the use of a particular service. 714 This mechanism is useful if, for example, as shown in Figure 7, 715 traffic before 18:00 is rated at rate r1 and traffic after 18:00 is 716 rated at rate r2. The mechanism requires the PPC to report usage 717 before and after the switch occured. 719 18:00 720 ------------------+----------------- 721 r1 | r2 722 ------------------+----------------- 723 ^ ^ 724 |<----TSI---> | 725 | | 726 Access-Accept Access-Request 727 (quota allocated) (quota consumed) 729 Figure 7: Example of Tariff Switching 731 The PPC indicates support for tariff switching by setting the 732 appropriate bit in the PPAC. If the PPS needs to signal a tariff 733 switch time it will send a PTS attribute that indicates the point in 734 time when the switch will occur. This indication represents the 735 number of seconds from current time (TariffSwitchInterval TSI). 737 At some point after the tariff switch the PPC sends another Access- 738 Request, as a result of either the user having logged off or the 739 volume threshold being reached. The PPC reports how much volume was 740 used in total (in a PPAQ attribute) and how much volume was used 741 after the tariff switch (in a PTS VUATS subtype attribute). 743 In situations with multiple tariff switches, the PPS has to specify 744 the length of the tariff switch period using the 745 TimeIntervalAfterTariffSwitchUpdate (TITSU) field in the PTS 746 attribute, as shown in Figure 8. 748 18:00 23:30 749 ------------------+---------------------+-------------- 750 r1 | r2 | r3 751 ------------------+---------------------+-------------- 752 ^ ^ ^ 753 |<----TSI---><-----------|-------->|TITSU 754 | | 755 Access-Accept Access-Request 757 Figure 8: Multiple Tariff Switches 759 When a TITSU is specified in the PTS, the PPC MUST generate an 760 Access-Request within the time after TSI and before TITSU expires. 761 Note that, typically, the PPC will be triggered by the Volume 762 Threshold. However, it is possible that, during period r2, resources 763 are not entirely consumed and, thus, the threshold is not reached. 764 The TITSU attribute ensures that, even in this case, the PPC will 765 generate the new Access-Request in good time. 767 For time based services, the quota is continuously consumed at the 768 regular rate of 60 seconds per minute. At the time when credit 769 resources are allocated, the server already knows how many units will 770 be consumed before the tariff time change and how many units will be 771 consumed afterward. Similarly, the server can determine the units 772 consumed at the before rate and the units consumed at the rate 773 afterward in the event that the end user closes the session before 774 the consumption of the allotted quota. There is no need for 775 additional traffic between the PPC and the PPS in the case of tariff 776 time changes for continuous time based service. Therefore, the 777 tariff change mechanism is not used for such services. For time- 778 based services in which the quota is not continuously consumed at a 779 regular rate, the tariff change mechanism described for volume and 780 event units may be used. 782 2.5. Support for Roaming 784 In certain networks it is essential for prepaid data services to be 785 available to roaming subscribers. Support for both static and 786 dynamic roaming models is needed. In a static roaming scenario the 787 subscriber connects to a foreign network which has a roaming 788 agreement either directly with the home network, or through a broker 789 network. When the subscriber logs into another foreign network, a 790 new login procedure has to be executed. 792 In a dynamic roaming scenario the subscriber may move between 793 networks while maintaining his connection. In such a scenario the 794 data session is seamlessly handed off between the networks. 796 In both roaming scenarios, the subscriber always authenticates 797 himself to the home network. Authorization for the prepaid session 798 and quota replenishing occurs at the home network and more 799 specifically at the PPS where state is being maintained. 801 Roaming is challenging because a subscriber who established a prepaid 802 data session may move to another PPC that does not support the 803 prepaid extensions. 805 2.6. Dynamic Termination 807 When fraud or an error is detected, either only the affected session, 808 or all sessions of the affected subscriber should be immediately 809 terminated. Under certain conditions, the system may wish to 810 terminate the session in order to make sure that the user is not 811 charged for services it does not use. 813 Certain handoff procedures used in dynamic roaming scenarios require 814 that the system terminates the subscribers prepaid data session at a 815 PPC. This is the case, for example, when time-based prepaid is used 816 and the mobile subscriber performs a dormant handoff. 818 2.7. One Time Event 820 2.7.1. One-Time Charging 822 One-time charging is a mode of operation of where the RADIUS prepaid 823 extensions are used for charging of a service that is provided 824 instansteneously. An example of such an event is the purchase of a 825 ring tone. Subscription based services can also be modeled as a one- 826 time event. In this case the one-time service event is the purchase 827 of a subscription. 829 For a given user, one-time charging may occur in parallel with other 830 charging models. For example, the subscriber may be connected to the 831 Internet, which is metered (based on time or volume), while he also 832 purchases a ring tone (a one-time-based event). 834 Note that it is up to the service providers to decide whether or not 835 the user will be charged for the download of, for example, the video 836 and also be charged for the data volume required to download the 837 video. The facilities provided by this document gives the service 838 provider the capability to achieve their service charging business 839 goals. 841 The PPC signals one-time charging to the PPS with an indication that 842 identifies the service and the units that should be debited from the 843 user account. 845 A PPC may decide to perform one-time charging and the PPC may need to 846 authenticate the user before sending the relevant message to the 847 user's home AAA server (and to the PPS). 849 Note that one-time charging can also be used to credit the prepaid 850 account. For example, the PPC can return resources to the subscriber 851 by issuing a one-time charging request that includes the amount of 852 resources to be credited into the account. 854 2.7.2. Service Price Enquiry 856 The PPC may need to know the price of the service event. Services 857 offered by application service providers whose prices are not known 858 in the PPC might exist. The end user might also want to get an 859 estimation of the price of a service event before requesting it. 861 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 862 with the value set to "Price Enquiry" (2). The request includes 863 enough information to identify the service, namely a Service- 864 Identifier or a Rating-Group-Identifer. 866 The PPS calculates the cost of the requested service event, but it 867 does not perform any account balance check or credit reservation from 868 the account. 870 The estimated cost of the requested service event is returned to the 871 PPS with a PPAQ in the Cost-Information SubType. The PPC may 872 transfer the information to the end user as an advice of charge. 874 More information regarding the price enquiry functionality is 875 provided in Section 4.2.17 and in Section 4.2.19. 877 2.7.3. Balance Check 879 The PPC may only have to verify that the end user's account balance 880 covers the cost of a certain service without reserving any units from 881 the account at the time of the inquiry. This method does not 882 guarantee that credit would be left when the PPC requests the 883 debiting of the account with a separate request. 885 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 886 with the value set to "Balance Check" (1). The request includes 887 enough information to identify the service, namely a Service- 888 Identifier or a Rating-Group-Identifer. 890 The PPS makes the balance check, but it does not make any credit- 891 reservation from the account. 893 The result of balance check, namely "Success" (1) or "Failure" (2), 894 is returned to the PPC in the Check-Balance-Result SubType conveyed 895 in the PPAQ attribute from the PPS to the PPC. 897 More information regarding the balance check functionality is 898 provided in Section 4.2.17 and in Section 4.2.18. 900 2.7.4. Refund 902 Some services may refund service units to the end user's account; for 903 example, gaming services. 905 To initiate refunding the PPC includes the PPAQ attribute in an 906 Access-Request packet and the amount (as a negative value) to be 907 refunded is specified using the Resource Quota and Resource Quota 908 overflow subtypes. This functionality is similar to one-time 909 charging with the difference that refunding uses negative values 911 Information about the service need to be provided by the PPC to allow 912 service identification, namely the Service-ID field of the PPAQ 913 identifies the prepaid service. 915 Note that a monetary amount itself to be refunded is not provided but 916 rather abstract units. Based on prior out-of-band agreements between 917 the PPC and the PPS these abstract units are translated into a 918 monetary amount. 920 More information regarding the refund functionality is provided in 921 Section 3.7.6. 923 3. Operations 925 This section contains the normative text for the prepaid extension. 927 3.1. Capability Discovery 929 The PPC initiates the authentication and authorization procedure by 930 sending a RADIUS Access-Request to the HAAA. Since the PPC MUST 931 include a PPAC attribute in the RADIUS Access-Request. The PPAC 932 attribute indicates to the PPS which prepaid capabilities are 933 possessed by the PPC. These are required in order to complete the 934 prepaid authorization procedure. 936 If the authentication procedure involves multiple message exchanges 937 (as it is the case with EAP), the PPC MUST include the PPAC attribute 938 in at least the last Access-Request of the authentication procedure. 940 3.2. Authentication and Authorization Operation 942 Once the Access-Request arrives at the HAAA, the HAAA authenticates 943 the subscriber. If this fails, the HAAA sends an Access-Reject 944 message to the client. If authentication succeeds, the HAAA 945 determines whether or not the subscriber is a prepaid subscriber. If 946 the subscriber is not a prepaid subscriber, then the HAAA responds as 947 usual with an Access-Accept or an Access-Reject message. If the 948 subscriber is a prepaid subscriber then the HAAA MAY forward the 949 Access-Request to the PPS for further authorization. 951 The PPS locates the subscriber account and authorizes him. During 952 this procedure, the PPS takes into consideration the PPCs 953 capabilities. Upon successful authorization, the PPS generates an 954 Access-Accept containing an PPAC attribute and an PPAQ attribute. 955 The PPAC attribute returned to the client indicates the type of 956 prepaid service to be provided for the session. The PPAQ attribute 957 includes the following information. 959 o The QID, which is set by the PPS to a unique value, is used to 960 correlate quota requests. 962 o Volume and/or Time quota, which is set to a value representing a 963 portion of the subscriber's credit. 965 o Time or Volume Threshold that indicates when the PPC should 966 request additional quota. This information is optional. 968 o The IP address of the serving PPS and one or more alternative 969 PPSs. This is used by the HAAA to route subsequent quota 970 replenishing messages to the appropriate PPS(s). 972 o A State attribute, as defined in RFC 2865 [RFC2865]. This is 973 necessary in order to satisfy the requirements of Section 5.44 of 974 RFC 2865 [RFC2865], which mandates that an Access-Request with 975 Service-Type="Authorize-Only" must contain a State attribute. 976 Since the PPC sends subsequent quota replenishment requests in the 977 form of such "Authorize-Only" requests, a State attribute MUST be 978 present in all Access-Accept messages that also carry a PPAQ 979 attribute. 981 Note: The Idle-Timeout(28) attribute can be used to trigger the 982 premature termination of a prepaid service, for example as a result 983 of inactivity. 985 Depending on site policies, after failed authorization, the PPS may 986 generate an Access-Reject in order to terminate the session 987 immediately. Alternatively, the PPS may generate an Access-Accept 988 blocking some or all of the traffic and/or redirect some or all of 989 the traffic to a location to a fixed server. (This feature could be 990 used, for example, to prompt the user to replenish their account.) 991 Blocking of traffic is achieved by either Filter-ID(11) or NAS- 992 Filter-Rule (see [I-D.ietf-radext-filter-rules]). A description of 993 the redirect functionality is outside the scope of this document. 994 The time period before the session is blocked/redirected is specified 995 by the Session-Timeout(27) attribute. 997 Upon receiving an Access-Accept from the PPS, the HAAA appends the 998 usual service attributes and forward the packet to the PPC. The HAAA 999 SHOULD NOT overwrite any attributes already set by the PPS. If the 1000 HAAA receives an Access-Reject message, it will simply forward the 1001 packet to its client. Depending on site policies, if the HAAA does 1002 not receive an Access-Accept or an Access-Reject message from the PPS 1003 it MAY do nothing or send an Access-Reject or an Access- Accept 1004 message back to the PPC. 1006 3.3. Session Start Operation 1008 The start of the session is indicated by the arrival of an 1009 Accounting-Request(Start) packet. The Accounting-Request (Start) MAY 1010 be routed to the PPS such that it can confirm the initial quota 1011 allocation. 1013 Note that the role of the PPS is not to record accounting messages 1014 and therefore it SHOULD NOT respond with an Accounting Response 1015 packet. If the PPS does not receive the Accounting-Request(start) 1016 message it will only know that the session has started upon the first 1017 reception of a quota replenishment operation. 1019 If the PPS does not receive indication directly (via Accounting- 1020 Request(start)) or indirectly, it SHOULD, after some configurable 1021 time, deduce that the session has not started. If the PPC supports 1022 termination capabilities, the PPS SHOULD send a Disconnect Message to 1023 the PPC as a measure to ensure that the session is indeed dead. 1025 3.4. Mid-Session Operation 1027 During the lifetime of a prepaid data session the PPC may request the 1028 replenishment of the quotas using an Authorize-Only Access-Request 1029 message. Once either the allocated quota has been exhausted or the 1030 threshold has been reached, the PPC MUST send an Access-Request with 1031 Service-Type(6) set to a value of "Authorize-Only" and the PPAQ 1032 attribute. 1034 The PPC MUST also include NAS identifiers, and Session Identifier 1035 attributes in the Authorize-Only Access-Request. The Session 1036 Identifier should be the same as the one used during the initial 1037 Access-Request. For example, if the User-Name(1) attribute was used 1038 in the Access-Request it has to be included in the Authorize-Only 1039 Access-Request as well, especially if the User-Name(1) attribute is 1040 used to route the Access-Request to the Home AAA server. 1042 The Authorize-Only Access-Request MUST NOT include a User Password 1043 and MUST NOT include a CHAP Password. In order to enable the 1044 receiver to authenticate the message, the PPC MUST include a Message- 1045 Authenticator(80). In order to satisfy the requirements of Section 1046 5.44 of RFC 2865 [RFC2865], the PPC MUST also include the State 1047 attribute. It is anticipated that the inclusion of the State 1048 attribute will enable the PPS to map the Authorize-Only Access 1049 Request to the authentication context that was established when the 1050 PPC authenticated itself at the beginning of the session. The PPC 1051 computes the value for the Message-Authenticator and the State 1052 attributes according to RFC 2869 [RFC2869] and RFC 2865 [RFC2865] 1053 respectively. 1055 When the HAAA receives an Authorize-Only Access-Request that contains 1056 a PPAQ, it validates the message using the Message-Authenticator(80), 1057 according to RFC 2869. If the HAAA receives an Authorize-Only 1058 Access-Request that contains a PPAQ and either no or an invalid 1059 Message-Authenticator(80) it SHALL silently discard the message. An 1060 Authorize Only Access-Request message that does not contain a PPAQ is 1061 either erroneous or belongs to another application (for example, a 1062 Change of Authorization message [RFC3576]). In this case the 1063 Authorize-Only Access-Request is either silently discarded or handled 1064 by another application. 1066 Once the Authorize-Only Access-Request message is validated, the HAAA 1067 SHALL forward the Authorize-Only Access-Request to the appropriate 1068 PPS. The HAAA MUST forward the Authorize-Only Access-Request to the 1069 PPS specified in the PPAQ. The HAAA MUST add a Message- 1070 Authenticator(80) to the message, according to RFC 2869. As with the 1071 Access-Request message, the HAAA MAY modify the User-Name(1) 1072 attribute such that it identifies the user to the PPS. 1074 When the PPS receives the Authorize-Only Access-Request containing a 1075 PPAQ attribute, it MUST validate the Message-Authenticator(80) as 1076 described in RFC 2869. If validation fails, the PPS MUST silently 1077 discard the message. If it receives an Authorize-Only Access-Request 1078 message that does not contain a PPAQ, it MUST silently discard the 1079 message. 1081 The PPS locates the prepaid session state and uses the QID contained 1082 within the PPAQ to detect replays. The PPS takes the most recently 1083 allocated quota and subtracts it from the user balance. If 1084 sufficient balance remains, the PPS authorizes the PPS and allocates 1085 additional quota. The PPS may also calculate a new threshold value. 1086 Upon successful re-authorization, the PPS generates an Access-Accept 1087 containing the PPAQ attribute. 1089 Depending on site policies, upon unsuccessful authorization, the PPS 1090 generates an Access-Reject or an Access-Accept with Filter-Id(11) or 1091 Ascend-Data-Filter attribute (if supported) and the Session- 1092 Timeout(27) attribute such that the subscriber can get access to a 1093 restricted set of locations for a short period of time. This feature 1094 could be used to enable users to replenish their accounts, create new 1095 accounts, or to access free content. 1097 Upon receiving an Access-Accept from the PPS, the HAAA forwards the 1098 message to its client. If the HAAA receives an Access-Reject 1099 message, it forwards the message. Depending on site policies, if the 1100 HAAA does not receive an Access-Accept or an Access-Reject message 1101 from the PPS it MAY do nothing or it MAY send an Access-Reject 1102 message back to its client. 1104 Upon receiving an Access-Accept, the PPC updates its quotas and 1105 threshold parameters with the values contained in the PPAQ attribute. 1106 Note that the PPS MAY update the PrePaidServer attribute(s) and these 1107 may have to be saved as well. If the Access-Accept message contains 1108 a Filter-Id(11), an Ascend-Data-Filter attribute, or Session 1109 Timeout(27), the PPC SHALL restrict the subscriber session 1110 accordingly. 1112 3.5. Dynamic Operations 1114 The PPS may take advantage of the dynamic capabilities that are 1115 supported by the PPC as advertised in the Dynamic-Capabilities 1116 attribute during the initial Access-Request. There are two types of 1117 actions that the PPS may perform. Firstly, it may request the 1118 session to be terminated. Secondly, it may request the attributes 1119 associated with the session to be modified. More specifically, it 1120 may modify a previously sent PPAQ. 1122 Both of these actions require that the session be uniquely identified 1123 at the PPC as described in [RFC3576]. 1125 3.5.1. Unsolicited Session Termination Operation 1127 At anytime during a session the PPS may send a Disconnect Message in 1128 order to terminate a session, see in [RFC3576]. Upon successful 1129 termination of a session the PPC MUST return any unused quota to the 1130 PPS by issuing an Authorize-Only Access-Request containing the PPAQ 1131 which contains any unused quota and the Update-Reason set to "Remote 1132 Forced Disconnection". 1134 3.5.2. Unsolicited Change of Authorization Operation 1136 At any time during the session the PPC may receive a Change of 1137 Authorization (CoA) message. A PPS may send a new quota to either 1138 add or to remove quota that is allocated to the service. If the 1139 Change of Authorization contains a PPAQ then that PPAQ overrides a 1140 previously received PPAQ. The PPS MUST NOT change the units used in 1141 the PPAQ. 1143 If the newly received PPAQ reduces the amount of allocated quota 1144 beyond what is already used then the PPC accepts the new PPAQ and act 1145 as it normally would when the quota is used up. For example, if the 1146 threshold is reached then is request a quota update. 1148 3.6. Termination Operation 1150 The termination phase is initiated when (i) the subscriber logs off, 1151 (ii) the subscriber balance is exhausted, or (iii) when the PPC 1152 receives a Disconnect Message. 1154 In case the user logged off, or the PPC receives a Disconnect 1155 Message, the PPC sends an Authorize-Only Access-Request message with 1156 a PPAQ and Update-Reason attribute set to either "Client Service 1157 Termination" or "Remote Forced Disconnect". This message indicates 1158 the amount of consumed quota. 1160 In case the currently allocated quota is exhausted, if the PPAQ 1161 contained the Termination-Action subytype, the PPC follows the 1162 specified action. 1164 3.7. Operation Considerations for Multiple Services 1166 This section describes the support for multiple prepaid services on a 1167 single PPC. Message flows illustrating the various interactions are 1168 presented in Appendix A. 1170 A PPC that supports prepaid operations for multi-services SHOULD set 1171 the "Multi-Services Supported" bit in the PPAC. When working with 1172 multi-services, we need to differentiate between the services. A 1173 Service-Id attribute is used in the PPAQ in order to uniquely 1174 differentiate between the services. The exact definition of the 1175 Service-Id attribute is outside the scope of this document. 1177 A PPAQ that contains a Service-Id is associated with that service. A 1178 PPAQ that contains a Rating-Group-Id is associated with that Rating- 1179 Group. A PPAQ MUST NOT contain both a Rating-Group-Id and a 1180 Service-Id. A PPAQ that contains neither a Rating-Group-Id nor a 1181 Service-Id then the default service is used, i.e., the "Access 1182 Service". 1184 3.7.1. Initial Quota Request 1186 When operations with multiple services is desired then the PPC 1187 requests the initial quota by sending a PPAQ containing the 1188 Service-Id in an Authorize-Only Access-Request packet for that 1189 service. Similarly, if the PPC supports rating groups then it may 1190 request a quota for the rating group by sending a PPAQ containing the 1191 Rating-Group-Id. In both cases the Update-Reason is set to "Initial- 1192 Request". The Authorize-Only Access-Request message MAY contain more 1193 than one PPAQ. 1195 Upon receiving an Authorize-Only Access-Accept message containing one 1196 or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ 1197 is assigned a unique QID that MUST appear in subsequent PPAQ updates 1198 for that service or rating group. Additionally, the PPAQ MUST 1199 contain the Service-ID or Rating-Group-Id, unless the PPAQ is the 1200 generic "Access Service". 1202 3.7.2. Quota Update 1204 Once the services start to utilize their allotted quota they will 1205 eventually need to replenish their quotas (either the threshold is 1206 reached or no more quota remains). In order to replenish the quota, 1207 the PPC sends an Authorize-Only Access-Request message containing one 1208 or more PPAQs. Each PPAQ MUST contain the appropriate QID, 1209 Service-ID or Rating-Group-Id (or neither the Service-ID or Rating- 1210 Group-Id if the quota replenishment is for the "Access Service"). 1211 The Update-Reason filed indicates either "Threshold reached"(3), or 1212 "Quota reached"(4). 1214 Upon receiving an Authorize-Only Access-Request packet with one or 1215 more PPAQs the PPS responds with a new PPAQ for that service. The 1216 PPAQ contains a new QID, the Service-Id or the Rating-Group-Id, and a 1217 new QID. If the PPS does not grant additional quota for the service 1218 it MUST include the Termination-Action subfield in the PPAQ that will 1219 instruct the PPC to take appropriate actions. 1221 3.7.3. Termination 1223 When the allotted quota for a service is exhausted, the PPC shall act 1224 in accordance with the flags set in the Termination-Action subtype. 1225 If the Termination-Action subtype is absent then the service MUST be 1226 terminated. If the service is to be terminated, then the PPC shall 1227 send a PPAQ with the appropriate QID, the Service-Id, the used quota, 1228 and the Update-Reason set to "Client Service Termination". 1230 If the "Access Service" has terminated, then all other services must 1231 be terminated as well. In this case the PPC MUST report on all 1232 issued quotas for the various services. The Update-Reason field 1233 should be set to "Access Service Terminated". 1235 3.7.4. Dynamic Operations 1237 Dynamic operations for multi-services are similar to dynamic 1238 operations described for single service operations. The PPS MAY send 1239 a COA message containing a PPAQ for an existing service instance. 1240 The PPC matches the PPAQ with the service using the Service-ID or the 1241 Rating-Group-Id attribute. The new quota could differ from the 1242 previously allocated value. 1244 A disconnect message terminates the "Access Service". As such the 1245 PPC MUST report all unused quotas by sending an Authorize-Only Access 1246 Request message containing a PPAQ for each active service. The 1247 Update-Reason MAY indicate that the reason for the update. 1249 3.7.5. Support for Resource Pools 1251 If the PPC supports pools as indicated by setting the "Pools 1252 supported" bit in the PPAC then the PPS may associate a quota with a 1253 Pool by including the Pool-Id and the Pool-Multiplier in the PPAQ. 1254 When Resource Pools are used, the PPAQ MUST NOT use the threshold 1255 field. 1257 3.7.6. One-time Charging 1259 To initiate one-time charging the PPC includes the PPAQ attribute in 1260 an Access-Request packet. The Service-ID field of the PPAQ 1261 identifies the prepaid service. The amount to be charged is 1262 specified using the Resource Quota and Resource Quota overflow 1263 subtypes. If the value specified is negative then the resources are 1264 credited to the user account. This functionality corresponds to 1265 refunding. 1267 The QID subtype MUST be set to a unique value and is used by the PPS 1268 to detect duplicates. The Update Reason field MUST be set to One- 1269 Time Charging. Upon receiving a One-Time charge PPAQ, the RADIUS 1270 server authenticates the user and, if successful, passes the PPAQ to 1271 the PPS. The PPS locates the account and debits or credits it 1272 accordingly. The PPS MUST respond to the PPS with an Access-Accept 1273 message if successful, or an Access-Reject message otherwise. 1275 In case of a successful operation the HAAA forwards the message to 1276 the PPC with an Access Accept message. Since this is a one-time 1277 charge the PPC MUST NOT allow the session to continue. Therefore, 1278 the RADIUS server SHOULD include in the Access-Accept a Session- 1279 Timeout set to 0. Upon receiving an Access-Accept response the PPC 1280 SHOULD generate an Accounting Stop message. 1282 A PPAQ used for One-Time charging MAY appear in an Authorize-Only 1283 Access Request. This is the case when the session already exists. 1284 The PPS responds with an Access-Accept to indicate that the user 1285 account has been debited or an Access-Reject otherwise. 1287 3.7.7. Error Handling 1289 If the PPS receives a PPAQ with an invalid QID it MUST ignore that 1290 PPAQ. 1292 If the PPS receives a PPAQ containing a Service-Id, or a Rating- 1293 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1295 If the PPC receives a PPAQ containing a Service-Id, or a Rating- 1296 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1298 If the PPC receives a PPAQ that contains a Pool-Id without a Pool- 1299 Multiplier or a Pool-Multiplier without a Pool-Id it MUST ignore that 1300 PPAQ. 1302 3.7.8. Accounting Considerations 1304 Although typically generated, accounting messages are not required to 1305 deliver a prepaid data service. When generated, accounting messages 1306 are used for auditing purposes and for billing. Accounting messages 1307 associated with prepaid data sessions should include the PPAQ 1308 attribute. 1310 4. Attributes 1312 This section specifies the attributes that implement the RADIUS 1313 extensions for prepaid. 1315 4.1. PrePaid Accounting Capability (PPAC) Attribute 1317 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1318 Access-Request message by a PPC to describe its prepaid capabilities. 1320 0 1 2 3 1321 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 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | TYPE | LENGTH | SubType (1) | LENGTH | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | AvailableInClient (AiC) | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | AvailableInClient-Extended (AiC-ext) | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 TYPE : IANA registered value of PPAC attribute 1331 LENGTH: 8 1332 VALUE : Data type String 1334 The value field is encoded as follows: 1336 SubType : Value (1) 1337 Length : 6 or 10 octets 1339 AvailableInClient (AiC): The bitmap is encoded as: 1341 Value | Description 1342 -------------+------------------------------------- 1343 00000001 | Volume metering supported 1344 00000010 | Duration metering supported 1345 00000100 | Resource metering supported 1346 00001000 | Pools supported 1347 00010000 | Rating groups supported 1348 00100000 | Multi-Services supported 1349 01000000 | Tariff Switch supported 1350 10000000 | Extended AiC field 1352 If the Extended AiC flag is not set then the length 1353 of this SubType is 6 octets. If the Extended AiC flag 1354 is, however, set then the length of this SubType is 1355 10 octects long and the subsequent 4 octects are 1356 available as shown below: 1358 AvailableInClient-Extended (AiC-ext): 1360 The bitmap is encoded as: 1362 Value | Description 1363 -------------+------------------------------------- 1364 00000001 | **Available via IANA registration** 1365 00000010 | **Available via IANA registration** 1366 00000100 | **Available via IANA registration** 1367 00001000 | **Available via IANA registration** 1368 00010000 | **Available via IANA registration** 1369 00100000 | **Available via IANA registration** 1370 01000000 | **Available via IANA registration** 1371 10000000 | **Available via IANA registration** 1373 Figure 9: PPAC Attribute 1375 4.2. Prepaid Accounting Operation (PPAQ) Attribute 1377 One or more PPAQ attributes are sent in an Access Request, Authorize- 1378 Only Access-Request and Access-Accept message. In an Access Request 1379 message, the PPAQ attribute is used to facilitate one-time charging 1380 transactions. In Authorize-Only Access-Request messages it is used 1381 for one-time charging, report usage and to request further quota. It 1382 is also used in order to request prepaid quota for a new service 1383 instance. In an Access-Accept message it is used in order to 1384 allocate the (initial and subsequent) quotas. 1386 When multiple services are supported, a PPAQ is associated with a 1387 specific service as indicated by the presence of a Service-Id, a 1388 Rating-Group-Id, or the "Access Service" (as indicated by the absence 1389 of both, the Service-Id and the Rating-Group-Id). 1391 Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes MUST 1392 appear in the PPAQ attribute, except for the price enquiry message 1393 exchange where these subtypes MUST be absent. A single PPAQ 1394 attribute MUST NOT contain more than one Service-Id, MUST NOT contain 1395 more than one Rating-Group-Id, and MUST NOT contain both a Service-Id 1396 and a Rating-Group-Id. A PPAQ that does not contain a Service-ID or 1397 a Rating-Group-Id refers to the "Access Service". A PPAQ MUST NOT 1398 contain more than one Pool-Id. A PPAQ that contains a Pool-Id MUST 1399 also contain a Pool-Multiplier SubType. 1401 The PPAQ attribute, as shown in Figure 10, has a variable length 1402 (greater than 8, encoded into one octet), and consists of a variable 1403 number of subtypes. Unused subtypes are omitted from the message. 1404 In the following subsections the various subtypes of the PPAQ 1405 attribute are specified. 1407 0 1 2 3 1408 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 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | TYPE | LENGTH | VALUE ... 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 ... VALUE | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 TYPE : value of PPAQ 1416 LENGTH: variable 1417 VALUE : Data type String 1419 Each subattribute is then encoding in the following style: 1421 0 1 2 3 1422 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 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | SubType | LENGTH | VALUE ... 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 Figure 10: PPAQ Attribute 1429 4.2.1. Quota Identifier (QID) SubType 1431 The value of the type field of the Quota Identifier (QID) SubType is 1432 TBD. The length of this SubType is 6 octets. Its value is encoded 1433 as a string. It is generated by the PPS and subsequently returned in 1434 a PPAQ->QID subtype from the PPC to the PPS. This field has the 1435 semantic of a transaction identifier and therefore changes with every 1436 transaction initiated by the PPS to the PPC. 1438 4.2.2. VolumeQuota SubType 1440 The value of the type field of the VolumeQuota SubType is TBD. The 1441 length of this SubType is 12 or 18 octets. It is only present if 1442 volume-based charging is used. In a RADIUS Access-Accept message 1443 (PPS to PPC direction), it indicates the volume (in octets) allocated 1444 for the session by the PPS. In an RADIUS Authorize-Only Access- 1445 Request message (PPC to PPS direction), it indicates the total used 1446 volume (in octets) for both inbound and outbound traffic. The 1447 attribute consists of a Value-Digits SubType and optionally an 1448 Exponent SubType (as indicated in the length field). The Exponent 1449 SubType, if present, MUST NOT encode a negative number or zero. 1451 4.2.3. VolumeThreshold SubType 1453 The value of the type field of the VolumeThreshold SubType is TBD and 1454 its length is 12 or 18 octets. This SubType is optionally present if 1455 VolumeQuota is present in a RADIUS Access-Accept message (PPS to PPC 1456 direction). It is generated by the PPS and indicates the volume (in 1457 octets) that has to be consumed before a new quota is requested. 1458 This threshold MUST NOT be larger than the VolumeQuota. The 1459 attribute consists of a Value-Digits SubType and optionally an 1460 Exponent SubType (as indicated by the length field). The Exponent 1461 SubType, if present, MUST NOT encode a negative number or zero. 1463 4.2.4. DurationQuota SubType 1465 The value of the type field of the DurationQuota SubType is TBD and 1466 its length is 6 octets. This optional SubType is only present if 1467 duration-based charging is used. In a RADIUS Access-Accept message 1468 (PPS to PPC direction), it indicates the duration (in seconds) 1469 allocated for the session by the PPS. It is encoded as an integer. 1470 In a RADIUS Access-Request message (PPC to PPS direction), it 1471 indicates the total duration (in seconds) since the start of the 1472 accounting session related to the QID subtype of the PPAQ attribute 1473 in which it occurs. 1475 4.2.5. DurationThreshold SubType 1477 The value of the type field of the DurationThreshold SubType is TBD 1478 and its length is 6 octets. This SubType shall optionally be present 1479 if the DurationQuota is present in a RADIUS Access-Accept message 1480 (PPS to PPC direction). It represents the duration (in seconds) 1481 after which new quota should be requested. This threshold MUST NOT 1482 be larger than the DurationQuota SubType. It is encoded as an 1483 integer. 1485 4.2.6. ResourceQuota SubType 1487 The value of the type field of the ResourceQuota SubType is TBD. The 1488 length of this SubType is 12 or 18 octets. This optional SubType is 1489 only present if resource-based or one-time charging is used. In the 1490 RADIUS Access-Accept message (PPS to PPC direction) it indicates the 1491 resources allocated for the session by the PPS. In RADIUS Authorize- 1492 Only Access-Request message (PPC to PPS direction), it indicates the 1493 resources used in total, including both incoming and outgoing 1494 chargeable traffic. In one-time charging scenarios, the subtype 1495 represents the number of units to charge or credit the user. The 1496 attribute consists of a Value-Digits SubType and optionally an 1497 Exponent SubType (as indicated by the length field). 1499 4.2.7. ResourceThreshold SubType 1501 The value of the type field of the ResourceThreshold SubType is TBD. 1502 The length of this SubType is 12 or 18 octets. The semantics of this 1503 SubType follow those of the VolumeThreshold and DurationThreshold 1504 SubType. It consists of a Value-Digits SubType and optionally an 1505 Exponent SubType. 1507 4.2.8. Value-Digits SubType 1509 The value of the type field of the Value-Digits SubType is TBD and 1510 its length is 10 octets. This SubType encodes the most significant 1511 digits of a number, encoded as an integer. If decimal values are 1512 needed to present the number, the scaling MUST be indicated with a 1513 related Exponent SubType. For example, the decimal number 0.05 is 1514 encoded by a Value-Digits SubType set to 5, and a scaling that is 1515 indicated with the Exponent SubType set to -2. 1517 4.2.9. Exponent SubType 1519 The value of the type field of the Exponent SubType is TBD. The 1520 length of this SubType is 6 octets. This SubType contains the 1521 exponent value that is to be applied to the accompanying Value-Digit 1522 SubType. Its value is encoded as an integer. 1524 4.2.10. Update-Reason SubType 1526 The value of the type field of the Update-Reason SubType is TBD. The 1527 length of this SubType is 4 octets. This SubType is present in a 1528 RADIUS Access-Request message (PPC to PPS direction) and indicates 1529 the reason for initiating the quota update operation. Update reasons 1530 (6), (7), (8) and (9) indicate that the associated resources are 1531 released at the PPC side, and that therefore the PPS MUST NOT 1532 allocate a new quota in the RADIUS Access Accept message. 1534 The following values for the Update-Reason SubType are defined: 1536 Value | Description 1537 -------------+-------------------------------------- 1538 0 | Reserved 1539 1 | Pre-initialization 1540 2 | Initial Request 1541 3 | Threshold Reached 1542 4 | Quota Reached 1543 5 | TITSU Approaching 1544 6 | Remote Forced Disconnect 1545 7 | Client Service Termination 1546 8 | "Access Service" Terminated 1547 9 | Service not established 1548 10 | One-Time Charging 1549 11..255 | **Available for IANA registration** 1551 Figure 11: Values for Update-Reason SubType 1553 4.2.11. PrepaidServer SubType 1555 The value of the type field of the PrepaidServer SubType is TBD. The 1556 length of this SubType is 6 or 18 octets, for IPv4 and IPv6 addresses 1557 respectively. This optional SubType indicates the address of the 1558 serving PPS. If present, the Home RADIUS server uses this address to 1559 route the message to the serving PPS. Multiple instances of this 1560 subtype MAY be present in a single PPAQ attribute. The value of this 1561 SubType is encoded as an address. 1563 If present in the PrepaidServer SubType of an incoming RADIUS Access- 1564 Accept message, the PPC returns this SubType back without modifying 1565 it in the subsequent RADIUS Access-Request message. If multiple 1566 values are present, the PPC MUST NOT change their order. 1568 4.2.12. Service-ID SubType 1570 The value of the type and length fields of the Service-ID SubType are 1571 TBD. The value field of this SubType is encoded as a string. This 1572 value is handled as an opaque string that uniquely describes the 1573 service instance to which prepaid metering should be applied. 1575 A Service-Id could be an IP 5-tuple (source address, source port, 1576 destination address, destination port, protocol). If a Service-ID 1577 SubType is present in the PPAQ, the entire PPAQ attribute refers to 1578 that service. If a PPAQ attribute does not contain a Service-Id or 1579 Rating-Group-ID, then the PPAQ attribute refers to the "Access 1580 Service". 1582 4.2.13. Rating-Group-ID SubType 1584 The value of the type field of the Rating-Group-ID SubType is TBD. 1585 The length of this SubType is 6 octets. This SubType indicates that 1586 this PPAQ attribute is associated with resources allocated to a 1587 Rating Group with the corresponding ID. This SubType is encoded as a 1588 string. A single PPAQ MUST NOT contain more than one 1589 Rating-Group-ID. 1591 4.2.14. Termination-Action SubType 1593 The value of the type field of the Termination-Action SubType is TBD. 1594 The length of this SubType is 3 octets. This SubType contains an 1595 enumeration of the action to take when the PPS does not grant 1596 additional quota. Valid actions are as follows. 1598 The following values for the Termination-Action SubType are defined: 1600 Value | Description 1601 -------------+------------------------------------ 1602 0 | Reserved 1603 1 | Terminate 1604 2 | Request More Quota 1605 3 | Redirect/Filter 1606 4..255 | **Available for IANA registration** 1608 Figure 12: Values for the Termination-Action SubType 1610 4.2.15. Pool-ID SubType 1612 The value of the type field of the Pool-ID SubType is TBD. The 1613 length of this SubType is 6 octets and it identifies the resource 1614 pool. It is encoded as a string. 1616 4.2.16. Pool-Multiplier SubType 1618 The value of the type field of the Pool-Multiplier SubType is TBD. 1619 The length of this SubType is 12 or 18 octets. The pool multiplier 1620 determines the weight that resources are inserted into the pool that 1621 is identified by the accompanying Pool-ID SubType, and the rate at 1622 which resources are taken out of the pool by the relevant Service or 1623 Rating-Group. The SubType consists of a Value-Digits SubType and 1624 optionally an Exponent SubType (as indicated by the length field). 1626 4.2.17. Requested-Action SubType 1628 The value of the type field of the Requested-Action SubType is TBD. 1629 The length of this SubType is 3 octets and it is only be present in 1630 messages sent from the PPC to the PPS. It indicates that the PPC 1631 desires the PPS to perform the indicated action and to return the 1632 result. The PPAQ in which a Requested-Action SubType occurs MUST NOT 1633 contain a QID, and MUST contain a Service-Identifier or a Rating- 1634 Group-Identifer that allows the PPS to uniquely identify the service 1635 for which the indicated action is requested. 1637 The following values for the Requested-Action SubType are defined: 1639 Value | Description 1640 -------------+------------------------------------- 1641 0 | Reserved 1642 1 | Balance Check 1643 2 | Price Enquiry 1644 3..255 | **Available for IANA registration** 1646 Figure 13: Values for the Requested-Action SubType 1648 4.2.18. Check-Balance-Result SubType 1650 The value of the type field of the Check-Balance-Result SubType is 1651 TBD. The length of this SubType is 3 octets. This SubType can only 1652 be present in messages sent from the PPS to the PPC. It indicates 1653 the balance check decision of the PPS about a previously received 1654 Balance Check Request (as indicated in a Requested-Action SubType). 1655 The PPAQ attribute in which a Check-Balance-Result occurs MUST NOT 1656 include a QID. 1658 The following values for the Check-Balance-Result SubType are 1659 defined: 1661 Value | Description 1662 -------------+------------------------------------------- 1663 0 | Success; Sufficient funds available 1664 | in the user's prepaid account 1665 1 | Failure; Insufficient funds available 1666 2..255 | **Available for IANA registration** 1668 Figure 14: Values for the Check-Balance-Result SubType 1670 4.2.19. Cost-Information SubType 1672 The value of the type field of the Cost-Information SubType is TBD. 1673 The length of this SubType is variable. This SubType is used in 1674 order to return the cost information of a service, which the PPC can 1675 transfer transparently to the end user. This SubType is sent from 1676 the PPS to the PPC as a response to a "Price Enquiry", as indicated 1677 by the Requested-Action SubType. This SubType consists of four 1678 further SubTypes, as follows: 1680 Value-Digits SubType: 1682 The Value-Digits SubType encodes the most significant digits of 1683 the monetery value that represents the cost in question. 1685 Exponent SubType: 1687 The Exponent SubType encodes the exponent that applies to the 1688 Value-Digits SubType. 1690 Currency-Code SubType: 1692 the value of the type field of this SubType is TBD. The length of 1693 this SubType is 4 octets. It encodes the currency code, as 1694 defined in the ISO 4217 standard. 1696 Cost-Unit SubType: 1698 the value of the type field of this SubType is TBD. The length of 1699 this SubType is variable. It carries a UTF8String encoded human 1700 readable string that can be displayed to the end user. It 1701 specifies the applicable unit to the Cost-Information when the 1702 service cost is a cost per unit (e.g., cost of the service is $1 1703 per minute). The Cost-Unit can be minutes, hours, days, 1704 kilobytes, megabytes, etc. 1706 For example, the cost of 7.75 Malawi kwacha per hour would be encoded 1707 as follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, 1708 and Cost-Unit = "hour". 1710 The PPAQ that carries a Cost-Information MUST NOT include a QID. 1712 4.3. Prepaid Tariff Switching (PTS) Attribute 1714 This specification defines the PTS attribute, which allows to switch 1715 from one rate to another during service provision. Support for 1716 tariff switching is optional to implement and to use for the PPC and 1717 the PPS. PPCs use the flag "Tariff Switching supported" in the 1718 AvailableInClient field of the PPAC attribute in order to indicate 1719 support for tariff switching. PPSs employ the PTS attribute in order 1720 to announce their support for tariff switching. 1722 If a RADIUS message contains a PTS attribute, it MUST also contain at 1723 least one PPAQ attribute. If a RADIUS Access-Request message 1724 contains a PTS attribute or the "Tariff Switching supported" flag in 1725 the AvailableInClient field of the PPAC attribute, it MUST also 1726 contain an Event-Timestamp RADIUS attribute (see [RFC2869]). 1728 Every PTS attribute MUST include a QID SubType, as specified in 1729 Section 4.2.1. In a RADIUS Access-Request message sent from the PPC 1730 to the PPS, the QID SubType MUST contain the value of the Quota 1731 Identifier SubType that was previously received from the PPS and MUST 1732 be the same as the value carried in the QID SubType of one of the 1733 PPAQ attributes included the same RADIUS message. 1735 If multiple services are supported and if the PPAQ is associated with 1736 a service as indicated by the Service-ID SubType, then the PTS refers 1737 to the tariff switch for that service. If the PPAQ does not have a 1738 Service-ID, then the PTS refers to tariff switch for the "Access 1739 Service". 1741 A PPAQ attribute that is transported along with a PTS attribute and 1742 has the same value as the QID SubType contained in the PTS attribute 1743 in its own QID SubType is referred to as the "accompanying PPAQ 1744 attribute". If a PPS receives an Access-Request message from a PPC, 1745 it associates a unique value for the QID SubType to this request. 1747 The PTS attribute, as shown in Figure 15, contains a number of other 1748 subtypes which are specified in the following subsections. 1750 0 1 2 3 1751 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 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | TYPE | LENGTH | VALUE ... 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 ... VALUE | 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 TYPE : value of PTS 1759 LENGTH: variable 1760 VALUE : Variable length content of data type String 1762 Each SubType is then encoding in the following style: 1764 0 1 2 3 1765 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 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 | SubType | LENGTH | VALUE ... 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 Figure 15: PTS Attribute 1772 4.3.1. VolumeUsedAfterTariffSwitch SubType 1774 The value of the type field of the VolumeUsedAfterTariffSwitch 1775 (VUATS) SubType is TBD. The length of this SubType is 12 or 18 1776 octets. The VolumeUsedAfterTariffSwitch subtype SHOULD be used in 1777 the RADIUS Access-Request messages (PPC to PPS direction). It 1778 indicates the volume (in octets) used during a session after the last 1779 tariff switch for the service specified via the QID SubType and the 1780 accompanying PPAQ attribute. The attribute consists of a Value- 1781 Digits SubType and optionally an Exponent SubType (as indicated in 1782 the length field). 1784 4.3.2. TariffSwitchInterval SubType 1786 The type of the TariffSwitchInterval (TSI) SubType is TBD and its 1787 length 6 octets. This SubType MUST be present in each PTS attribute 1788 that is part of a RADIUS Access-Accept message (PPS to PPC 1789 direction). It indicates the interval (in seconds) between the value 1790 of Event-Timestamp RADIUS attribute (see [RFC2869]) of the 1791 corresponding RADIUS Access-Request message and the next tariff 1792 switch condition. 1794 4.3.3. TimeIntervalafterTariffSwitchUpdate SubType 1796 The value of the type field of the 1797 TimeIntervalafterTariffSwitchUpdate (TITSU) SubType is TBD. The 1798 length of this SubType is 6 octets. The PPS MUST include this 1799 SubType if there is another tariff switch period after the period 1800 that ends as indicated by the TSI SubType. The value of the TITSU 1801 SubType in encoded as an integer, and contains the number of seconds 1802 of the tariff period that begins immediately after the period that 1803 ends as indicated by the TSI attribute. If the TITSU SubType is not 1804 present, the PPC assumes that the tariff period which ends as 1805 indicated by the TSI SubType lasts until further notice. If TITSU is 1806 specified, the PPC MUST send a quota update before the point in time 1807 specified by the TITSU SubType (see Figure 8). 1809 5. Diameter RADIUS Interoperability 1811 The RADIUS prepaid extensions need to interoperate with the Diameter 1812 protocol. Two interoperability scenarios exist, as follows. Either 1813 the AAA infrastructure is Diameter based and the PPC are RADIUS 1814 based, or the PPC is Diameter based and the AAA infrastructure is 1815 RADIUS based. 1817 The Diameter Credit Control Application [RFC4006] describes how to 1818 implement a prepaid accounting system using a Diameter based 1819 infrastructure. 1821 The translation functionality between a Diameter Credit Control and a 1822 RADIUS prepaid protocol interaction is described in Appendix B. 1824 6. Security Considerations 1826 The extended RADIUS protocol described in this document is subject to 1827 a number of potential attacks, in a manner similar to the RADIUS 1828 protocol without these extensions. It is recommended that IPsec be 1829 employed to protect against certain of the attacks. 1831 [Editor's Note: This section is freaking short. We should add 1832 something here.] 1834 7. Table of Attributes 1836 The following table provides a guide which attributes may be found in 1837 which RADIUS messages, and in what quantity. 1839 Request Accept Reject Challenge Accounting # Attribute 1840 Request 1841 0-1 0 0 0 0 TBD PPAC 1842 0+ 0+ 0 0 0+ TBD PPAQ 1843 0+ 0+ 0 0 0+ TBD PTS 1845 8. IANA Considerations 1847 This document contains a number of instructions to IANA. 1849 8.1. New RADIUS Attributes 1851 This document requires the assignment of new RADIUS attributes type 1852 numbers for the following attributes: 1854 Attribute Name | Attribute Type Value 1855 --------------------------------------+----------------------------- 1856 Prepaid-Accounting-Capability (PPAC) | TBD 1857 Prepaid-Accounting-Operation (PPAQ) | TBD 1858 Prepaid Tariff Switching (PTS) | TBD 1860 8.2. New Registry: Prepaid SubTypes 1862 Section 4 defines the SubTypes used within newly defined attributes. 1863 IANA is asked to create a registry for these SubTypes. Each registry 1864 entry consists of a 8 bit number together with a description of the 1865 SubType. This document creates the following SubTypes for this 1866 registry: 1868 Value | SubType Name 1869 ---------+----------------------------- 1870 0 | Reserved 1871 1 | AvailableInClient 1872 2 | Quota Identifier 1873 3 | VolumeQuota 1874 4 | VolumeThreshold 1875 5 | DurationQuota 1876 6 | DurationThreshold 1877 7 | ResourceQuota 1878 8 | ResourceThreshold 1879 9 | Value-Digits 1880 10 | Exponent 1881 11 | Update-Reason 1882 12 | PrepaidServer 1883 13 | Service-ID 1884 14 | Rating-Group-ID 1885 15 | Termination-Action 1886 16 | Pool-ID 1887 17 | Pool-Multiplier 1888 18 | Requested-Action 1889 19 | Check-Balance-Result 1890 20 | Cost-Information 1891 21 | Currency-Code 1892 22 | Cost-Unit SubType 1893 23 | VolumeUsedAfterTariffSwitch 1894 24 | TariffSwitchInterval 1895 25 | TimeIntervalafterTariffSwitchUpdate 1896 26..255 | **Available for IANA registration** 1898 The semantic of the above-listed SubTypes is described in Section 4. 1900 Following the policies outline in [RFC3575] the available SubTypes 1901 (i.e., value 0 and values 26-255) with a description of their 1902 semantic will be assigned after Expert Review initiated by the O&M 1903 Area Directors in consultation with the RADEXT working group chairs 1904 or the working group chairs of a designated successor working group. 1905 Updates can be provided based on expert approval only. A designated 1906 expert will be appointed by the O&M Area Directors. No mechanism to 1907 mark entries as "deprecated", or to delete entries from the registry 1908 is envisioned. 1910 Each registration must include a number for the SubType and the 1911 semantic of the SubType. 1913 8.3. New Registry: Update-Reason 1915 Section 4.2.10 defines the Update-Reason SubType. IANA is asked to 1916 create a registry for the values contained in the Update-Reason 1917 SubType, as shown in Figure 11. Each registry entry consists of a 8 1918 bit number together with a description of the update reason. 1920 Following the policies outline in [RFC3575] the available values 1921 together with a description of their semantic will be assigned after 1922 Expert Review initiated by the O&M Area Directors in consultation 1923 with the RADEXT working group chairs or the working group chairs of a 1924 designated successor working group. Updates can be provided based on 1925 expert approval only. A designated expert will be appointed by the 1926 O&M Area Directors. No mechanism to mark entries as "deprecated", or 1927 to delete entries from the registry is envisioned. 1929 8.4. New Registry: Termination-Action 1931 Section 4.2.14 defines the Termination-Action SubType. IANA is asked 1932 to create a registry for the values contained in the Termination- 1933 Action SubType, as shown in Figure 12. Each registry entry consists 1934 of a 8 bit number together with a description of the termination 1935 action. 1937 Following the policies outline in [RFC3575] the available values 1938 together with a description of their semantic will be assigned after 1939 Expert Review initiated by the O&M Area Directors in consultation 1940 with the RADEXT working group chairs or the working group chairs of a 1941 designated successor working group. Updates can be provided based on 1942 expert approval only. A designated expert will be appointed by the 1943 O&M Area Directors. No mechanism to mark entries as "deprecated", or 1944 to delete entries from the registry is envisioned. 1946 8.5. New Registry: Requested-Action 1948 Section 4.2.17 defines the Requested-Action SubType. IANA is asked 1949 to create a registry for the values contained in the Requested-Action 1950 SubType, as shown in Figure 13. Each registry entry consists of a 8 1951 bit number together with a description of the requested reason. 1953 Following the policies outline in [RFC3575] the available values 1954 together with a description of their semantic will be assigned after 1955 Expert Review initiated by the O&M Area Directors in consultation 1956 with the RADEXT working group chairs or the working group chairs of a 1957 designated successor working group. Updates can be provided based on 1958 expert approval only. A designated expert will be appointed by the 1959 O&M Area Directors. No mechanism to mark entries as "deprecated", or 1960 to delete entries from the registry is envisioned. 1962 8.6. New Registry: Check-Balance-Result 1964 Section 4.2.18 defines the Check-Balance-Result SubType. IANA is 1965 asked to create a registry for the values contained in the Check- 1966 Balance-Result SubType, as shown in Figure 14. Each registry entry 1967 consists of a 8 bit number together with a description of the 1968 requested reason. 1970 Following the policies outline in [RFC3575] the available values 1971 together with a description of their semantic will be assigned after 1972 Expert Review initiated by the O&M Area Directors in consultation 1973 with the RADEXT working group chairs or the working group chairs of a 1974 designated successor working group. Updates can be provided based on 1975 expert approval only. A designated expert will be appointed by the 1976 O&M Area Directors. No mechanism to mark entries as "deprecated", or 1977 to delete entries from the registry is envisioned. 1979 8.7. New Registry: AvailableInClient-Extended 1981 Section 4.2.18 defines the PrePaid Accounting Capability (PPAC) 1982 attribute with the AvailableInClient-Extended field. IANA is asked 1983 to create a registry for the values contained in the 1984 AvailableInClient-Extended field, as shown in Section 4.1. Each 1985 registry entry consists of a 8 bit number together with a description 1986 of the capability. Note that this is a bitmask and only 8 values are 1987 available for registration via IANA. 1989 Following the policies outline in [RFC3575] the available values 1990 together with a description of their semantic will be assigned after 1991 Expert Review initiated by the O&M Area Directors in consultation 1992 with the RADEXT working group chairs or the working group chairs of a 1993 designated successor working group. Updates can be provided based on 1994 expert approval only. A designated expert will be appointed by the 1995 O&M Area Directors. No mechanism to mark entries as "deprecated", or 1996 to delete entries from the registry is envisioned. 1998 9. Acknowledgements 2000 The authors would like to thank Christian Guenther, Bernard Aboba, 2001 and John Loughney for their feedback throughout the development of 2002 this document. 2004 10. References 2006 10.1. Normative References 2008 [RFC2119] Bradner, S., "RFC 2119: Key words for use in RFCs to 2009 Indicate Requirement Levels", March 1997. 2011 [RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2012 2865: Remote Authentication Dial In User Server (RADIUS)", 2013 June 2000. 2015 10.2. Informative References 2017 [I-D.ietf-radext-filter-rules] 2018 Congdon, P., "RADIUS Attributes for Filtering and 2019 Redirection", draft-ietf-radext-filter-rules-03 (work in 2020 progress), July 2007. 2022 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 2023 Authentication Protocol (EAP)", RFC 2284, March 1998. 2025 [RFC2866] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. 2027 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS 2028 Extensions", June 2000. 2030 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 2031 Authentication Dial In User Service)", RFC 3575, 2032 July 2003. 2034 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 2035 Adoba, "RFC 3576: Dynamic Authorization Extensions to 2036 Remote Authentication Dial-In User Service (RADIUS)", 2037 February 2003. 2039 [RFC3748] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2040 Levkowetz, "RFC 3748: Extensible Authentication Protocol", 2041 June 2004. 2043 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 2044 Loughney, "RFC 4006: Diameter Credit Control Application", 2045 August 2005. 2047 Appendix A. Example flows 2049 This section presents certain example flows that involve the RADIUS 2050 prepaid extensions. By no means is the intent of this section to 2051 specify or recommend business logic, rating strategies, and 2052 application-level behaviour. The intent of this section is purely to 2053 illustrate some fictive scenarios and the RADIUS prepaid message 2054 flows that could be associated with these scenarios. The contents of 2055 this section should be regarded as a collection of informative 2056 examples that aim to provide guidance to implementors. 2058 A.1. A simple flow 2060 End user PPC PPS 2062 user logs on 2063 ------(1)---------> 2064 Access Request 2065 {RADIUS BASE AVPS, 2066 PPAC=00...00011} 2067 -------(2)--------> 2069 [allocates 2070 5MB quota] 2072 Access Accept 2073 {RADIUS BASE AVPS, 2074 PPAQ={QID=5, VQ = 5MB, 2075 VTH = 4.5 MB}} 2076 <-------(3)-------- 2078 service provision/metering 2079 -------(4)---------> 2081 4.5 MB consumed 2083 Access Request 2084 {RADIUS BASE AVPS, 2085 PPAQ={QID=5, VQ=4.5MB, 2086 REASON=THRESHOLD REACHED}} 2087 -------(5)---------> 2089 [allocates another 7MB 2090 to the access service] 2092 Access Accept 2093 {RADIUS BASE AVPS, 2094 PPAQ={QID=8, VQ=12MB, 2095 VTH = 11.5 MB}} 2096 <----------(6)-------------- 2097 user logs off 2098 ------(7)------- 2099 Access Request 2100 {RADIUS BASE AVPS, 2101 PPAQ={QID=8, VQ=7 MB, 2102 REASON=ACCESS SERV TERMINATED}} 2103 -------(8)---------> 2105 [reimburses 2106 user account] 2108 AA Accept 2109 {RADIUS BASE AVPS} 2110 <-------(9)-------- 2112 Figure 19: A simple example message flow 2114 The user logs on (1). The PPC sends a RADIUS Access Request message 2115 to the PPS (2), and includes the prepaid-specific PPAC AVP. This AVP 2116 indicates that both duration-based and volume-based metering is 2117 supported. However, it also indicated that multiple services, rating 2118 groups and resource pools are not supported. Note that, since this 2119 is not an "Authorize-Only" message, no PPAQ attribute with Update 2120 Reason="initial request" is included (see Section 3.7.1). The PPS 2121 then authenticates the user and authorizes the access service, as is 2122 usual in RADIUS. Note that the PPAC AVP is appended by the PPC in at 2123 least the last message that is sent to the home AAA server during 2124 this possibly multiple-round exchange. 2126 If authentication and authorization is successful (in this example 2127 this is assumed), then the PPS identifies the user's prepaid account 2128 from the included base RADIUS AVPs, and determines the capabilities 2129 of the PPC from the PPAC attribute. Assuming that sufficient funds 2130 are available in the user's prepaid account, the PPS reserves some of 2131 these and rates the service. In this example, the PPS reserves, say, 2132 2 Euros and determines that the access service is rated at 0.4 Euro 2133 per MB. This results in 5 MB of quota being granted. The PPS also 2134 determines that the PPC should ask for this quota to be replenished 2135 once 4.5 MB have been consumed. Thus, it creates an Access Accept 2136 message with a Volume-Threshold indication of 4.5MB. It further 2137 associates the QID=5 to this reservation. This identifier can be 2138 used to later uniquely identify the prepaid session, user, account, 2139 etc. The resulting Access Accept message is sent to the PPC (3). 2141 Upon reception of message (4), the PPC provides the access service to 2142 the user and meters it accordingly. At some point in time, the 2143 threshold is reached, i.e., 4.5MB of "access service" have been 2144 consumed by the user. At that point, the PPC generates an Authorize- 2145 Only Access Request that contains the usual RADIUS attributes and a 2146 PPAQ attributes that reports the amount of consumed quota, and the 2147 request for replenishment, i.e., the Update-Reason= THRESHOLD REACHED 2148 (5). Note that the QID in this message is the same as the one 2149 previously received from the PPS. 2151 Upon reception of message (5), the PPS identifies the user and his 2152 account from the QID. In also determines that a prepaid session is 2153 ongoing, and that enough credit remains in the prepaid account in 2154 order for the access service to continue being provided. Since 4.5 2155 MB have been consumed, the PPS subtracts 1.8 Euros from the user's 2156 prepaid account. The PPS decides to reserve another 2.8 euros from 2157 the user's account. (This results in 3 euros being reserved in total 2158 at this point in time.) As the access service is rated at 0.4 euros 2159 per MB, the PPS determines that another 7 MB of quota should be 2160 granted. This results in a total cumulative quota allocation of 12 2161 MB for the access service. The PPS further calculates the new 2162 threshold value of 11.5 MB. Since this is a new quota reservation, 2163 the PPS also allocates a new QID to it, in this example QID=8. The 2164 resulting RADIUS message is sent to the PPC (6). 2166 Upon reception of message (6), the PPC updates its records and 2167 continues provisioning access to the user. At some point the user 2168 logs off (7). The PPC must then report how many resources were 2169 consumed, so that the PPC can subtract the appropriate monetary 2170 amount from the user's prepaid account. To this end the PPC 2171 constructs an Authorize-Only Access Request message with a PPAQ 2172 attributes for the access service. In this example, 7 MB were 2173 consumed by the access service in total. The PPC reports 7 MB its 2174 final message (8). The PPS correlates the report, using the QID, to 2175 the previous session state. It determines, from the previous 2176 records, that the access service had consumed another 4.5 MB before 2177 (as indicated in message (6)). This means that, of the 7 MB, only 2178 3.5 MB have not yet been subtracted from the user's account. Thus, 2179 the PPS subtracts another 1.4 euros from the user's account and, 2180 since the session is to be terminated (REASON=ACCESS SERVICE 2181 TERMINATED), releases any reserved monetary amount. 2183 The PPS responds with an Access Response as required by the RADIUS 2184 base specification (9). 2186 A.2. A flow with prepaid tariff switching 2188 End user PPC PPS 2189 user logs on 2190 ------(1)---------> 2191 Access Request 2192 {RADIUS BASE AVPS, 2193 PPAC=00...00111} 2194 -------(2)--------> 2196 [allocates 2197 20MB quota] 2199 Access Accept 2200 {RADIUS BASE AVPS, 2201 PPAQ={QID=5, VQ = 20MB, 2202 VTH = 18 MB}, PTS={ 2203 QID=5, PTS{TSI=300sec, 2204 TITSU=6000sec}} 2205 <-------(3)------- 2207 service provision/metering 2208 -------(4)---------> 2210 5900 seconds 2211 passed 2212 Access Request 2213 {RADIUS BASE AVPS, 2214 PPAQ={QID=5, VQ=14MB, 2215 REASON=TITSU APPROACH.}, 2216 TSI={QID=5, VUATS=11MB}} 2217 -------(5)---------> 2219 [allocates another 10MB 2220 to the access service] 2222 Access Accept 2223 {RADIUS BASE AVPS, 2224 PPAQ={QID=8, VQ=30MB, 2225 VTH = 28 MB},PTS={ 2226 QUD=8, PTS=95 sec}} 2227 <----------(6)-------------- 2229 user logs off 2230 ------(7)------- 2232 Access Request 2233 {RADIUS BASE AVPS, 2234 PPAQ={QID=8, VQ=17 MB, 2235 REASON=ACCESS SERV TERMINATED}, 2236 PTS={QID=8, VUATS=2.5 MB} 2237 -------(8)---------> 2239 [reimburses 2240 user account] 2242 AA Accept 2243 {RADIUS BASE AVPS} 2244 <-------(9)-------- 2246 Figure 20: Example message flow with Tariff Switch 2248 The user logs on (1). The PPC sends a RADIUS Access Request message 2249 to the home AAA server (2), and includes the prepaid-specific PPAC 2250 AVP. This AVP indicates that both duration-based and volume-based 2251 metering is supported, as well as tariff switching. The home AAA 2252 server then may authenticate and user and authorize the access 2253 service, as is usual in RADIUS. Note that the PPAC AVP is appended 2254 by the PPC in at least the last message that is sent to the PPS 2255 during this possibly multiple-round exchange. 2257 If authentication and authorization is successful (in this example 2258 this is assumed), the PPS identifies the user's prepaid account from 2259 the included base RADIUS AVPs, and determines the capabilities of the 2260 PPC from the PPAC attribute. In this example, it is assumed that a 2261 tariff switch is about to occur in 300 seconds from the current time. 2262 Suppose that the access service is currently rated at 0.5 euros per 2263 MB and in the next tariff period it is rated at 0.6 euros per MB. 2264 Suppose further that a third tariff period is about to start in 6000 2265 seconds from current time and that that access service is rated at 2266 0.8 euros per MB in that period. The PPS then decides to reserve 12 2267 euros from the user's account. Since it is conceivable that the user 2268 may consume all allocated quota in the (more expensive) "0.6-euro" 2269 period, the PPS reserves 20 MB of quota, and determines a threshold 2270 value of 18 MB. It constructs a Radius Access Accept message with a 2271 PPAQ attribute that reflects these choices, and carries a Quota 2272 Identifier QID=5. It further adds a PTS AVP in the message which is 2273 linked to the PPAQ via the common QID value. The PTS AVP contains a 2274 TSI attribute indicating that a tariff switch will occur in 300 2275 seconds. It also includes a TITSU attribute with the value of 6000 2276 seconds. This is included in order to make sure that the PPC will 2277 report the consumed quota before the "2-euro" tariff period will 2278 start. The message is sent to the PPC (3). 2280 Upon reception of message (3), the PPC provides the access service to 2281 the user and meters it accordingly (4). It also keeps track of time. 2283 That is, it remembers how many octets are consumed before and how 2284 many after the tariff switch that will take place in 300 seconds. 2286 In this example it is assumed that the user consumes the allocated 2287 quota rather slowly. In particular, nearly 6000 seconds (the value 2288 indicated by TITSU SubType) pass without the threshold of 18 MB being 2289 reached. The PPC notices this and must therefore report usage and 2290 request the quota to be replenished despite the fact that the 2291 threshold has not been reached. In this example, it decides to do so 2292 100 seconds before the 6000 seconds are reached. To this end, it 2293 constructs an Authorization Access Request message including a PPAQ 2294 that indicates that 14 MB have been consumed up to now. It also 2295 includes a PTS attribute in order to indicate, using the VUATS 2296 SubType, that 11 MB of these were consumed after the tariff switch. 2297 The message is sent to the the PPS (5). 2299 The PPS can link the message to previous session state via the QID. 2300 It now rates the consumed volume as follows. The 11 MB that were 2301 consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros 2302 and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS 2303 subtracts the amount of 6.6+1.5=8.1 euros from the user's account, 2304 which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved. 2306 The PPS now determines that message (5) was sent in order to 2307 replenish the quota for this prepaid session. This can be deduced 2308 from the UPDATE REASON field, which indicates that the PPC sent this 2309 message because the time indicated by the TITSU SubType is 2310 approacing. The PPS now determines that enough credit remains in the 2311 user's prepaid account in order for the access service to continue 2312 being provided and decides to reserve another 8.9 euros from the 2313 user's account. Since it is conceivable that the user will consume 2314 the 6 unused MB of quota from the previous allocation, as well as the 2315 entire quota that is to be allocated now, entirely in the "0.8-euro" 2316 period, the quota that should now be granted in addition to the 2317 previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros 2318 are being reserved in order to "cover the worst case scenario". The 2319 fact that 0.9 euros are reserved for this purpose is due to the fact 2320 that the unused 6 MB from the previous allocation correspond to 4.8 2321 euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more 2322 than the amount of funds that are still "reserved" from the previous 2323 allocation. (After this reservation, the total amount of reserved 2324 money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB 2325 being consumed in the "0.8-euro" period.) 2327 Since quotas are encoded in a cumulative way in RADIUS, the PPS 2328 includes a VolumeQuota of 30 MB into the Access Accept message (6). 2329 The PPS further calculates the new threshold value of 28 MB. Since 2330 this is a new quota reservation, the PPS also allocates a new QID to 2331 it, in this example QID=8. The resulting RADIUS message is sent to 2332 the PPC (6). 2334 Upon reception of message (6), the PPC updates its records and 2335 continues providing access to the user. At some point the user logs 2336 off (7). The PPC must then report how many resources were consumed, 2337 so that the PPC can subtract the appropriate monetary amount from the 2338 user's prepaid account. To this end the PPC constructs an Authorize- 2339 Only Access Request message with a PPAQ attributes for the access 2340 service. In this example, 17 MB were consumed by the access service 2341 in total. The PPC reports 17 MB its final message (8). The PPS 2342 correlates the report, using the QID, to the previous session state. 2343 It determines, from the previous records, that the access service had 2344 consumed 14 MB before (as indicated in message (5)). This means 2345 that, of the 17 MB, only the monetary equivalent for 3 MB have not 2346 yet been subtracted from the user's account. The PPS calculates how 2347 much should be deducted from the user's account as follows. Since 2348 the VUATS SubType indicates that 2.5MB were consumed after the tariff 2349 switch, only 0.5 MB were consumed before that. Thus, the monetary 2350 equivalent is 0.5 * 0.6 + 2.5 * 0.8 = 3.6 euros. That is, the PPS 2351 subtracts 3.6 euros from the user's prepaid account. Since the 2352 session has by now be terminated by the PPC (REASON=ACCESS SERVICE 2353 TERMINATED), the PPS now releases any reserved monetary amount, in 2354 this example 12.8 - 3.6 = 9.2 euros. 2356 The PPS responds with an Access Response as required by the RADIUS 2357 base specification (9). 2359 Remark: In this example, two tariff switches take place. In other 2360 scenarios, of course, only one tariff switch may occur. In such 2361 scenarios the TITSU SubType is not used. 2363 A.3. Resource pools and Rating Groups 2365 End user PPC PPS 2367 user logs on 2368 ------(1)---------> 2370 Access Request 2371 {RADIUS BASE AVPS, 2372 PPAC=00...00101111} 2373 -------(2)--------> 2375 [allocates 2376 5MB quota] 2378 Access Accept 2379 {RADIUS BASE AVPS, 2380 PPAQ={QID=5, VQ = 5MB, 2381 poolID=1,mult=1}} 2382 <-------(3)-------- 2384 service provision/metering 2385 -------(4)---------> 2387 user requests service A 2388 -------(5)---------> 2390 Access Request 2391 {RADIUS BASE AVPS,PPAQ={ 2392 SID="A", RGROUP=1}} 2393 -------(6)--------> 2395 [allocates 50 min 2396 quota] 2398 Access Accept 2399 {RADIUS BASE AVPS, 2400 PPAQ={QID=7, DQ=3000sec 2401 poolID=1,RGROUP=1, SID="A" 2402 mult=1747.63}} 2403 <---------(7)--------------- 2405 user requests service B 2406 -------(8)--------> 2408 Pool 1 close to exhaustion 2410 Access Request 2411 {RADIUS BASE AVPS, 2412 PPAQ={QID=5, VQ=4MB, 2413 REASON=QUOTA REACHED, 2414 PoolID=1, mult=1} 2415 PPAQ={QID=7, DQ=3300sec 2416 REASON=QUOTA REACHED, 2417 PoolID=1, mult=1747.63, 2418 SID="A",RGROUP=1}} 2419 -------(9)---------> 2421 [allocates another 2422 3 MB to access service 2423 and 30 minutes to 2424 service "A"] 2426 Access Accept 2427 {RADIUS BASE AVPS, 2428 PPAQ={QID=8, VQ=8MB, 2429 PoolID=1, mult=1, RGROUP=1}, 2430 PPAQ={QID=9, DQ=4800sec 2431 PoolID=1, mult=1747.63, 2432 SID="A"}} 2433 \ <----------(10)-------------- 2435 user logs off 2436 ------(11)------- 2437 Access Request 2438 {RADIUS BASE AVPS, 2439 PPAQ={QID=8, VQ=6.5MB, 2440 REASON=ACCESS SERV TERMINATED, 2441 PoolID=1, mult=1} 2442 PPAQ={QID=9, DQ=5400sec 2443 REASON=ACCESS SERV TERMINATED, 2444 PoolID=1, mult=1747.63, 2445 SID="A",RGROUP=1}} 2446 -------(12)---------> 2448 [reimburses 2449 user account] 2451 AA Accept 2452 {RADIUS BASE AVPS 2453 <------(13)-------- 2455 Figure 21: Example message flow with resource pools and rating groups 2457 The user logs on (1). The PPC sends a RADIUS Access Request message 2458 to the PPS (2), and includes the prepaid-specific PPAC AVP, 2459 indicating that multiple services, rating groups and resource pools 2460 are supported. Note that, since this is not an "Authorize- Only" 2461 message, no PPAQ attribute with Update Reason="initial request" is 2462 included (see Section 3.7.1). The PPS then may authenticate the user 2463 and authorize the access service, as is usual in RADIUS. Note that 2464 the PPAC AVP is appended by the PPC in at least the last message that 2465 is sent to the PPS during this possibly multiple-round exchange. 2467 If authentication and authorization is successful (in this example 2468 this is assumed), the PPS identifies the user's prepaid account from 2469 the included base RADIUS AVPs, and determines the capabilities of the 2470 PPC from the PPAC attribute. Assuming that sufficient funds are 2471 available in the user's prepaid account, the PPS reserves some of 2472 these and rates the service. In this example, the PPS reserves 5 2473 Euros and determines that the access service is rated at 1 Euro per 2474 MB. In anticipation that the user requests more chargeable services 2475 throughout this prepaid session, and since this is supported by the 2476 PPC, the PPS further associates a resource pool with this 2477 reservation, in this example PoolID=1. The PPC also specifies the 2478 multiplier = 1 for the access service. Note that, since 5MB = 2479 5242880 octets, 1 unit in the resource pool corresponds to 5 / 2480 5242880 euros, which is about 0.000095367431640625 Eurocents. 2481 (However, the PPC does not need to know that.) Moreover, the PPS 2482 associates the QID=5 to this reservation. This identifier can be 2483 used to later uniquely identify the prepaid session, user, account, 2484 etc. The resulting Access Accept message is sent to PPC (3). 2486 Upon reception of message (3), the PPC provides the access service to 2487 the user and meters it accordingly (4). That is, for every octet 2488 consumed, the PPC subtracts 1 unit (since the multiplier is 1) from 2489 the resouce pool with PoolID=1. 2491 At some point in time, the user requests another chargeable service, 2492 namely service A (5). The PPC generates an Authorize-Only Access 2493 Request that contains the usual RADIUS attributes and the Service-ID 2494 identifying service A (6). The PPC has determined that service A is 2495 rated in an identical way as at least one more service. Thus, 2496 service A has been configured to belong to a rating group, in this 2497 example the group with Rating-Group-ID=1. This identifier is 2498 included is message (6). 2500 Upon reception of message (6), the PPS identifies the user and his 2501 account from the base RADIUS attributes, the fact that a prepaid 2502 session is ongoing, and determines that enough credit remains in the 2503 prepaid account in order for service A to be provided. The PPS also 2504 determines that service A is rated at 0.10 euros per minute. The PPS 2505 decides to reserve another 5 euros from the users account; this 2506 corresponds to 50 minutes or, as encoded in the DurationQuota 2507 SubType, 3000 seconds. As service A draws from the same prepaid 2508 account as the access service, the PPS associates this reservation 2509 with the same resource pool as the previous reservation (QID=5), 2510 namely the pool with PoolID=1. Note that, in order for the abstract 2511 units in the pool to be consistent, the multiplier has to be 1747.63. 2512 This is because each second corresponds to about 0.10 / 60 = 0.00167 2513 euros, which is about 1747.63 times the value of an abstract resource 2514 pool unit, as this was determined by the first allocation of quota to 2515 the pool (i.e., 0.000095367431640625 Eurocents). Since this is a new 2516 quota reservation, the PPS also allocates a new QID to it, in this 2517 example QID=7. The resulting RADIUS message is sent to the PPC (7). 2519 Upon reception of message (7), the PPC adjusts the units in resource 2520 pool 1. That is, it first determines how much quota had been 2521 allocated to service A in the past, and subtracts this from the quota 2522 reservation found in the message. Since this is the first quota 2523 reservation for service A, there is nothing to subtract. Thus, it 2524 adds 3000 * 1747.63 = 5242890 units to the pool and remembers that 2525 3000 seconds have been allocated to service A during this prepaid 2526 session. The PPC then provides service A to the user, and meters it 2527 against resource pool 1. That is, for every second it subtracts 2528 1747.63 units from the pool. 2530 At some point in time, the user requests service B (8). The PPC 2531 determines that service B is rated exactly in the same way as service 2532 A, i.e., that they belong to the same rating group, namely the one 2533 with Rating-Group-ID=1. Since this rating group has been effectively 2534 authorised by the allocation of quota with QID=7, the PPC provides 2535 service B to the user immediately. It is rated in the same way as 2536 service A, i.e., for every second provided, 1747.63 units are 2537 subtracted from credit pool 1. 2539 At some point in time, resource pool 1 is close to exhaustion. (For 2540 example, the PPC may determine that the pool is "close to exhaustion" 2541 when has less than 10% its initial amount of units.) At that point, 2542 the PPC needs to ask for replenishment for the pool. Suppose that, 2543 at that point in time, 4MB of "access service", 45 minutes of 2544 "service A", and 10 minutes of "service B" were provided to the user. 2545 Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304 2546 + 5767179 = 9961483 abstract service units from the pool. The PPC 2547 constructs an Authorize-Only Access Request message that reports the 2548 usage for the "access service" and "service A". This message 2549 contains two PPAQ attributeS, is sent to the PPS (9). Note that is 2550 the message it appears that "service A" has consumed more than it was 2551 allocated (i.e., 55 minutes although only 50 minutes were initially 2552 allocated to it). This is not a a problem since the PPS knows that 2553 "service A" was drawing from the same pool as the "access service" 2554 and that the "access service" did only consume 4 out of the 5 MB it 2555 was allocated. 2557 Upon reception of message (9), the PPS subtracts 4 euros from the 2558 user's account for the "access service" and another 5.5 euros for 2559 "service A". (This includes the charge incurred by "service B" up to 2560 that point in time, although the PPS is not aware of "service B" 2561 being provisioned to the user.) The PPS then determines that 2562 sufficient funds remain in the prepaid account in order for both 2563 services to be continued. The PPS decides to reserve another 3MB for 2564 the access service and 30 minutes for "service A". This corresponds 2565 to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a 2566 cumulative manner, the PPAQ attribute that grants the quota for the 2567 "access service" contains a Volume-Quota SubType of 8MB (8388608 2568 octets), which is the 5MB that were initially allocated, plus the 3MB 2569 allocated now. The resource pool identifier is, as previously, 2570 PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants 2571 quota for "service A" contains 4800 seconds (the initial 3000 plus 2572 1800 that correspond to the 30 additional minutes). Again, the 2573 PoolID=1 and multiplier=1747.63. The resulting Access Response 2574 message is sent to the PPC (10). 2576 When the PPC received message (10) it checks how much quota has been 2577 allocated previously to the "access service". It finds that the 2578 answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets) 2579 that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets) 2580 have not yet been added to resource pool 1. The PPC thus adds 2581 3145728 abstract units to resource pool 1 (since the multiplier is 2582 1). The PPC then acts similarly on the other PPAQ attribute that 2583 exists in message (11). That is, the PPC determines that 3000 2584 seconds of quota for "service A" had already been added to the pool. 2585 Thus only 1800 out of the 4800 should be additionally added to the 2586 pool. Since the applicable multiplier here is 1747.63, the PPC adds 2587 further 3145734 abstract units to the pool 1. 2589 The PPC then continues to provide the access service, "service A" and 2590 "service B" to the user, and meters them against the pool, as 2591 previously. 2593 At some point the user logs off (11). The PPC must then report how 2594 many resources were consumed, so that the PPC can subtract the 2595 appropriate monetary amount from the user's prepaid account. To this 2596 end the PPC constructs an Authorize-Only Access Request message with 2597 two PPAQ attributes; one for the access service and one for "service 2598 A". Suppose that, in total, 6.5MB were consumed by the access 2599 service, 70 minutes were consumed by "service A" and 20 minutes by 2600 "service B". The PPC reports 6.5MB (6815744 octets) and 90 minutes 2601 (5400 seconds) in its final message (12). The PPS determines, from 2602 the previous records, that the access service consumed another 2.5MB 2603 (since 4MB out of the 6.5MB were already reported in message (9), and 2604 that "service A" consumed further 600 seconds. This corresponds to 2605 2.5 + (600/60)*0.1 = 2.5+ 1=3.5 euros. Thus, the PPS only subtracts 2606 2.5 out of the 6 previously reserved euros from the user's prepaid 2607 account and responds with an Access Response as required by the 2608 RADIUS base specification (13). 2610 A.4. One-time charging 2611 End user PPC PPS 2613 user requests ring tone 2614 ------(1)---------> 2616 Access Request 2617 {RADIUS BASE AVPS, 2618 PPAQ={QID=321, SID=X, RQ=650, 2619 REASON=10 (ONE-TIME CHARGING}} 2620 -------(2)---------> 2622 [rates 650 abstract units 2623 deducts from user's account] 2625 Access Accept 2626 {RADIUS BASE AVPS} 2627 <----------(3)-------------- 2629 ring tone is delivered 2630 <------(4)------- 2632 Figure 22: Example message flow with one-time charging 2634 The user requests a chargeable ring tone (1). The PPC sends a RADIUS 2635 Access Request message to the PPS (2), and includes a PPAQ attribute 2636 with Update Reason="one-time charging" is included (see 2637 Section 3.7.6). The Service ID indicates to the PPS that the 2638 charging event is connected to a ring tone, so that the PPS can rate 2639 the event accordingly. The PPAQ also contains a unique Quota 2640 Identifier. 2642 The PPS then may authenticate the user as is usual in RADIUS. If 2643 authentication is successful (in this example this is assumed), the 2644 home AAA server forwards the PPC converts the 650 reported abstract 2645 units into monetary value, according to the service type, and debit 2646 the user's account accordingly. This happens, of course, only if 2647 sufficient funds are available in the user's prepaid account. The 2648 PPC then responds with an an Access Accept message (3). The PPS adds 2649 a "session timeout = 0 AVP" (see Section 3.7.6). 2651 A.5. Price enquiry 2652 End user PPC PPS 2654 user requests AoC 2655 ------(1)---------> 2657 Access Request 2658 {RADIUS BASE AVPS, 2659 PPAQ={SID=X, VQ=10MB, 2660 REQ_ACT=2(PRICE ENQUIRY}} 2661 -------(2)---------> 2663 [rates 10MB for requested 2664 service] 2666 Access Accept 2667 {RADIUS BASE AVPS, 2668 PPAQ={SID=X, VQ=10MB, 2669 COST INFORMATION= 0.6 euros 2670 per MB}} 2671 <----------(3)-------------- 2673 AoC is delivered 2674 <------(4)------- 2676 Figure 23: Example message flow with price enquiry (advice of charge) 2678 Please refer to Section 2.7.2 for an explanation of this message 2679 flow. 2681 A.6. Balance check 2682 End User PPC PPS 2684 Access Request 2685 {RADIUS BASE AVPS, 2686 PPAQ={SID=X, VQ=10MB, 2687 REQ_ACT=BALANCE CHECK}} 2688 -------(2)---------> 2690 [rates requested 2691 Service and checks 2692 remaining funds] 2694 Access Accept 2695 {RADIUS BASE AVPS, 2696 PPAQ={SID=X, VQ=10MB, 2697 BALANCE_CHECK_RESULT}} 2698 <----------(3)-------------- 2700 Figure 24: Example message flow with balance check 2702 Please refer to Section 2.7.3 for an explanation of this message 2703 flow. 2705 Appendix B. Translation between RADIUS Prepaid and Diameter Credit 2706 Control 2708 In scenarios where the service metering device uses the "RADIUS 2709 prepaid" (RPP) protocol for accounting and prepaid charging while the 2710 AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, 2711 a translation agent that enables the interoperation of both systems, 2712 is desirable. This also applies vice versa, i.e., in scenarios where 2713 the AAA infrastructure uses RADIUS and the service metering device 2714 uses Diameter. 2716 The idea of such a translation agent would be to convert incoming RPP 2717 (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It 2718 would be, in principle, desirable for the translation agent to be 2719 stateless. That is, the agent should not be required to internally 2720 maintain information about each ongoing RADIUS or Diameter session. 2721 However, under the current specification of RPP and DCC, this appears 2722 to be impossible due to a number of reasons. These include the 2723 following. 2725 1. The transport mechanism for DCC is TCP, which requires per- 2726 session state to be maintained at both endpoints of the 2727 communication. Note, however, that, in principle, each DCC 2728 message could be sent over a dedicated TCP connection which is 2729 torn down as soon as the message is sent. This, however, is 2730 likely to be unacceptable in terms of efficiency. 2732 2. While RPP messages encode the cumulative amount of consumed/ 2733 requested resources, DCC messages carry the difference from the 2734 previous message. This means that the translation agent has to 2735 maintain the current amount of consumed/requested resources in 2736 order to be able to calculate the correct amount to be put into 2737 an outgoing message. 2739 The translator maps each incoming RPP (resp. DCC) message into an 2740 outgoing DCC (resp. RPP) message, and possibly establishes or updates 2741 local state that is associated with the session. The translated 2742 (i.e., outgoing) message is a function of the incoming message as 2743 well as existing state that is associated with the current session. 2745 Translation occurs on an attribute-by-attribute basis. Certain 2746 attributes are translated without consideration of local per-session 2747 state. Other attributes, namely those that are bound to a particular 2748 session, require such consideration. The translation agent has to 2749 identify the session (and possibly subsession) an incoming message 2750 belongs to in order to consult the appropriate local per-session 2751 state. 2753 Note that certain DCC attributes cannot be translated due to their 2754 semantics not being present in RPP, and vice versa. This results in 2755 the messages, in which these attributes occur, not being delivered to 2756 their intended destination. In such cases it is desirable to inform 2757 the originator about the failure and terminate the session. 2759 In each scenario (i.e., RPP client / DCC AAA infrastructure and DCC 2760 client / RPP AAA infrastructure), the translator operates in two 2761 directions, namely RPP to DCC and vice versa. In the following 2762 sections, the notation c->s means that the attribute in question may 2763 occur only in the direction from the client to the server. The 2764 notation s->c denotes the converse and the notation c<->s denotes 2765 that the attribute may occur in messages that are directed in either 2766 direction. 2768 B.1. Session Identification 2770 The translation agent has to keep per-session state in order to 2771 perform its task. A session may be identified based on the RPP 2772 identifier or the DCC session identifier. That is, the translation 2773 agent should always maintain a pair of (RPP, DCC) session identifiers 2774 and maintain the per-session state in association with that pair. 2775 This per-session state must be addressable by either of these two 2776 identifiers. Moreover, an RPP session identifier must uniquely 2777 correspond to a DCC identifier. (If this holds, the converse also 2778 holds.) Each subsession identifier within an RPP session must also 2779 uniquely correspond to a subsession identifier within its 2780 corresponding DCC session. (If this holds the converse also holds.) 2782 B.2. Translation between RADIUS Prepaid and Diameter Credit Control 2784 This section describes the translator in the "RPP client / DCC AAA 2785 infrastructure" case. In other words, in this section it is assumed 2786 that the client "talks" RPP and the AAA inftrastructure "talks" DCC. 2787 The translator is assumed to sit somewhere in the middle and to 2788 mediate between client and server. 2790 For each RPP AVP (i.e., AVPs that are specified in the present 2791 document), the transformation into a semantically equivalent DCC AVP 2792 (if such an AVP exists), along with what per-session state the 2793 translator has to create or consult, is described. For clarity of 2794 exposition, each RPP AVP is addressed in a separate subsection. 2795 Since in this scenario, the PPC is typically the initiator a session, 2796 the focus is on the RPP AVPs. 2798 B.2.1. PPAC (c<->s) 2800 A DCC client is assumed to always support Volume metering, Duration 2801 metering, Resource metering, Pools, Rating groups, and Tariff 2802 Switching. Thus, if a PPAQ that indicates any of the above is sent 2803 client->server, the translator does the following: It lets message go 2804 through but remembers what exactly the client supports. If the 2805 server later requests (servier -> client direction) an unsupported 2806 metering to be performed, send failure to server and cause the 2807 session to be terminated at the client. 2809 If a PPAC indicates support for multiple services (0x00000020), the 2810 translator maps this onto a DCC Multiple-Services- Indicator AVP. 2812 B.2.2. Service Termination Attribute (c->s) 2814 The Diameter base protocol assumes that the client always supports 2815 dynamic session termination. If this AVP is present, the translator 2816 does not need to do anything, i.e., there exists no DCC AVP that this 2817 AVP can be mapped to. If this AVP is absent, the message in which it 2818 appears should either be discarded and originator should be informed 2819 of a failure, or the message can be passed on (without this AVP being 2820 mapped onto a DCC AVP). However, in the latter case, the translator 2821 has to remember that the client does not support dynamic termination. 2822 Thus, the translatior has to initiate the normal session termination 2823 procedure with the client when (if) dynamic termination is later 2824 initiated by the server. 2826 B.2.3. Quota Identifier Attribute (c<->s) 2828 When quota is allocated for the first time by the DCC server, the 2829 translator has to create a QID AVP, as required by this 2830 specification. The translator later uses a QID AVP that is sent in 2831 the client-to-server direction in order to identify the corresponding 2832 DCC session. The QID has to be saved in the translator's per session 2833 state. 2835 B.2.4. Volume Quota Attribute (c<->s) 2837 If this AVP occurs in a message that is sent in the server-to-client 2838 direction, it is translated into a Granted-Service-Unit AVP with an 2839 embedded CC-Total-Octets AVP. 2841 If this AVP occurs in a message that is sent in the client-to-server 2842 direction, then it is translated into a Used-Service-Unit AVP with an 2843 embedded CC-Total-Octets AVP. Note that only the difference between 2844 current cumulative quota for the (sub)session and the quota in 2845 incoming messages is indicated in the translated DCC message. Local 2846 state is updated with cumulative consumed resources. 2848 Conversely, if the server grants quota using the DCC Granted-Service- 2849 Unit AVP with an embedded CC-Total-Octets AVP, then the translation 2850 agent must translate this into a Volume Quota Attribute. Again, 2851 local state must be consulted so that the cumulative amount of octets 2852 is indicated in the Volume Quota attribute. 2854 B.2.5. Duration Quota Attribute (c<->s) 2856 If this AVP occurs in a message that is sent in the server-to-client 2857 direction, it is translated into a Granted-Service-Unit AVP with an 2858 embedded CC-Time AVP. 2860 If this AVP occurs in a message that is sent in the client-to-server 2861 direction, then it is translated into a Used-Service-Unit AVP with an 2862 embedded CC-Time AVP. Note that only the difference between current 2863 cumulative quota for the (sub)session and the quota in incoming 2864 messages is indicated in the translated DCC message. Local state is 2865 updated with cumulative consumed resources (i.e., time). 2867 Conversely, if the server grants quota using the DCC Granted-Service- 2868 Unit AVP with an embedded CC-Time AVP, then the translation agent 2869 must translate this into a Duration Quota attribute. Again, local 2870 state must be consulted so that the cumulative amount of seconds is 2871 indicated in the Duaration Quota attribute. 2873 B.2.6. Resource Quota Attribute (c<->s) 2875 If this AVP occurs in a message that is sent in the server-to-client 2876 direction, it is translated into a Granted-Service-Unit AVP with an 2877 embedded CC-Service-Specific-Units AVP. 2879 If this AVP occurs in a message that is sent in the client-to-server 2880 direction, then it is translated into a Used-Service-Unit AVP with an 2881 embedded CC-Service-Specific-Units AVP. Note that only the 2882 difference between current cumulative quota for the (sub)session and 2883 the quota in incoming messages is indicated in the translated DCC 2884 message. Local state is updated with cumulative consumed resources 2885 (i.e., resources). 2887 Conversely, if the server grants quota using the DCC Granted-Service- 2888 Unit AVP with an embedded CC-Service-Specific-Units AVP, then the 2889 translation agent must translate this into a Resource Quota 2890 attribute. Again, local state must be consulted so that the 2891 cumulative amount of resource units is indicated in the Resource 2892 Quota attribute. 2894 Note that the "resource" type is application dependent. This means 2895 that a DCC application unit corresponds to n RPP application units, 2896 where n may be any real number. If n is not 1, then the RPP/DCC 2897 translator must be aware of that and translate resource units 2898 accordingly. 2900 B.2.7. Value Digits Attribute (c<->s) 2902 The encoding of this AVP is similar in RPP and DCC, and the value it 2903 holds may have to be evaluated in conjunction with an acommpanying 2904 "Exponent" AVP. It should be kept in mind that, in RPP the 2905 cumulative amount of granted/consumed quota is typically encoded into 2906 an AVP of this type, while in DCC only the difference from a previous 2907 message. 2909 B.2.8. Exponent Attribute (c<->s) 2911 The encoding of this AVP is similar in RPP and DCC, and the value it 2912 holds may have to be evaluated in conjunction with an acommpanying 2913 "Value Digits" AVP. It should be kept in mind that, in RPP the 2914 cumulative amount of granted/consumed quota is typically encoded into 2915 a related "Value Digits" and "Exponent" AVP pair, while in DCC only 2916 the difference from a previous message is encoded into such a pair. 2918 B.2.9. Volume/Duration/Resource Threshold Attributes (s->c) 2920 In DCC the concept of "threshold" does not exist. Instead, the DCC 2921 client is assumed to ask for the replenishment of quota in good time. 2922 In RPP, on the other hand, the server may optionally include a 2923 threshold AVP, as an indication to the PPC about when to ask for 2924 quota replenishment. 2926 Thus, in this scenario, there is no need for the translator to ever 2927 include a threshold attribute into the messages that it sends to the 2928 PPC. If, however, there is a need for a threshold attribute to be 2929 present in order to avoid a possible service provision 2931 B.2.10. Update Reason Attribute (c->s) 2933 The DCC AVP that is semantically closer to the Update Reason AVP than 2934 any other AVP is the CC-Request-Type AVP. This AVP indicates whether 2935 the message is which it appears is intended to indicate an "initial", 2936 an "intermediate" or a "final interrogation". Morever, in case of 2937 the session being terminated at the client, it indicates the reason 2938 for this termination. 2940 The following list lists the possible values of an "Update Reason" 2941 attribute, along with corresponding values for the CC-Request-Type 2942 AVP. 2944 o Pre-initialization: No action/value defined. 2946 o Initial Request: Typically an "intial interrogation" is triggered 2947 as a result of the reception of the message that contains this 2948 Update Reason AVP. Hence, CC-Request-Type AVP indicates 2949 "INITIAL_REQUEST". 2951 o Threshold Reached: The reception of the message containing this 2952 Update Reason AVP typically triggers an "intermediate 2953 interrogation". Hence, CC-Request-Type AVP indicates 2954 "UPDATE_REQUEST". 2956 o Quota Reached: The reception of the message containing this Update 2957 Reason AVP typically triggers an "intermediate interrogation". 2958 Hence, CC-Request-Type AVP indicates "UPDATE_REQUEST". 2960 o TITSU Approaching: The reception of the message containing this 2961 Update Reason AVP typically triggers an "intermediate 2962 interrogation". Hence, CC-Request-Type AVP indicates 2963 "UPDATE_REQUEST". 2965 o Remote Forced Disconnect: Reception of such an Update Reason 2966 indicates that the client has terminated the session. The 2967 corresponding value for the CC-Request-Type AVP is 2968 "TERMINATION_REQUEST". 2970 o Client Service Termination: Reception of such an Update Reason 2971 indicates that the client has terminated the session. The 2972 corresponding value for the CC-Request-Type AVP is 2973 "TERMINATION_REQUEST". 2975 o "Access Service" Terminated: Reception of such an Update Reason 2976 indicates that the client has terminated the session. The 2977 corresponding value for the CC-Request-Type AVP is 2978 "TERMINATION_REQUEST". 2980 o Service not established: Reception of such an Update Reason 2981 indicates that the client has terminated the session. The 2982 corresponding value for the CC-Request-Type AVP is 2983 "TERMINATION_REQUEST". 2985 o One-Time Charging: Such an Update Reason indicates that a one-time 2986 charging event is initiated by the client. The corresponding 2987 value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a 2988 "Requested-Action: AVP MUST also be included in the outgoing DCC 2989 message. Typically, this would be of the type "DIRECT_DEBITING", 2990 or "REFUND_ACCOUNT", depending on other AVPs present in the 2991 message. 2993 B.2.11. PrepaidServer Attribute (s<->c) 2995 The PPC typically never sets the value of a PrepaidServer attribute. 2996 Instead, it repeats those values that it receives from the AAA 2997 infrastructure, in this scenario from the translator. This attribute 2998 is therefore not used in a translation scenario. Nevertheless, the 2999 translator must make sure that messages about the same RPP session 3000 are forwarded to the same DCC server, throughout the whole session. 3001 This may be easy to guarantee since the transport of Diameter is TCP. 3003 B.2.12. Service-ID Attribute (s<->c) 3005 The DCC equivalent of a RPP "Service-ID" AVP is the combination of 3006 Service-Context-Id and Service-Identifier AVPs. The translator must 3007 keep a static equivalence table of the RPP Service-ID and the 3008 corresponding DCC combination in order to correctly translate an RPP 3009 service identifier into DCC and back. 3011 B.2.13. Rating-Group-ID Attribute (s<->c) 3013 The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a 3014 "Rating-Group-ID". Depending on the configuration, this AVP may 3015 contain the same value on both the RPP and the DCC side of the 3016 communication. If, however, static rating groups are configured 3017 between the RCC client and the translator, and different rating 3018 groups between the DCC server and the translator, then the translator 3019 has to maintain a static translation table for the rating group 3020 identifier. In any case, the translation of a rating group AVP, is 3021 not a function of the translator's local per-session state. 3023 B.2.14. Termination-Action Attribute (s->c) 3025 The DCC equivalent of the "Termination-Action" AVP is called the 3026 "Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA 3027 infrastructure), a DCC "Final-Unit-Action" AVP is translated into a 3028 "Termination-Action" AVP. The following list contains the possible 3029 "Final-Unit-Action" values along with their "Termination-Action" 3030 equivalent. 3032 o TERMINATE (DCC): This value has a direct equivalent in RPP, also 3033 called "Terminate". 3035 o REDIRECT (DCC): If this value appears in a "Final-Unit-Action" 3036 AVP, then a "Redirect-Server-Address" AVP must also appear in the 3037 same DCC message. The translator translates these two AVPs into a 3038 "Termination-Action" with value "Redirect/Filter" and an 3039 eqiovalent NAS-Filter-Rule attribute (specified in http:// 3040 www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt). 3042 o RESTRICT_ACCESS (DCC): If this value appears in a "Final-Unit- 3043 Action" AVP, then a "Restriction-Filter-Rule" AVP must also appear 3044 in the same DCC message. The translator translates these two AVPs 3045 into a "Termination-Action" with value "Redirect/Filter" and an 3046 eqiovalent Filter-ID attribute (specified in http://www.ietf.org/ 3047 internet-drafts/draft-ietf-radext-ieee802-00.txt). 3049 o In the absence of a "Final-Unit-Action" AVP, the DCC server 3050 assumes that the DCC client will ask for replenishment of quota at 3051 some suitable time. In RPP, this is explicitly conveyed via a 3052 "Termination-Action" AVP with the value "Request More Quota". 3053 Thus, in the absence of a "Final-Unit-Action" AVP, the translator 3054 in this scenario appends such an AVP into the outgoing RPP 3055 message. 3057 B.2.15. Pool-ID Attribute (s<->c) 3059 The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID". 3060 Typically, no translation needs to be done to the "Pool-ID" 3061 attribute. 3063 B.2.16. Multiplier Attribute (s<->c) 3065 The multiplier attribute, which is a pair of "Value-Digits" and 3066 "Exponent" AVPs, typically needs no translation, since the value it 3067 carries (inside a "Value-Digits" and an "Exponent" AVP) represents 3068 the rating of the service or rating group to which it refers, with 3069 respect to abstract units. As such, the same multiplier value would 3070 typically applyt be conveyed from a DCC server to an PPC, and vice 3071 versa. 3073 B.2.17. Requested-Action Attribute (c->s) 3075 The "Requested Action" AVP can be directly translated into its DCC 3076 equivalent, which carries the same name. 3078 1. Balance Check (PCC): CHECK_BALANCE (DCC) 3080 2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC) 3082 B.2.18. Check-Balance-Result Attribute (s->c) 3084 This attribute carries only a binary value. Hence, its translation 3085 is straightforward. 3087 B.2.19. Cost-Information Attribute (s->c) 3089 This attribute consists of a Value-Digits AVP, an Exponent AVP, a 3090 Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise 3091 exist in DCC, and carry identical semantics in the context of the 3092 "Cost-Information" AVP. Thus, the translation of this attribute is 3093 straightforward. 3095 B.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) 3097 This attribute carries the amount of octets that were consumed after 3098 a tariff change. It always appears in a message with an accompanying 3099 PPAQ attribute in which the total amount of octets (i.e., those that 3100 were consumed both before and after the tariff switch) is reported. 3101 Thus, the translation agent can compute the amount of octets that 3102 were consumed before the tariff change. 3104 In DCC, the two amounts, i.e., the octets that were consumed before a 3105 tariff change and those that were consumed afterwards, are reported 3106 in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs 3107 have an embedded CC-Total-Octets AVP that indicates the appropriate 3108 amount of octets. Furthermore, the Used-Service-Unit AVP that 3109 carries the amount that was consumed before the tariff switch also 3110 carries an embedded Tariff-Change-Usage AVP with the value 3111 UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP 3112 that carries the amount that was consumed after the tariff switch 3113 also carries an embedded Tariff-Change-Usage AVP with the value 3114 UNIT_AFTER_TARIFF_CHANGE (1). 3116 Authors' Addresses 3118 Avi Lior 3119 Bridgewater Systems 3120 303 Terry Fox Drive 3121 Ottawa, Ontario Suite 100 3122 Canada 3124 Email: avi@bridgewatersystems.com 3126 Parviz Yegani 3127 Cisco 3128 Mobile Wireless Group, Cisco Systems 3129 3625 Cisco Way, San Jose, California 95134 3130 USA 3132 Email: pyegani@cisco.com 3134 Kuntal Chowdhury 3135 Starent Networks 3136 30 International Place, 3rd Floor 3137 Tewksbury, MA 01876 3138 USA 3140 Email: kchowdhury@starentnetworks.com 3142 Hannes Tschofenig 3143 Nokia Siemens Networks 3144 Otto-Hahn Ring 6 3145 Munich, Bavaria 81739 3146 Germany 3148 Email: hannes.tschofenig@nsn.com 3149 URI: http://www.tschofenig.com 3151 Andreas Pashalidis 3152 NEC 3153 Kurfuersten-Anlage 36 3154 Heidelberg 69115 3155 Germany 3157 Email: Andreas.Pashalidis@netlab.nec.de 3159 Full Copyright Statement 3161 Copyright (C) The IETF Trust (2007). 3163 This document is subject to the rights, licenses and restrictions 3164 contained in BCP 78, and except as set forth therein, the authors 3165 retain all their rights. 3167 This document and the information contained herein are provided on an 3168 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3169 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3170 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3171 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3172 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3173 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3175 Intellectual Property 3177 The IETF takes no position regarding the validity or scope of any 3178 Intellectual Property Rights or other rights that might be claimed to 3179 pertain to the implementation or use of the technology described in 3180 this document or the extent to which any license under such rights 3181 might or might not be available; nor does it represent that it has 3182 made any independent effort to identify any such rights. Information 3183 on the procedures with respect to rights in RFC documents can be 3184 found in BCP 78 and BCP 79. 3186 Copies of IPR disclosures made to the IETF Secretariat and any 3187 assurances of licenses to be made available, or the result of an 3188 attempt made to obtain a general license or permission for the use of 3189 such proprietary rights by implementers or users of this 3190 specification can be obtained from the IETF on-line IPR repository at 3191 http://www.ietf.org/ipr. 3193 The IETF invites any interested party to bring to its attention any 3194 copyrights, patents or patent applications, or other proprietary 3195 rights that may cover technology that may be required to implement 3196 this standard. Please address the information to the IETF at 3197 ietf-ipr@ietf.org. 3199 Acknowledgment 3201 Funding for the RFC Editor function is provided by the IETF 3202 Administrative Support Activity (IASA).