idnits 2.17.00 (12 Aug 2021) /tmp/idnits47545/draft-lior-radius-prepaid-extensions-13.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 3228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3239. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3252. 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 (February 25, 2008) is 5198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TS32240' is mentioned on line 264, but not defined -- Looks like a reference, but probably isn't: '3576' on line 1230 == Unused Reference: 'RFC3748' is defined on line 2093, 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 (==), 11 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: August 28, 2008 Cisco 6 K. Chowdhury 7 Starent Networks 8 H. Tschofenig 9 Nokia Siemens Networks 10 A. Pashalidis 11 NEC 12 February 25, 2008 14 Prepaid Extensions to Remote Authentication Dial-In User Service 15 (RADIUS) 16 draft-lior-radius-prepaid-extensions-13.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 August 28, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 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. Resource Consumption Query . . . . . . . . . . . . . . 20 74 2.7.3. Service Price Enquiry . . . . . . . . . . . . . . . . 20 75 2.7.4. Balance Check . . . . . . . . . . . . . . . . . . . . 21 76 2.7.5. Refund . . . . . . . . . . . . . . . . . . . . . . . . 21 77 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 22 79 3.2. Authentication and Authorization Operation . . . . . . . . 22 80 3.3. Session Start Operation . . . . . . . . . . . . . . . . . 24 81 3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24 82 3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26 83 3.5.1. Unsolicited Session Termination Operation . . . . . . 26 84 3.5.2. Unsolicited Change of Authorization Operation . . . . 26 85 3.6. Termination Operation . . . . . . . . . . . . . . . . . . 27 86 3.7. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27 87 3.8. Operation Considerations for Multiple Services . . . . . . 28 88 3.8.1. Initial Quota Request . . . . . . . . . . . . . . . . 28 89 3.8.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29 90 3.8.3. Termination . . . . . . . . . . . . . . . . . . . . . 29 91 3.8.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 29 92 3.8.5. Support for Resource Pools . . . . . . . . . . . . . . 30 93 3.8.6. One-time Charging . . . . . . . . . . . . . . . . . . 30 94 3.8.7. Error Handling . . . . . . . . . . . . . . . . . . . . 30 95 3.8.8. Accounting Considerations . . . . . . . . . . . . . . 31 96 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32 97 4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 32 98 4.2. Session Termination Attribute . . . . . . . . . . . . . . 33 99 4.3. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 33 100 4.4. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 40 101 5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 43 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 103 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 45 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 105 8.1. New RADIUS Attributes . . . . . . . . . . . . . . . . . . 46 106 8.2. New Registry: Prepaid SubTypes . . . . . . . . . . . . . . 46 107 8.3. New Registry: Update-Reason . . . . . . . . . . . . . . . 48 108 8.4. New Registry: Termination-Action . . . . . . . . . . . . . 48 109 8.5. New Registry: Requested-Action . . . . . . . . . . . . . . 48 110 8.6. New Registry: Check-Balance-Result . . . . . . . . . . . . 49 111 8.7. New Registry: AvailableInClient-Extended . . . . . . . . . 49 112 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 113 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 114 10.1. Normative References . . . . . . . . . . . . . . . . . . . 51 115 10.2. Informative References . . . . . . . . . . . . . . . . . . 51 116 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 52 117 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 52 118 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 54 119 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 58 120 A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 63 121 A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 64 122 A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 65 123 Appendix B. Translation between RADIUS Prepaid and Diameter 124 Credit Control . . . . . . . . . . . . . . . . . . . 67 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 126 Intellectual Property and Copyright Statements . . . . . . . . . . 77 128 1. Introduction 130 This document specifies an extension to the RADIUS protocol that 131 enables service providers to perform accounting and charging in an 132 "online" fashion. In particular, they enable the service provider to 134 (a) ensure that subscriber's remaining funds suffice before the 135 service is delivered, and 137 (b) interrupt service provision when the funds are exhausted. 139 Note that these capabilities are typically used in scenarios where 140 the subscriber maintains a prepaid account with the service provider; 141 hence, this extension is called the "prepaid" extension for RADIUS. 142 The functionality described in this document is often referred as 143 "online charging" in comparison to "offline charging" support 144 provided by RFC 2866 [RFC2866]. 146 The extensions were designed with the following goals in mind: 148 o Make use of existing infrastructure as much as possible (including 149 enabling the interworking of RADIUS-based and Diameter-based 150 infrastructures), and thereby limit the amount of necessary 151 capital expenditures, 153 o provide the ability to rate service requests in an "online" 154 fashion, 156 o provide the ability to charge the user's account prior to service 157 provision, 159 o protect against revenue loss, i.e., to prevent an end user from 160 obtaining service when the available funds do not suffice, 162 o protect against fraud, and 164 o be deployable for a number of services independent of the access 165 network technology. 167 The architecture between the entities that execute the RADIUS 168 protocols, with the extensions defined in this document, assumes that 169 the rating of chargeable events does not occur in the element that 170 provides the service. Instead, the rating may be performed at a 171 dedicated server, termed the "prepaid-enabled AAA server" or simply 172 "prepaid server" (PPS). Alternatively, the actual rating may occur 173 in an entity related to this prepaid server. 175 Furthermore, this document assumes that a "quota server" is available 176 which, through co-ordination with the rating entity and an account 177 balance manager, is able to provide a quota indication for a 178 particular user when requested. This quota server may or may not 179 coexist in the prepaid server. 181 1.1. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 Prepaid Client (PPC): 189 The entity which triggers the RADIUS message exchange, including 190 the prepaid extensions defined in this document. The PPC provides 191 the service to the users, and executes the RADIUS client which, 192 for the purposes of this document, is termed the "PrePaid Client" 193 (PPC). When the prepaid service is used the PPC collects service 194 event information and reports it while the services is provided to 195 the user. This event information is sent to the PPS using the 196 extensions defined in this document. 198 Prepaid Server (PPS): 200 The entity that interacts with the PPC using the RADIUS prepaid 201 extensions defined in this document. 203 Rating Entity: 205 This entity converts the credit that is allocated by the PPS into 206 a "quota". This quota is then returned to the requesting PPC via 207 the PPS. The rating entity may also determine that during service 208 provision a tariff switch will occur. In this case the rating 209 entity will include details of when exactly tariff switch will 210 occur. 212 Quota: 214 A quota denotes the amount of granted units to be consumed without 215 performing another credit control interaction. 217 Home Network: 219 The network which contains the user profile and the user's prepaid 220 account. 222 Authorize-Only Access Request: 224 A RADIUS message of type "Access Request" (code field = 1) that 225 contains a "Service-Type" AVP (type = 6) with value "Authorize- 226 Only". 228 Offline Charging: 230 Offline charging is a process where charging information for 231 resource usage is collected concurrently with that resource usage. 232 The charging information is then passed through a chain of logical 233 charging functions. At the end of this process, Charging Data 234 Record (CDR) files are generated, which are then transferred to 235 the operator's billing domain for the purpose of subscriber 236 billing and/or inter-operator accounting (or additional functions, 237 e.g., statistics, at the operator's discretion). The billing 238 domain typically comprises post-processing systems, such as the 239 operator's billing system or billing mediation device. In 240 conclusion, offline charging is a mechanism where charging 241 information does not affect, in real-time, the service rendered. 242 [TS32240] 244 Online Charging: 246 Online charging is a process where charging information for 247 resource usage is collected concurrently with that resource usage 248 in the same fashion as in offline charging. However, 249 authorization for the network resource usage must be obtained 250 prior to the actual resource usage to occur. This authorization 251 is granted by the PPS upon request from the PPC. When receiving a 252 resource usage request, the PPS assembles the relevant charging 253 information and generates a charging event in real-time. The PPS 254 then returns an appropriate resource usage authorization. The 255 resource usage authorization may be limited in its scope (e.g., 256 volume of data or duration), therefore the authorization may have 257 to be renewed from time to time as long as the resource usage 258 persists. Note that the charging information utilized in online 259 charging is not necessarily identical to the charging information 260 employed in offline charging. In conclusion, online charging is a 261 mechanism where charging information can affect, in real-time, the 262 service rendered and therefore a direct interaction of the 263 charging mechanism with the control of resource usage is required. 264 [TS32240] 266 1.2. Overview 268 This section provides an overview of the prepaid charging models and 269 architectures, which are supported by the extensions described in 270 this document. 272 A number of models of how to charge customers for services in a 273 prepaid manner are supported: 275 o Volume-based charging (e.g., 2 Cents/KiloByte). 277 o Duration-based charging (e.g., 3 Cents/minute). 279 o Resource-based charging (e.g., 3 videos for 10 Euros) 281 o Event-based charging (e.g., 7 Cents/ring tone) . 283 This draft assumes that the user maintains a prepaid account with his 284 home network. This account may be used to fund multiple services, 285 some of which may use the extensions defined in this document, and 286 some may use other mechanisms. The interworking of these mechanisms 287 is outside the scope of this document. Similarly, the means by which 288 the subscriber obtains funds is also outside the scope of this 289 document. 291 1.2.1. Architectural Model 293 This section describes the architectural model of the protocol 294 extensions described in this document. Figure 1 describes the 295 involved entities. 297 The end user establishes a connection with one of possibly multiple 298 PPCs during service access. The selected PPC communicates with a 299 HAAA server (directly or indirectly via a broker network). 301 The interface between the HAAA and the PPS is implemented using the 302 RADIUS protocol together with the extensions described in this 303 document. However, in cases where the PPS does not implement the 304 RADIUS protocol, the implementation would have to map the 305 requirements defined in this document to a functionally equivalent 306 protocol. 308 The requesting PPC meters the consumption of the service according to 309 the instructions provided by the PPS. After service completion, or 310 on reception of a subsequent request for service, the PPS deducts the 311 corresponding amount of credit from the user account. When a user 312 terminates an on-going service, the PPC informs the PPS with a 313 suitable indication about the unused portion of the allocated quota. 314 The PPS then refunds the user account accordingly. Note that 315 multiple PPSs may be deployed for reasons of redundancy and load 316 sharing. The system may also employ multiple rating servers. 318 Service 319 Access Device Accounting 320 +----------+ +---------+ Protocol +------------+ 321 | End |<---->|+-------+|<------------>| Accounting | 322 | User | +->|| PCC || | Server | 323 | | | || ||<----+ | | 324 +----------+ | |+-------+| | +------------+ 325 | +---------+ | 326 +----------+ | | 327 | End |<--+ | 328 | User | | +----------+ 329 +----------+ +------->| | 330 Prepapid | PPS | 331 Protocol | | 332 +----------+ 334 Figure 1: Basic Prepaid Architecture 336 The PPS and the accounting server in this architecture MAY be 337 combined. The PPC must have the ability to meter the consumption of 338 a prepaid data session. This metering is typically based on time 339 (i.e., seconds) or volume (i.e., octets). 341 The device running the PPC may also have "Dynamic Session 342 Capabilities", such as the ability to terminate a data session or to 343 change the filters associated with a specific data session by 344 processing "Disconnect" messages and "Change of Authorization" 345 messages as per RFC 3576 [RFC3576]. 347 This document assumes that the PPS is used as the AAA server. There 348 are three types of AAA server, as follows. 350 The AAA server in the home network (HAAA) is responsible for 351 authentication of the subscriber. In addition, the HAAA communicates 352 with the PPS using the RADIUS protocol in order to authorize 353 subscribers. 355 This document assumes that the PPS communicates with the HAAA for the 356 purposes of authentication and authorisation. The PPS, in turn, 357 interfaces to entities which 359 o keep the subscriber's account balance (balance manager), 361 o rate access service requests in real-time (rating engine), and 363 o manage quota for a particular prepaid service (quota server). 365 The balance manager, the rating engine and the quota server belong to 366 the service provider's backend infrastructure and are outside the 367 scope of this specification. In particular, as far as this 368 specification is concerned, they are assumed to exist in the PPS. 370 Accounting messages are not needed to deliver a prepaid service. 371 However, accounting messages can be used to keep the PPS up-to-date 372 as to what is happening with the prepaid data session. 374 1.2.2. Motivation 376 Why not use existing RADIUS attributes to construct a protocol for 377 prepaid scenarios? This could lead to a solution where no code has 378 to be modified at existing devices. 380 It is indeed possible to construct a solution for prepaid scenarios 381 using existing RADIUS attributes. The RADIUS server would send an 382 Access-Accept message containing a Session-Timeout(27) and include a 383 Termination-Action(29) in the RADIUS-request. Upon receiving the 384 Access-Accept message, the NAS would meter the duration of the 385 session and upon termination of the session the NAS would generate an 386 Access-Request message again. The RADIUS server would then re- 387 authenticate the session and reply with an Access-Accept message 388 indicating the amount of additional time in a Session-Timeout(27). 389 Alternatively, it could respond with an Access-Reject message if 390 there were no more resources in the user account. 392 Moreover, if the user terminates the session prematurely, the NAS 393 could indicate this in the accounting stream so that unused funds can 394 be returned into the prepaid user account. 396 Unfortunately, the above "solution" has a number of drawbacks, 397 including the following. 399 o It only supports time-based charging. The solution presented in 400 this document supports multiple charging metrics. 402 o Using accounting messages to recoup unused time may be problematic 403 because RADIUS accounting messages are not delivered in real-time. 404 A RADIUS server may store-and-forward accounting messages in 405 batches. Thus, relying on accounting messages for the purposes of 406 prepaid may cause revenue leakage. The solution presented in this 407 document does not rely on Accounting packets at all. It uses 408 Access-Request messages, which are required to flow through any 409 network in real-time. 411 o Session-Timeout(27) is not a mandatory attribute. If a prepaid 412 subscriber is served by a NAS that does not adhere to Session- 413 Timeout then that subscriber may use the service for an 414 undetermined period of time. 416 o Termination-Action(29) presents its own issues. Firstly, the 417 behaviour of Termination-Action(29) is not mandatory. Secondly, 418 according to RFC 2865 [RFC2865], Termination-Action fires when the 419 provision of the service has completed. However, service should 420 not be terminated when negotiating additional quota, because this 421 should happen in a manner transparent to the subscriber. Due to 422 the fact that Termination-Action occurs when the service is 423 completed, it is unclear whether or not user experience would be 424 affected if this attribute would be used in a prepaid scenario. 425 The RADIUS server might even allocate a new IP address to the 426 subscriber device after a Termination-Action. Also, the RADIUS 427 server has no way of telling why a given Access-Request message 428 was generated. The RADIUS server might have to wait for the 429 corresponding accounting packet to determine the reason. Finally, 430 re-authenticating the subscriber may take too long. The solution 431 presented in this document allows quota replenishing to occur 432 without affecting user experience. No re-authentication is 433 required and quotas can be negotiated before the available credit 434 actually runs out. 436 o Due to the fact that the standard RADIUS attributes are not 437 mandatory, the correct prepaid operation is really an act of faith 438 on the part of the RADIUS server. If Session-Timeout(27) and/or 439 Termination-Action(29) are not supported, the prepaid subscriber 440 might be able to obtain the service for free. The solution 441 described in this document requires that a PPC informs the RADIUS 442 server, regardless of whether or not the latter supports the 443 prepaid extensions. The RADIUS server can then determine whether 444 or not service should be granted. For example, if a prepaid 445 subscriber is connected to a NAS that does not support prepaid, 446 the RADIUS server can either instruct the NAS to tunnel the 447 traffic to another entity in the home network (e.g., an Home 448 Agent) that supports prepaid, or cause it to provide only a 449 restricted service. 451 The solution presented in this document requires the support of two 452 mandatory and one optional attribute. Furthermore, it does not 453 require a great amount of additional code at a NAS (or similar 454 device) that already supports time or volume-based metering. The 455 solution requires that RADIUS entities advertise their prepaid 456 capabilities in an Access-Request and that they generate an Access- 457 Request packet with Service-Type="Authorize-Only" in order to obtain 458 more quota when or before the current quota is used up. It also 459 requires the NAS to send an Access-Request with Service- 460 Type="Authorize-Only" when the session terminates in order to refund 461 the subscriber account. 463 1.3. Assumptions 465 This document makes the following assumptions. 467 o The values carried in the Service Identifiers are pre-configured 468 between the PPC and the PPS. 470 o The decision about the service rating happens at the PPS. 472 o The decision whether credit control requests for two services are 473 placed in a resource pool are made by the PPS. 475 o The decision which services belong to the same rating group are 476 pre-configured at the PPC. Once a rating group is authorized it 477 is not necessary to re-authorize an additional service that 478 belongs to the same rating group at the PPS again. 480 o A price enquiry is done purely for the purpose of providing AoC 481 for the end user, not for processing at the PPC nor to trigger any 482 specific actions. 484 1.4. Example Use Case 486 This section describes the sequence of events in an example RADIUS 487 prepaid transaction. 489 1. When an end host attaches to a network (for example, using IEEE 490 802.1X), as usual, the PPC that is servicing the subscriber uses 491 the AAA infrastructure in order to authenticate and authorize the 492 subscriber with respect to the requested service. In order to do 493 this, it sends a RADIUS Access-Request to the AAA server. This 494 Access-Request contains the subscriber's credentials and may 495 contain the prepaid capabilities of the PPC. 497 2. The authentication procedure proceeds. This may involve several 498 message exchanges, as it is the case with the Extensible 499 Authentication Protocol (EAP) [RFC2284]. Once the subscriber has 500 been successfully authenticated, the home AAA server determines 501 that the subscriber is a prepaid subscriber and requests 502 authorisation from the PPS. This request MUST include the 503 prepaid capabilities of the serving PPC. 505 3. The PPS, possibly with the help of the backend infrastructure, 506 validates that the subscriber has a prepaid account and that the 507 account is active. It further validates that the PPC has the 508 appropriate prepaid capabilities. If all is in order, the PPS 509 authorises the subscriber to use the network. Otherwise it 510 rejects the request. The decision is sent to the AAA system in 511 the form of a response message. In the case of success, this 512 message contains attributes that indicate the allocation of a 513 portion of the subscriber credit. This portion is called the 514 "initial quota" and is expressed in units of time or volume. The 515 response may also include a threshold value. Note that only a 516 portion of the user's funds is allocated because the user may be 517 engaged in other services that may draw on the same account. For 518 example, the user may be engaged in a data session and a voice 519 session. Although these two services would draw from the same 520 account, they form separate parts of the overall system. If the 521 entire quota was allocated to the data session then the user 522 would have no more funds for a voice session. 524 4. The AAA system incorporates the attributes received from the PPS 525 into an Access-Accept message that it sends to the PPC. Note 526 that the AAA system is responsible for authorizing the service 527 whereas the prepaid system is responsible for prepaid 528 authorization. 530 5. Upon receiving the Access-Response, the PPC starts the prepaid 531 data session and meters the session based on time or volume, as 532 indicated in the message. 534 6. Once the consumption approaches the allocated limit (as expressed 535 by the threshold), the PPC will request additional quota. Re- 536 authorization for additional quota flows through the AAA system 537 to the PPS. The PPS revalidates the subscriber account and 538 subtracts the previously allocated quota from the current 539 balance. If there is remaining balance, it reauthorizes the 540 request with an additional quota allotment. Otherwise, the PPS 541 rejects the request. Note that the replenishment of the quota is 542 a re-authorization procedure and does not require the subscriber 543 to authenticate himself again. 545 7. Upon receiving a re-allotment of the quota, the PPC continues to 546 provide the requested service until the new threshold is reached. 547 If the request for additional quota cannot be fulfilled then the 548 PPC lets the subscriber use the remaining quota and terminates 549 the session. Alternatively, instead of terminating the session, 550 the PPC may restrict service access in such a way that the 551 subscriber can only reach a particular web server. This web 552 server maybe used to allow the subscriber to replenish his 553 account. This restriction can also be used to allow new 554 subscribers to set up prepaid accounts in the first place. 556 8. Should the subscriber terminate the session before the quota is 557 exhausted, the remaining balance allotted to the session is 558 refunded into his account. 560 Note that the subscriber may have disconnected while the PPC is 561 waiting for the initial quota. The entire allocated quota will have 562 to be credited back to the subscribers account in this case. Also 563 note that the PPS maintains session state for the subscriber. This 564 state includes how much account balance was allocated during the last 565 quota enquiry and how much is left in the account. Therefore, it is 566 required that all messages about the session reach the same (and 567 correct) PPS. 569 For a simple message flow, along the lines of this use case, please 570 see Appendix A. 572 2. Supported Features 574 This section describes the features that are supported by the 575 extensions specified in this document. 577 2.1. Services and Quotas 579 Examples of services that the user may be using are browsing the web, 580 participating in a VoIP conversation, watching streaming video and 581 downloading a ring tone. Some operators may want to distinguish 582 between these services and to charge them at different rates and 583 meters them differently. Therefore, the prepaid solution needs to be 584 able to distinguish services, and allocate quota to the services 585 using different unit types (time, volume) and allow for those quotas 586 to be consumed at different rates. 588 +---------+ +---------+ +-------+ 589 | | 1 N | | 1 1 | | 590 | Session |<---------->| Service |<---------->| Quota | 591 | | | | | | 592 +---------+ +---------+ +-------+ 594 Figure 2: Multiple services within a single session 596 As shown in Figure 2, a session may be associated with multiple 597 services. Each service is identified by a service identifier 598 (Service-ID). The format of the Service-ID is not in the scope of 599 this document. It may, for example, be expressed as a 5-tuple {i.e., 600 source IP address, destination IP address, source port, destination 601 port, and protocol type}. Each service is associated with a quota 602 whereby a quota might be applicable to multiple services. An example 603 message flow that involves multiple services within a single session 604 is given in the Appendix A. 606 2.2. Resource Pools 608 When working with multiple services a new problem arises because one 609 service may consume its quota faster than another service. When the 610 user balance is close to exhaustion, a situation could arise where 611 one service is unable to obtain quota while another service has 612 plenty of quota remaining. Unless the quotas can be rebalanced, the 613 SAD would then have to terminate the former service. Moreover, it is 614 likely that each service generates a certain amount of RADIUS prepaid 615 traffic. In an environment with many users and charged services, 616 this amount of traffic may become a considerable overhead that could 617 lead to inefficiency. 619 One method to circumvent the above situation is to use a so-called 620 "resource pool". Resource pools enable the allocation of resources 621 to multiple services of a session by allocating resources to a pool 622 and have services draw their quota from the pool at a rate 623 appropriate to that service. When the quota that has been allocated 624 to the pool is close to exhaustion, the entire pool (rather than 625 individual services) is replenished. 627 +-----------+ 628 | Service-A |-----+ +--------+ 629 +-----------+ | Ma | | 630 +-------->| | 631 | Pool | 632 +-------->| (1) | 633 +-----------+ | Mb | | 634 | Service-B |-----+ +--------+ 635 +-----------+ 637 Figure 3: Resource pool example 639 As shown in Figure 3, Service-A and Service-B are bound to Pool(1). 640 Ma and Mb are the pool multipliers (that are associated with 641 Service-A and Service-B respectively) that determine the rate at 642 which Service-A and Service-B draw from the pool. 644 The pool is initialized by taking the quota allocated to service n 645 and multiplying it by Mn. Therefore, the amount of resources 646 allocated to a pool is given by Poolr = Ma*Qa + Mb*Qb + . . ., where 647 Qn denotes the amount of quota that is allocated to service n. 648 Further, the pool is considered to be empty if 650 Poolr <= Ca*Ma + Cb*Mb + . . ., 652 Figure 4 654 where Ca and Cb are resources consumed by Service-A and Service-B 655 respectively. 657 Note that the resources assigned to the pool are not associated with 658 a metric. That is, Service-A can be rated at $1 per MB and Service-B 659 can rated at $0.10 per minute. In this case, if $5 worth of 660 resources are allocated for service-A to the pool and if Ma = 10, 661 then 50 units would be placed into the pool. If a further $5 are 662 allocated for service-B to the pool, then M=1 and 50 units are 663 deposited into the pool. The pool would then have a total sum of 100 664 units to be shared between the two services. The PPC would then 665 mater the services such that each Mbyte used by Service-A will draw 666 10 units from the pool and each minute used by Service-B will draw 1 667 unit from the pool. 669 2.3. Rating Groups 671 A Rating Group gathers a set of services, identified by a service 672 identifier, and subject to the same cost and rating type (e.g., $0.1/ 673 minute). 675 The rating of a service can be quite complex. While some operators 676 follow linear pricing models, others may wish to apply more complex 677 functions. For example, a service provider may wish to rate a 678 service such that the first N MBytes are free, then the next M Mbytes 679 are rated at $1 per MB and volume above (N+M) MB be rated at $0.50 680 per MB. Such a function could be implemented by repeated message 681 exchanges in the prepaid system. 683 To avert the need to exchange many messages while still supporting 684 such complex rating functions, the concept of the Rating Group was 685 introduced. 687 As shown in Figure 5, a Rating Group is associated with one or more 688 services and defines the rate that the services associated with the 689 Rating Group consume an allocated amount of quota. 691 +--------------+ +--------------+ 692 +-----------+ N 1 | | M 1 | Resource Pool| 693 | Service-A +---------->| Rating Group |------>| or | 694 +-----------+ | | | Quota | 695 +--------------+ +--------------+ 697 Figure 5: Rating Group 699 During the usage of a service that is associated with a Rating Group, 700 the PPC sends the ID of the Rating Group to the PPS. The PPS 701 authorises the Rating Group by allocating a quota to it and assign it 702 to a Resource Pool. When an additional service that belongs to an 703 already authorised Rating Group is instantiated, the PPC does not 704 need to re-authorize this service. This effectively means that the 705 PPC meters the service such that it draws from the already allocated 706 quota. Therefore, no RADIUS messages need to be exchanged in this 707 case. This limits the amount of traffic between the PPC and the PPS. 708 An example of a flow that uses Rating Groups is given in Appendix A.3 710 2.4. Tariff Switching 712 Tariff is the set of parameters defining the utilization charges for 713 the use of a particular service. 715 This mechanism is useful if, for example, as shown in Figure 6, 716 traffic before 18:00 is rated at rate r1 and traffic after 18:00 is 717 rated at rate r2. The mechanism requires the PPC to report usage 718 before and after the switch occured. 720 18:00 721 ------------------+----------------- 722 r1 | r2 723 ------------------+----------------- 724 ^ ^ 725 |<----TSI---> | 726 | | 727 Access-Accept Access-Request 728 (quota allocated) (quota consumed) 730 Figure 6: Example of Tariff Switching 732 The PPC indicates support for tariff switching by setting the 733 appropriate bit in the PPAC. If the PPS needs to signal a tariff 734 switch time it will send a PTS attribute that indicates the point in 735 time when the switch will occur. This indication represents the 736 number of seconds from current time (TariffSwitchInterval TSI). 738 At some point after the tariff switch the PPC sends another Access- 739 Request, as a result of either the user having logged off or the 740 volume threshold being reached. The PPC reports how much volume was 741 used in total (in a PPAQ attribute) and how much volume was used 742 after the tariff switch (in a PTS VUATS subtype attribute). 744 In situations with multiple tariff switches, the PPS has to specify 745 the length of the tariff switch period using the 746 TimeIntervalAfterTariffSwitchUpdate (TITSU) field in the PTS 747 attribute, as shown in Figure 7. 749 18:00 23:30 750 ------------------+---------------------+-------------- 751 r1 | r2 | r3 752 ------------------+---------------------+-------------- 753 ^ ^ ^ 754 |<----TSI---><-----------|-------->|TITSU 755 | | 756 Access-Accept Access-Request 758 Figure 7: Multiple Tariff Switches 760 When a TITSU is specified in the PTS, the PPC MUST generate an 761 Access-Request within the time after TSI and before TITSU expires. 762 Note that, typically, the PPC will be triggered by the Volume 763 Threshold. However, it is possible that, during period r2, resources 764 are not entirely consumed and, thus, the threshold is not reached. 765 The TITSU attribute ensures that, even in this case, the PPC will 766 generate the new Access-Request in good time. 768 For time based services, the quota is continuously consumed at the 769 regular rate of 60 seconds per minute. At the time when credit 770 resources are allocated, the server already knows how many units will 771 be consumed before the tariff time change and how many units will be 772 consumed afterward. Similarly, the server can determine the units 773 consumed at the before rate and the units consumed at the rate 774 afterward in the event that the end user closes the session before 775 the consumption of the allotted quota. There is no need for 776 additional traffic between the PPC and the PPS in the case of tariff 777 time changes for continuous time based service. Therefore, the 778 tariff change mechanism is not used for such services. For time- 779 based services in which the quota is not continuously consumed at a 780 regular rate, the tariff change mechanism described for volume and 781 event units may be used. 783 2.5. Support for Roaming 785 In certain networks it is essential for prepaid data services to be 786 available to roaming subscribers. Support for both static and 787 dynamic roaming models is needed. In a static roaming scenario the 788 subscriber connects to a foreign network which has a roaming 789 agreement either directly with the home network, or through a broker 790 network. When the subscriber logs into another foreign network, a 791 new login procedure has to be executed. 793 In a dynamic roaming scenario the subscriber may move between 794 networks while maintaining his connection. In such a scenario the 795 data session is seamlessly handed off between the networks. 797 In both roaming scenarios, the subscriber always authenticates 798 himself to the home network. Authorization for the prepaid session 799 and quota replenishing occurs at the home network and more 800 specifically at the PPS where state is being maintained. 802 Roaming is challenging because a subscriber who established a prepaid 803 data session may move to another PPC that does not support the 804 prepaid extensions. 806 2.6. Dynamic Termination 808 When fraud or an error is detected, either only the affected session, 809 or all sessions of the affected subscriber should be immediately 810 terminated. Under certain conditions, the system may wish to 811 terminate the session in order to make sure that the user is not 812 charged for services it does not use. 814 Certain handoff procedures used in dynamic roaming scenarios require 815 that the system terminates the subscribers prepaid data session at a 816 PPC. This is the case, for example, when time-based prepaid is used 817 and the mobile subscriber performs a dormant handoff. 819 2.7. One Time Event 821 2.7.1. One-Time Charging 823 One-time charging is a mode of operation where the RADIUS prepaid 824 extensions are used for charging of a service that is provided 825 instansteneously. An example of such an event is the purchase of a 826 ring tone. Subscription based services can also be modeled as a one- 827 time event. In this case the one-time service event is the purchase 828 of a subscription. 830 For a given user, one-time charging may occur in parallel with other 831 charging models. For example, the subscriber may be connected to the 832 Internet, which is metered (based on time or volume), while he also 833 purchases a ring tone (a one-time-based event). 835 Note that it is up to the service providers to decide whether or not 836 the user will be charged for the download of, for example, the video 837 and also be charged for the data volume required to download the 838 video. The facilities provided by this document gives the service 839 provider the capability to achieve their service charging business 840 goals. 842 The PPC signals one-time charging to the PPS with an indication that 843 identifies the service and the units that should be debited from the 844 user account. 846 A PPC may decide to perform one-time charging and the PPC may need to 847 authenticate the user before sending the relevant message to the 848 user's home AAA server (and to the PPS). 850 Note that one-time charging can also be used to credit the prepaid 851 account. For example, the PPC can return resources to the subscriber 852 by issuing a one-time charging request that includes the amount of 853 resources to be credited into the account. 855 2.7.2. Resource Consumption Query 857 It should be possible for the PPS to query the PPC for the current 858 resource consumption and to adjust the users account balance. For 859 example, a request to the PPS is made (e.g., a one-time charging 860 event), the account is depleted and resources have been allocated to 861 the PPC. The PPS should have the ability to query the PPC and, if it 862 has the spare resources, to reassign the quotas to the PPC and to the 863 pending request. Note that the PPS does not know resource usage 864 until the PPC request for more resources. This can be a long time. 866 In the absence of this capability the PPS can minimize the effect of 867 this phenomenon by allocating small quotas, a practice that results 868 in more message exchanges. 870 2.7.3. Service Price Enquiry 872 The PPC may need to know the price of the service event. Services 873 offered by application service providers whose prices are not known 874 in the PPC might exist. The end user might also want to get an 875 estimation of the price of a service event before requesting it. 877 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 878 with the value set to "Price Enquiry" (2). The request includes 879 enough information to identify the service, namely a Service- 880 Identifier or a Rating-Group-Identifer. 882 The PPS calculates the cost of the requested service event, but it 883 does not perform any account balance check or credit reservation from 884 the account. 886 The estimated cost of the requested service event is returned to the 887 PPS with a PPAQ in the Cost-Information SubType. The PPC may 888 transfer the information to the end user as an advice of charge. 890 More information regarding the price enquiry functionality is 891 provided in Section 4.3.17 and in Section 4.3.19. 893 2.7.4. Balance Check 895 The PPC may only have to verify that the end user's account balance 896 covers the cost of a certain service without reserving any units from 897 the account at the time of the inquiry. This method does not 898 guarantee that credit would be left when the PPC requests the 899 debiting of the account with a separate request. 901 A PPC issues a PPAQ to the PPS including the Requested-Action SubType 902 with the value set to "Balance Check" (1). The request includes 903 enough information to identify the service, namely a Service- 904 Identifier or a Rating-Group-Identifer. 906 The PPS makes the balance check, but it does not make any credit- 907 reservation from the account. 909 The result of balance check, namely "Success" (1) or "Failure" (2), 910 is returned to the PPC in the Check-Balance-Result SubType conveyed 911 in the PPAQ attribute from the PPS to the PPC. 913 More information regarding the balance check functionality is 914 provided in Section 4.3.17 and in Section 4.3.18. 916 2.7.5. Refund 918 Some services may refund service units to the end user's account; for 919 example, gaming services. 921 To initiate refunding the PPC includes the PPAQ attribute in an 922 Access-Request packet and the amount (as a negative value) to be 923 refunded is specified using the Resource Quota and Resource Quota 924 overflow subtypes. This functionality is similar to one-time 925 charging with the difference that refunding uses negative values 927 Information about the service need to be provided by the PPC to allow 928 service identification, namely the Service-ID field of the PPAQ 929 identifies the prepaid service. 931 Note that a monetary amount itself to be refunded is not provided but 932 rather abstract units. Based on prior out-of-band agreements between 933 the PPC and the PPS these abstract units are translated into a 934 monetary amount. 936 More information regarding the refund functionality is provided in 937 Section 3.8.6. 939 3. Operations 941 This section contains the normative text for the prepaid extension. 943 3.1. Capability Discovery 945 The PPC initiates the authentication and authorization procedure by 946 sending a RADIUS Access-Request to the HAAA. Since the PPC MUST 947 include a PPAC attribute in the RADIUS Access-Request. The PPAC 948 attribute indicates to the PPS which prepaid capabilities are 949 possessed by the PPC. These are required in order to complete the 950 prepaid authorization procedure.Moreover, if the PPC supports the 951 Disconnect-Message or the Change-of-Authorization capabilities, then 952 it SHOULD include the Session Termination attribute. 954 In certain deployments, there may be other ways to terminate a data 955 session, or change authorization of an active session. For example, 956 some PPCs provide a session termination service via Telnet or SNMP. 957 In these cases, the AAA server MAY add the Dynamic-Capabilities 958 message to the Access-Request. Upon receiving the Change-of- 959 Authorization message, the AAA server would then be responsible for 960 terminating the session using the means that are supported by the 961 device. 963 If the authentication procedure involves multiple message exchanges 964 (as it is the case with EAP), the PPC MUST include the PPAC attribute 965 in at least the last Access-Request of the authentication procedure. 967 3.2. Authentication and Authorization Operation 969 Once the Access-Request arrives at the HAAA, the HAAA authenticates 970 the subscriber. If this fails, the HAAA sends an Access-Reject 971 message to the client. If authentication succeeds, the HAAA 972 determines whether or not the subscriber is a prepaid subscriber. If 973 the subscriber is not a prepaid subscriber, then the HAAA responds as 974 usual with an Access-Accept or an Access-Reject message. If the 975 subscriber is a prepaid subscriber then the HAAA MAY forward the 976 Access-Request to the PPS for further authorization. 978 The Access-Request contains the PPAC attribute and the Dynamic- 979 Capabilities attribute if one was included. The User-Name(1) 980 attribute MAY be set to a value that identifies the subscriber. This 981 attribute is used by the PPS to locate his account. For added 982 security, the HAAA MAY also set the User-Password(2) attribute to the 983 password used between the HAAA and the PPS. 985 The PPS locates the subscriber account and authorizes him. During 986 this procedure, the PPS takes into consideration the PPCs 987 capabilities. Upon successful authorization, the PPS generates an 988 Access-Accept containing an PPAC attribute and an PPAQ attribute. 989 The PPAC attribute returned to the client indicates the type of 990 prepaid service to be provided for the session. The PPAQ attribute 991 includes the following information. 993 o The QID, which is set by the PPS to a unique value, is used to 994 correlate quota requests. 996 o Volume and/or Time quota, which is set to a value representing a 997 portion of the subscriber's credit. 999 o Time or Volume Threshold that indicates when the PPC should 1000 request additional quota. This information is optional. 1002 o The IP address of the serving PPS and one or more alternative 1003 PPSs. This is used by the HAAA to route subsequent quota 1004 replenishing messages to the appropriate PPS(s). 1006 o A State attribute, as defined in RFC 2865 [RFC2865]. This is 1007 necessary in order to satisfy the requirements of Section 5.44 of 1008 RFC 2865 [RFC2865], which mandates that an Access-Request with 1009 Service-Type="Authorize-Only" must contain a State attribute. 1010 Since the PPC sends subsequent quota replenishment requests in the 1011 form of such "Authorize-Only" requests, a State attribute MUST be 1012 present in all Access-Accept messages that also carry a PPAQ 1013 attribute. 1015 Note: The Idle-Timeout(28) attribute can be used to trigger the 1016 premature termination of a prepaid service, for example as a result 1017 of inactivity. 1019 Depending on site policies, after failed authorization, the PPS may 1020 generate an Access-Reject in order to terminate the session 1021 immediately. Alternatively, the PPS may generate an Access-Accept 1022 blocking some or all of the traffic and/or redirect some or all of 1023 the traffic to a location to a fixed server. (This feature could be 1024 used, for example, to prompt the user to replenish their account.) 1025 Blocking of traffic is achieved by either Filter-ID(11) or NAS- 1026 Filter-Rule (see [I-D.ietf-radext-filter-rules]). A description of 1027 the redirect functionality is outside the scope of this document. 1028 The time period before the session is blocked/redirected is specified 1029 by the Session-Timeout(27) attribute. 1031 Upon receiving an Access-Accept from the PPS, the HAAA appends the 1032 usual service attributes and forward the packet to the PPC. The HAAA 1033 SHOULD NOT overwrite any attributes already set by the PPS. If the 1034 HAAA receives an Access-Reject message, it will simply forward the 1035 packet to its client. Depending on site policies, if the HAAA does 1036 not receive an Access-Accept or an Access-Reject message from the PPS 1037 it MAY do nothing or send an Access-Reject or an Access- Accept 1038 message back to the PPC. 1040 3.3. Session Start Operation 1042 The start of the session is indicated by the arrival of an 1043 Accounting-Request(Start) packet. The Accounting-Request (Start) MAY 1044 be routed to the PPS such that it can confirm the initial quota 1045 allocation. 1047 Note that the role of the PPS is not to record accounting messages 1048 and therefore it SHOULD NOT respond with an Accounting Response 1049 packet. If the PPS does not receive the Accounting-Request(start) 1050 message it will only know that the session has started upon the first 1051 reception of a quota replenishment operation. 1053 If the PPS does not receive indication directly (via Accounting- 1054 Request(start)) or indirectly, it SHOULD, after some configurable 1055 time, deduce that the session has not started. If the PPC supports 1056 termination capabilities, the PPS SHOULD send a Disconnect Message to 1057 the PPC as a measure to ensure that the session is indeed dead. 1059 3.4. Mid-Session Operation 1061 During the lifetime of a prepaid data session the PPC may request the 1062 replenishment of the quotas using an Authorize-Only Access-Request 1063 message. Once either the allocated quota has been exhausted or the 1064 threshold has been reached, the PPC MUST send an Access-Request with 1065 Service-Type(6) set to a value of "Authorize-Only" and the PPAQ 1066 attribute. 1068 The PPC MUST also include NAS identifiers, and Session Identifier 1069 attributes in the Authorize-Only Access-Request. The Session 1070 Identifier should be the same as the one used during the initial 1071 Access-Request. For example, if the User-Name(1) attribute was used 1072 in the Access-Request it has to be included in the Authorize-Only 1073 Access-Request as well, especially if the User-Name(1) attribute is 1074 used to route the Access-Request to the Home AAA server. 1076 The Authorize-Only Access-Request MUST NOT include a User Password 1077 and MUST NOT include a CHAP Password. In order to enable the 1078 receiver to authenticate the message, the PPC MUST include a Message- 1079 Authenticator(80). In order to satisfy the requirements of Section 1080 5.44 of RFC 2865 [RFC2865], the PPC MUST also include the State 1081 attribute. It is anticipated that the inclusion of the State 1082 attribute will enable the PPS to map the Authorize-Only Access 1083 Request to the authentication context that was established when the 1084 PPC authenticated itself at the beginning of the session. The PPC 1085 computes the value for the Message-Authenticator and the State 1086 attributes according to RFC 2869 [RFC2869] and RFC 2865 [RFC2865] 1087 respectively. 1089 When the HAAA receives an Authorize-Only Access-Request that contains 1090 a PPAQ, it validates the message using the Message-Authenticator(80), 1091 according to RFC 2869. If the HAAA receives an Authorize-Only 1092 Access-Request that contains a PPAQ and either no or an invalid 1093 Message-Authenticator(80) it SHALL silently discard the message. An 1094 Authorize Only Access-Request message that does not contain a PPAQ is 1095 either erroneous or belongs to another application (for example, a 1096 Change of Authorization message [RFC3576]). In this case the 1097 Authorize-Only Access-Request is either silently discarded or handled 1098 by another application. 1100 Once the Authorize-Only Access-Request message is validated, the HAAA 1101 SHALL forward the Authorize-Only Access-Request to the appropriate 1102 PPS. The HAAA MUST forward the Authorize-Only Access-Request to the 1103 PPS specified in the PPAQ. The HAAA MUST add a Message- 1104 Authenticator(80) to the message, according to RFC 2869. As with the 1105 Access-Request message, the HAAA MAY modify the User-Name(1) 1106 attribute such that it identifies the user to the PPS. 1108 When the PPS receives the Authorize-Only Access-Request containing a 1109 PPAQ attribute, it MUST validate the Message-Authenticator(80) as 1110 described in RFC 2869. If validation fails, the PPS MUST silently 1111 discard the message. If it receives an Authorize-Only Access-Request 1112 message that does not contain a PPAQ, it MUST silently discard the 1113 message. 1115 The PPS locates the prepaid session state and uses the QID contained 1116 within the PPAQ to detect replays. The PPS takes the most recently 1117 allocated quota and subtracts it from the user balance. If 1118 sufficient balance remains, the PPS authorizes the PPS and allocates 1119 additional quota. The PPS may also calculate a new threshold value. 1120 Upon successful re-authorization, the PPS generates an Access-Accept 1121 containing the PPAQ attribute. 1123 Depending on site policies, upon unsuccessful authorization, the PPS 1124 generates an Access-Reject or an Access-Accept with Filter-Id(11) or 1125 Ascend-Data-Filter attribute (if supported) and the Session- 1126 Timeout(27) attribute such that the subscriber can get access to a 1127 restricted set of locations for a short period of time. This feature 1128 could be used to enable users to replenish their accounts, create new 1129 accounts, or to access free content. 1131 Upon receiving an Access-Accept from the PPS, the HAAA forwards the 1132 message to its client. If the HAAA receives an Access-Reject 1133 message, it forwards the message. Depending on site policies, if the 1134 HAAA does not receive an Access-Accept or an Access-Reject message 1135 from the PPS it MAY do nothing or it MAY send an Access-Reject 1136 message back to its client. 1138 Upon receiving an Access-Accept, the PPC updates its quotas and 1139 threshold parameters with the values contained in the PPAQ attribute. 1140 Note that the PPS MAY update the PrePaidServer attribute(s) and these 1141 may have to be saved as well. If the Access-Accept message contains 1142 a Filter-Id(11), an Ascend-Data-Filter attribute, or Session 1143 Timeout(27), the PPC SHALL restrict the subscriber session 1144 accordingly. 1146 3.5. Dynamic Operations 1148 The PPS may take advantage of the dynamic capabilities that are 1149 supported by the PPC as advertised in the Dynamic-Capabilities 1150 attribute during the initial Access-Request. There are two types of 1151 actions that the PPS may perform. Firstly, it may request the 1152 session to be terminated. Secondly, it may request the attributes 1153 associated with the session to be modified. More specifically, it 1154 may modify a previously sent PPAQ. 1156 Both of these actions require that the session be uniquely identified 1157 at the PPC as described in [RFC3576]. 1159 3.5.1. Unsolicited Session Termination Operation 1161 At anytime during a session the PPS may send a Disconnect Message in 1162 order to terminate a session, see in [RFC3576]. Upon successful 1163 termination of a session the PPC MUST return any unused quota to the 1164 PPS by issuing an Authorize-Only Access-Request containing the PPAQ 1165 which contains any unused quota and the Update-Reason set to "Remote 1166 Forced Disconnection". 1168 3.5.2. Unsolicited Change of Authorization Operation 1170 At any time during the session the PPC may receive a Change of 1171 Authorization (CoA) message. A PPS may send a new quota to either 1172 add or to remove quota that is allocated to the service. If the 1173 Change of Authorization contains a PPAQ then that PPAQ overrides a 1174 previously received PPAQ. The PPS MUST NOT change the units used in 1175 the PPAQ. 1177 If the newly received PPAQ reduces the amount of allocated quota 1178 beyond what is already used then the PPC accepts the new PPAQ and act 1179 as it normally would when the quota is used up. For example, if the 1180 threshold is reached then is request a quota update. 1182 3.6. Termination Operation 1184 The termination phase is initiated when (i) the subscriber logs off, 1185 (ii) the subscriber balance is exhausted, or (iii) when the PPC 1186 receives a Disconnect Message. 1188 In case the user logged off, or the PPC receives a Disconnect 1189 Message, the PPC sends an Authorize-Only Access-Request message with 1190 a PPAQ and Update-Reason attribute set to either "Client Service 1191 Termination" or "Remote Forced Disconnect". This message indicates 1192 the amount of consumed quota. 1194 In case the currently allocated quota is exhausted, if the PPAQ 1195 contained the Termination-Action subytype, the PPC follows the 1196 specified action. 1198 3.7. Mobile IP Operations 1200 In roaming scenarios with Mobile-IP, the prepaid data session should 1201 be maintained transparently if the HA is acting as the access device 1202 hosting the PPC. As the subscriber device associates with a new 1203 access service device (AP or PDSN that supports PPC capability), this 1204 service access device sends a RADIUS Access-Request and the 1205 subscriber is re-authenticated and reauthorized. The service access 1206 device SHALL include the PPAC attribute in the RADIUS Access-Request. 1207 In this manner, the procedure follows the Authentication and 1208 Authorization procedure described earlier. 1210 If the HA was acting as the service access device before handoff, 1211 then the prepaid session does not undergo any change after the 1212 handoff because the Mobile IP session is anchored at the HA and the 1213 user's Home IP address does not change. 1215 In the case of a wireless access point or PDSN acting as the service 1216 access device, it is likely that the user's (care-of) IP address will 1217 change. The prepaid session will be affected by this. In this 1218 scenario the service access device shall send an Access-Request 1219 message which is routed to the home network and SHALL reach the PPS 1220 that is serving this session. The PPS correlates the new 1221 authorization request with the existing active session and assigns a 1222 quota to the new request. Any outstanding quota at the old service 1223 access device SHALL be returned to the PPS if the Mobile-IP nodes (HA 1224 and FA) support registration revocation (Mobile IPv4 only). 1225 Specifically, the quota SHOULD be returned when the service access 1226 device sends the Authorize-Only Access-Request with PPAQ Update- 1227 Reason set to either "Remote Forced Disconnect" or "Client Service 1228 Termination". In order to trigger the sending of this last 1229 Authorize-Only Access- Request, the PPS may issue a Disconnect 1230 Message [3576] to the service access device. 1232 Even if the subscriber moves to a service access device that does not 1233 have prepaid capabilities can the prepaid data service continue. 1234 This can be done by requesting the Home Agent (assuming it has such 1235 capabilities) to take over the responsibilities of the service access 1236 device (i.e. metering). This scenario will be discussed in detail in 1237 a later version of this document. 1239 3.8. Operation Considerations for Multiple Services 1241 This section describes the support for multiple prepaid services on a 1242 single PPC. Message flows illustrating the various interactions are 1243 presented in Appendix A. 1245 A PPC that supports prepaid operations for multi-services SHOULD set 1246 the "Multi-Services Supported" bit in the PPAC. When working with 1247 multi-services, we need to differentiate between the services. A 1248 Service-Id attribute is used in the PPAQ in order to uniquely 1249 differentiate between the services. The exact definition of the 1250 Service-Id attribute is outside the scope of this document. 1252 A PPAQ that contains a Service-Id is associated with that service. A 1253 PPAQ that contains a Rating-Group-Id is associated with that Rating- 1254 Group. A PPAQ MUST NOT contain both a Rating-Group-Id and a 1255 Service-Id. A PPAQ that contains neither a Rating-Group-Id nor a 1256 Service-Id then the default service is used, i.e., the "Access 1257 Service". 1259 3.8.1. Initial Quota Request 1261 When operations with multiple services is desired then the PPC 1262 requests the initial quota by sending a PPAQ containing the 1263 Service-Id in an Authorize-Only Access-Request packet for that 1264 service. Similarly, if the PPC supports rating groups then it may 1265 request a quota for the rating group by sending a PPAQ containing the 1266 Rating-Group-Id. In both cases the Update-Reason is set to "Initial- 1267 Request". The Authorize-Only Access-Request message MAY contain more 1268 than one PPAQ. 1270 Upon receiving an Authorize-Only Access-Accept message containing one 1271 or more PPAQs, the PPS allocates resources to each PPAQ. Each PPAQ 1272 is assigned a unique QID that MUST appear in subsequent PPAQ updates 1273 for that service or rating group. Additionally, the PPAQ MUST 1274 contain the Service-ID or Rating-Group-Id, unless the PPAQ is the 1275 generic "Access Service". 1277 3.8.2. Quota Update 1279 Once the services start to utilize their allotted quota they will 1280 eventually need to replenish their quotas (either the threshold is 1281 reached or no more quota remains). In order to replenish the quota, 1282 the PPC sends an Authorize-Only Access-Request message containing one 1283 or more PPAQs. Each PPAQ MUST contain the appropriate QID, 1284 Service-ID or Rating-Group-Id (or neither the Service-ID or Rating- 1285 Group-Id if the quota replenishment is for the "Access Service"). 1286 The Update-Reason filed indicates either "Threshold reached"(3), or 1287 "Quota reached"(4). 1289 Upon receiving an Authorize-Only Access-Request packet with one or 1290 more PPAQs the PPS responds with a new PPAQ for that service. The 1291 PPAQ contains a new QID, the Service-Id or the Rating-Group-Id, and a 1292 new QID. If the PPS does not grant additional quota for the service 1293 it MUST include the Termination-Action subfield in the PPAQ that will 1294 instruct the PPC to take appropriate actions. 1296 3.8.3. Termination 1298 When the allotted quota for a service is exhausted, the PPC shall act 1299 in accordance with the flags set in the Termination-Action subtype. 1300 If the Termination-Action subtype is absent then the service MUST be 1301 terminated. If the service is to be terminated, then the PPC shall 1302 send a PPAQ with the appropriate QID, the Service-Id, the used quota, 1303 and the Update-Reason set to "Client Service Termination". 1305 If the "Access Service" has terminated, then all other services must 1306 be terminated as well. In this case the PPC MUST report on all 1307 issued quotas for the various services. The Update-Reason field 1308 should be set to "Access Service Terminated". 1310 3.8.4. Dynamic Operations 1312 Dynamic operations for multi-services are similar to dynamic 1313 operations described for single service operations. The PPS MAY send 1314 a COA message containing a PPAQ for an existing service instance. 1315 The PPC matches the PPAQ with the service using the Service-ID or the 1316 Rating-Group-Id attribute. The new quota could differ from the 1317 previously allocated value. 1319 A disconnect message terminates the "Access Service". As such the 1320 PPC MUST report all unused quotas by sending an Authorize-Only Access 1321 Request message containing a PPAQ for each active service. The 1322 Update-Reason MAY indicate that the reason for the update. 1324 3.8.5. Support for Resource Pools 1326 If the PPC supports pools as indicated by setting the "Pools 1327 supported" bit in the PPAC then the PPS may associate a quota with a 1328 Pool by including the Pool-Id and the Pool-Multiplier in the PPAQ. 1329 When Resource Pools are used, the PPAQ MUST NOT use the threshold 1330 field. 1332 3.8.6. One-time Charging 1334 To initiate one-time charging the PPC includes the PPAQ attribute in 1335 an Access-Request packet. The Service-ID field of the PPAQ 1336 identifies the prepaid service. The amount to be charged is 1337 specified using the Resource Quota and Resource Quota overflow 1338 subtypes. If the value specified is negative then the resources are 1339 credited to the user account. This functionality corresponds to 1340 refunding. 1342 The QID subtype MUST be set to a unique value and is used by the PPS 1343 to detect duplicates. The Update Reason field MUST be set to One- 1344 Time Charging. Upon receiving a One-Time charge PPAQ, the RADIUS 1345 server authenticates the user and, if successful, passes the PPAQ to 1346 the PPS. The PPS locates the account and debits or credits it 1347 accordingly. The PPS MUST respond to the PPS with an Access-Accept 1348 message if successful, or an Access-Reject message otherwise. 1350 In case of a successful operation the HAAA forwards the message to 1351 the PPC with an Access Accept message. Since this is a one-time 1352 charge the PPC MUST NOT allow the session to continue. Therefore, 1353 the RADIUS server SHOULD include in the Access-Accept a Session- 1354 Timeout set to 0. Upon receiving an Access-Accept response the PPC 1355 SHOULD generate an Accounting Stop message. 1357 A PPAQ used for One-Time charging MAY appear in an Authorize-Only 1358 Access Request. This is the case when the session already exists. 1359 The PPS responds with an Access-Accept to indicate that the user 1360 account has been debited or an Access-Reject otherwise. 1362 3.8.7. Error Handling 1364 If the PPS receives a PPAQ with an invalid QID it MUST ignore that 1365 PPAQ. 1367 If the PPS receives a PPAQ containing a Service-Id, or a Rating- 1368 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1370 If the PPC receives a PPAQ containing a Service-Id, or a Rating- 1371 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1373 If the PPC receives a PPAQ that contains a Pool-Id without a Pool- 1374 Multiplier or a Pool-Multiplier without a Pool-Id it MUST ignore that 1375 PPAQ. 1377 3.8.8. Accounting Considerations 1379 Although typically generated, accounting messages are not required to 1380 deliver a prepaid data service. When generated, accounting messages 1381 are used for auditing purposes and for billing. Accounting messages 1382 associated with prepaid data sessions should include the PPAQ 1383 attribute. 1385 4. Attributes 1387 This section specifies the attributes that implement the RADIUS 1388 extensions for prepaid. 1390 4.1. PrePaid Accounting Capability (PPAC) Attribute 1392 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1393 Access-Request message by a PPC to describe its prepaid capabilities. 1395 0 1 2 3 1396 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 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | TYPE | LENGTH | SubType (1) | LENGTH | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | AvailableInClient (AiC) | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | AvailableInClient-Extended (AiC-ext) | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 TYPE : IANA registered value of PPAC attribute 1406 LENGTH: 8 1407 VALUE : Data type String 1409 The value field is encoded as follows: 1411 SubType : Value (1) 1412 Length : 6 or 10 octets 1414 AvailableInClient (AiC): The bitmap is encoded as: 1416 Value | Description 1417 ------------ -+------------------------------------- 1418 0x00000001 | Volume metering supported 1419 0x00000002 | Duration metering supported 1420 0x00000004 | Resource metering supported 1421 0x00000008 | Pools supported 1422 0x00000010 | Rating groups supported 1423 0x00000020 | Multi-Services supported 1424 0x00000040 | Tariff Switch supported 1425 Others | Reserved 1427 Figure 8: PPAC Attribute 1429 4.2. Session Termination Attribute 1431 The value shall be bitmap encoded rather than a raw integer. This 1432 attribute shall be included RADIUS Access-Request message to the 1433 RADIUS server and indicates whether or not the NAS supports Dynamic 1434 Authorization. 1436 0 1 2 3 1437 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 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | TYPE | LENGTH | String | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 Type : value of Session Termination Capability 1443 Length: = 4 1444 String encoded as follows: 1446 0x00000001 Dynamic Authorization Extensions (rfc3576) is 1447 supported. 1449 Figure 9: Session Termination Attribute 1451 4.3. Prepaid Accounting Operation (PPAQ) Attribute 1453 One or more PPAQ attributes are sent in an Access Request, Authorize- 1454 Only Access-Request and Access-Accept message. In an Access Request 1455 message, the PPAQ attribute is used to facilitate one-time charging 1456 transactions. In Authorize-Only Access-Request messages it is used 1457 for one-time charging, report usage and to request further quota. It 1458 is also used in order to request prepaid quota for a new service 1459 instance. In an Access-Accept message it is used in order to 1460 allocate the (initial and subsequent) quotas. 1462 When multiple services are supported, a PPAQ is associated with a 1463 specific service as indicated by the presence of a Service-Id, a 1464 Rating-Group-Id, or the "Access Service" (as indicated by the absence 1465 of both, the Service-Id and the Rating-Group-Id). 1467 Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes MUST 1468 appear in the PPAQ attribute, except for the price enquiry message 1469 exchange where these subtypes MUST be absent. A single PPAQ 1470 attribute MUST NOT contain more than one Service-Id, MUST NOT contain 1471 more than one Rating-Group-Id, and MUST NOT contain both a Service-Id 1472 and a Rating-Group-Id. A PPAQ that does not contain a Service-ID or 1473 a Rating-Group-Id refers to the "Access Service". A PPAQ MUST NOT 1474 contain more than one Pool-Id. A PPAQ that contains a Pool-Id MUST 1475 also contain a Pool-Multiplier SubType. 1477 The PPAQ attribute has a variable length (greater than 8, encoded 1478 into one octet), and consists of a variable number of subtypes. 1479 Unused subtypes are omitted from the message. In the following 1480 subsections the various subtypes of the PPAQ attribute are specified. 1482 4.3.1. Quota Identifier (QID) SubType 1484 The value of the type field of the Quota Identifier (QID) SubType is 1485 TBD. The length of this SubType is 6 octets. Its value is encoded 1486 as a string. It is generated by the PPS and subsequently returned in 1487 a PPAQ->QID subtype from the PPC to the PPS. This field has the 1488 semantic of a transaction identifier and therefore changes with every 1489 transaction initiated by the PPS to the PPC. 1491 4.3.2. VolumeQuota SubType 1493 The value of the type field of the VolumeQuota SubType is TBD. The 1494 length of this SubType is 12 or 18 octets. It is only present if 1495 volume-based charging is used. In a RADIUS Access-Accept message 1496 (PPS to PPC direction), it indicates the volume (in octets) allocated 1497 for the session by the PPS. In an RADIUS Authorize-Only Access- 1498 Request message (PPC to PPS direction), it indicates the total used 1499 volume (in octets) for both inbound and outbound traffic. The 1500 attribute consists of a Value-Digits SubType and optionally an 1501 Exponent SubType (as indicated in the length field). The Exponent 1502 SubType, if present, MUST NOT encode a negative number or zero. 1504 4.3.3. VolumeThreshold SubType 1506 The value of the type field of the VolumeThreshold SubType is TBD and 1507 its length is 12 or 18 octets. This SubType is optionally present if 1508 VolumeQuota is present in a RADIUS Access-Accept message (PPS to PPC 1509 direction). It is generated by the PPS and indicates the volume (in 1510 octets) that has to be consumed before a new quota is requested. 1511 This threshold MUST NOT be larger than the VolumeQuota. The 1512 attribute consists of a Value-Digits SubType and optionally an 1513 Exponent SubType (as indicated by the length field). The Exponent 1514 SubType, if present, MUST NOT encode a negative number or zero. 1516 4.3.4. DurationQuota SubType 1518 The value of the type field of the DurationQuota SubType is TBD and 1519 its length is 6 octets. This optional SubType is only present if 1520 duration-based charging is used. In a RADIUS Access-Accept message 1521 (PPS to PPC direction), it indicates the duration (in seconds) 1522 allocated for the session by the PPS. It is encoded as an integer. 1524 In a RADIUS Access-Request message (PPC to PPS direction), it 1525 indicates the total duration (in seconds) since the start of the 1526 accounting session related to the QID subtype of the PPAQ attribute 1527 in which it occurs. 1529 4.3.5. DurationThreshold SubType 1531 The value of the type field of the DurationThreshold SubType is TBD 1532 and its length is 6 octets. This SubType shall optionally be present 1533 if the DurationQuota is present in a RADIUS Access-Accept message 1534 (PPS to PPC direction). It represents the duration (in seconds) 1535 after which new quota should be requested. This threshold MUST NOT 1536 be larger than the DurationQuota SubType. It is encoded as an 1537 integer. 1539 4.3.6. ResourceQuota SubType 1541 The value of the type field of the ResourceQuota SubType is TBD. The 1542 length of this SubType is 12 or 18 octets. This optional SubType is 1543 only present if resource-based or one-time charging is used. In the 1544 RADIUS Access-Accept message (PPS to PPC direction) it indicates the 1545 resources allocated for the session by the PPS. In RADIUS Authorize- 1546 Only Access-Request message (PPC to PPS direction), it indicates the 1547 resources used in total, including both incoming and outgoing 1548 chargeable traffic. In one-time charging scenarios, the subtype 1549 represents the number of units to charge or credit the user. The 1550 attribute consists of a Value-Digits SubType and optionally an 1551 Exponent SubType (as indicated by the length field). 1553 4.3.7. ResourceThreshold SubType 1555 The value of the type field of the ResourceThreshold SubType is TBD. 1556 The length of this SubType is 12 or 18 octets. The semantics of this 1557 SubType follow those of the VolumeThreshold and DurationThreshold 1558 SubType. It consists of a Value-Digits SubType and optionally an 1559 Exponent SubType. 1561 4.3.8. Value-Digits SubType 1563 The value of the type field of the Value-Digits SubType is TBD and 1564 its length is 10 octets. This SubType encodes the most significant 1565 digits of a number, encoded as an integer. If decimal values are 1566 needed to present the number, the scaling MUST be indicated with a 1567 related Exponent SubType. For example, the decimal number 0.05 is 1568 encoded by a Value-Digits SubType set to 5, and a scaling that is 1569 indicated with the Exponent SubType set to -2. 1571 4.3.9. Exponent SubType 1573 The value of the type field of the Exponent SubType is TBD. The 1574 length of this SubType is 6 octets. This SubType contains the 1575 exponent value that is to be applied to the accompanying Value-Digit 1576 SubType. Its value is encoded as an integer. 1578 4.3.10. Update-Reason SubType 1580 The value of the type field of the Update-Reason SubType is TBD. The 1581 length of this SubType is 4 octets. This SubType is present in a 1582 RADIUS Access-Request message (PPC to PPS direction) and indicates 1583 the reason for initiating the quota update operation. Update reasons 1584 (6), (7), (8) and (9) indicate that the associated resources are 1585 released at the PPC side, and that therefore the PPS MUST NOT 1586 allocate a new quota in the RADIUS Access Accept message. 1588 The following values for the Update-Reason SubType are defined: 1590 Value | Description 1591 -------------+-------------------------------------- 1592 0 | Reserved 1593 1 | Pre-initialization 1594 2 | Initial Request 1595 3 | Threshold Reached 1596 4 | Quota Reached 1597 5 | TITSU Approaching 1598 6 | Remote Forced Disconnect 1599 7 | Client Service Termination 1600 8 | "Access Service" Terminated 1601 9 | Service not established 1602 10 | One-Time Charging 1603 11..255 | **Available for IANA registration** 1605 Figure 10: Values for Update-Reason SubType 1607 4.3.11. PrepaidServer SubType 1609 The value of the type field of the PrepaidServer SubType is TBD. The 1610 length of this SubType is 6 or 18 octets, for IPv4 and IPv6 addresses 1611 respectively. This optional SubType indicates the address of the 1612 serving PPS. If present, the Home RADIUS server uses this address to 1613 route the message to the serving PPS. Multiple instances of this 1614 subtype MAY be present in a single PPAQ attribute. The value of this 1615 SubType is encoded as an address. 1617 If present in the PrepaidServer SubType of an incoming RADIUS Access- 1618 Accept message, the PPC returns this SubType back without modifying 1619 it in the subsequent RADIUS Access-Request message. If multiple 1620 values are present, the PPC MUST NOT change their order. 1622 4.3.12. Service-ID SubType 1624 The value of the type and length fields of the Service-ID SubType are 1625 TBD. The value field of this SubType is encoded as a string. This 1626 value is handled as an opaque string that uniquely describes the 1627 service instance to which prepaid metering should be applied. 1629 A Service-Id could be an IP 5-tuple (source address, source port, 1630 destination address, destination port, protocol). If a Service-ID 1631 SubType is present in the PPAQ, the entire PPAQ attribute refers to 1632 that service. If a PPAQ attribute does not contain a Service-Id or 1633 Rating-Group-ID, then the PPAQ attribute refers to the "Access 1634 Service". 1636 4.3.13. Rating-Group-ID SubType 1638 The value of the type field of the Rating-Group-ID SubType is TBD. 1639 The length of this SubType is 6 octets. This SubType indicates that 1640 this PPAQ attribute is associated with resources allocated to a 1641 Rating Group with the corresponding ID. This SubType is encoded as a 1642 string. A single PPAQ MUST NOT contain more than one 1643 Rating-Group-ID. 1645 4.3.14. Termination-Action SubType 1647 The value of the type field of the Termination-Action SubType is TBD. 1648 The length of this SubType is 3 octets. This SubType contains an 1649 enumeration of the action to take when the PPS does not grant 1650 additional quota. Valid actions are as follows. 1652 The following values for the Termination-Action SubType are defined: 1654 Value | Description 1655 -------------+------------------------------------ 1656 0 | Reserved 1657 1 | Terminate 1658 2 | Request More Quota 1659 3 | Redirect/Filter 1660 4..255 | **Available for IANA registration** 1662 Figure 11: Values for the Termination-Action SubType 1664 4.3.15. Pool-ID SubType 1666 The value of the type field of the Pool-ID SubType is TBD. The 1667 length of this SubType is 6 octets and it identifies the resource 1668 pool. It is encoded as a string. 1670 4.3.16. Pool-Multiplier SubType 1672 The value of the type field of the Pool-Multiplier SubType is TBD. 1673 The length of this SubType is 12 or 18 octets. The pool multiplier 1674 determines the weight that resources are inserted into the pool that 1675 is identified by the accompanying Pool-ID SubType, and the rate at 1676 which resources are taken out of the pool by the relevant Service or 1677 Rating-Group. The SubType consists of a Value-Digits SubType and 1678 optionally an Exponent SubType (as indicated by the length field). 1680 4.3.17. Requested-Action SubType 1682 The value of the type field of the Requested-Action SubType is TBD. 1683 The length of this SubType is 3 octets and it is only be present in 1684 messages sent from the PPC to the PPS. It indicates that the PPC 1685 desires the PPS to perform the indicated action and to return the 1686 result. The PPAQ in which a Requested-Action SubType occurs MUST NOT 1687 contain a QID, and MUST contain a Service-Identifier or a Rating- 1688 Group-Identifer that allows the PPS to uniquely identify the service 1689 for which the indicated action is requested. 1691 The following values for the Requested-Action SubType are defined: 1693 Value | Description 1694 -------------+------------------------------------- 1695 0 | Reserved 1696 1 | Balance Check 1697 2 | Price Enquiry 1698 3..255 | **Available for IANA registration** 1700 Figure 12: Values for the Requested-Action SubType 1702 4.3.18. Check-Balance-Result SubType 1704 The value of the type field of the Check-Balance-Result SubType is 1705 TBD. The length of this SubType is 3 octets. This SubType can only 1706 be present in messages sent from the PPS to the PPC. It indicates 1707 the balance check decision of the PPS about a previously received 1708 Balance Check Request (as indicated in a Requested-Action SubType). 1709 The PPAQ attribute in which a Check-Balance-Result occurs MUST NOT 1710 include a QID. 1712 The following values for the Check-Balance-Result SubType are 1713 defined: 1715 Value | Description 1716 -------------+------------------------------------------- 1717 0 | Success; Sufficient funds available 1718 | in the user's prepaid account 1719 1 | Failure; Insufficient funds available 1720 2..255 | **Available for IANA registration** 1722 Figure 13: Values for the Check-Balance-Result SubType 1724 4.3.19. Cost-Information SubType 1726 The value of the type field of the Cost-Information SubType is TBD. 1727 The length of this SubType is variable. This SubType is used in 1728 order to return the cost information of a service, which the PPC can 1729 transfer transparently to the end user. This SubType is sent from 1730 the PPS to the PPC as a response to a "Price Enquiry", as indicated 1731 by the Requested-Action SubType. This SubType consists of four 1732 further SubTypes, as follows: 1734 Value-Digits SubType: 1736 The Value-Digits SubType encodes the most significant digits of 1737 the monetery value that represents the cost in question. 1739 Exponent SubType: 1741 The Exponent SubType encodes the exponent that applies to the 1742 Value-Digits SubType. 1744 Currency-Code SubType: 1746 the value of the type field of this SubType is TBD. The length of 1747 this SubType is 4 octets. It encodes the currency code, as 1748 defined in the ISO 4217 standard. 1750 Cost-Unit SubType: 1752 the value of the type field of this SubType is TBD. The length of 1753 this SubType is variable. It carries a UTF8String encoded human 1754 readable string that can be displayed to the end user. It 1755 specifies the applicable unit to the Cost-Information when the 1756 service cost is a cost per unit (e.g., cost of the service is $1 1757 per minute). The Cost-Unit can be minutes, hours, days, 1758 kilobytes, megabytes, etc. 1760 For example, the cost of 7.75 Malawi kwacha per hour would be encoded 1761 as follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, 1762 and Cost-Unit = "hour". 1764 The PPAQ that carries a Cost-Information MUST NOT include a QID. 1766 4.4. Prepaid Tariff Switching (PTS) Attribute 1768 This specification defines the PTS attribute, which allows to switch 1769 from one rate to another during service provision. Support for 1770 tariff switching is optional to implement and to use for the PPC and 1771 the PPS. PPCs use the flag "Tariff Switching supported" in the 1772 AvailableInClient field of the PPAC attribute in order to indicate 1773 support for tariff switching. PPSs employ the PTS attribute in order 1774 to announce their support for tariff switching. 1776 If a RADIUS message contains a PTS attribute, it MUST also contain at 1777 least one PPAQ attribute. If a RADIUS Access-Request message 1778 contains a PTS attribute or the "Tariff Switching supported" flag in 1779 the AvailableInClient field of the PPAC attribute, it MUST also 1780 contain an Event-Timestamp RADIUS attribute (see [RFC2869]). 1782 Every PTS attribute MUST include a QID SubType, as specified in 1783 Section 4.3.1. In a RADIUS Access-Request message sent from the PPC 1784 to the PPS, the QID SubType MUST contain the value of the Quota 1785 Identifier SubType that was previously received from the PPS and MUST 1786 be the same as the value carried in the QID SubType of one of the 1787 PPAQ attributes included the same RADIUS message. 1789 If multiple services are supported and if the PPAQ is associated with 1790 a service as indicated by the Service-ID SubType, then the PTS refers 1791 to the tariff switch for that service. If the PPAQ does not have a 1792 Service-ID, then the PTS refers to tariff switch for the "Access 1793 Service". 1795 A PPAQ attribute that is transported along with a PTS attribute and 1796 has the same value as the QID SubType contained in the PTS attribute 1797 in its own QID SubType is referred to as the "accompanying PPAQ 1798 attribute". If a PPS receives an Access-Request message from a PPC, 1799 it associates a unique value for the QID SubType to this request. 1801 The PTS attribute, as shown in Figure 14, contains a number of other 1802 subtypes which are specified in the following subsections. 1804 0 1 2 3 1805 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 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | TYPE | LENGTH | VALUE ... 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 ... VALUE | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 TYPE : value of PTS 1813 LENGTH: variable 1814 VALUE : Variable length content of data type String 1816 Each SubType is then encoding in the following style: 1818 0 1 2 3 1819 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 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | SubType | LENGTH | VALUE ... 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 Figure 14: PTS Attribute 1826 4.4.1. VolumeUsedAfterTariffSwitch SubType 1828 The value of the type field of the VolumeUsedAfterTariffSwitch 1829 (VUATS) SubType is TBD. The length of this SubType is 12 or 18 1830 octets. The VolumeUsedAfterTariffSwitch subtype SHOULD be used in 1831 the RADIUS Access-Request messages (PPC to PPS direction). It 1832 indicates the volume (in octets) used during a session after the last 1833 tariff switch for the service specified via the QID SubType and the 1834 accompanying PPAQ attribute. The attribute consists of a Value- 1835 Digits SubType and optionally an Exponent SubType (as indicated in 1836 the length field). 1838 4.4.2. TariffSwitchInterval SubType 1840 The type of the TariffSwitchInterval (TSI) SubType is TBD and its 1841 length 6 octets. This SubType MUST be present in each PTS attribute 1842 that is part of a RADIUS Access-Accept message (PPS to PPC 1843 direction). It indicates the interval (in seconds) between the value 1844 of Event-Timestamp RADIUS attribute (see [RFC2869]) of the 1845 corresponding RADIUS Access-Request message and the next tariff 1846 switch condition. 1848 4.4.3. TimeIntervalafterTariffSwitchUpdate SubType 1850 The value of the type field of the 1851 TimeIntervalafterTariffSwitchUpdate (TITSU) SubType is TBD. The 1852 length of this SubType is 6 octets. The PPS MUST include this 1853 SubType if there is another tariff switch period after the period 1854 that ends as indicated by the TSI SubType. The value of the TITSU 1855 SubType in encoded as an integer, and contains the number of seconds 1856 of the tariff period that begins immediately after the period that 1857 ends as indicated by the TSI attribute. If the TITSU SubType is not 1858 present, the PPC assumes that the tariff period which ends as 1859 indicated by the TSI SubType lasts until further notice. If TITSU is 1860 specified, the PPC MUST send a quota update before the point in time 1861 specified by the TITSU SubType (see Figure 7). 1863 5. Diameter RADIUS Interoperability 1865 The RADIUS prepaid extensions need to interoperate with the Diameter 1866 protocol. Two interoperability scenarios exist, as follows. Either 1867 the AAA infrastructure is Diameter based and the PPC are RADIUS 1868 based, or the PPC is Diameter based and the AAA infrastructure is 1869 RADIUS based. 1871 The Diameter Credit Control Application [RFC4006] describes how to 1872 implement a prepaid accounting system using a Diameter based 1873 infrastructure. 1875 The translation functionality between a Diameter Credit Control and a 1876 RADIUS prepaid protocol interaction is described in Appendix B. 1878 6. Security Considerations 1880 The extended RADIUS protocol described in this document is subject to 1881 a number of potential attacks, in a manner similar to the RADIUS 1882 protocol without these extensions. It is recommended that IPsec be 1883 employed to protect against certain of the attacks. 1885 [Editor's Note: This section is freaking short. We should add 1886 something here.] 1888 7. Table of Attributes 1890 The following table provides a guide which attributes may be found in 1891 which RADIUS messages, and in what quantity. 1893 Request Accept Reject Challenge Accounting # Attribute 1894 Request 1895 0-1 0 0 0 0 TBD PPAC 1896 0+ 0+ 0 0 0+ TBD PPAQ 1897 0+ 0+ 0 0 0+ TBD PTS 1899 8. IANA Considerations 1901 This document contains a number of instructions to IANA. 1903 8.1. New RADIUS Attributes 1905 This document requires the assignment of new RADIUS attributes type 1906 numbers for the following attributes: 1908 Attribute Name | Attribute Type Value 1909 --------------------------------------+----------------------------- 1910 Prepaid-Accounting-Capability (PPAC) | TBD 1911 Prepaid-Accounting-Operation (PPAQ) | TBD 1912 Prepaid Tariff Switching (PTS) | TBD 1914 8.2. New Registry: Prepaid SubTypes 1916 Section 4 defines the SubTypes used within newly defined attributes. 1917 IANA is asked to create a registry for these SubTypes. Each registry 1918 entry consists of a 8 bit number together with a description of the 1919 SubType. This document creates the following SubTypes for this 1920 registry: 1922 Value | SubType Name 1923 ---------+----------------------------- 1924 0 | Reserved 1925 1 | AvailableInClient 1926 2 | Quota Identifier 1927 3 | VolumeQuota 1928 4 | VolumeThreshold 1929 5 | DurationQuota 1930 6 | DurationThreshold 1931 7 | ResourceQuota 1932 8 | ResourceThreshold 1933 9 | Value-Digits 1934 10 | Exponent 1935 11 | Update-Reason 1936 12 | PrepaidServer 1937 13 | Service-ID 1938 14 | Rating-Group-ID 1939 15 | Termination-Action 1940 16 | Pool-ID 1941 17 | Pool-Multiplier 1942 18 | Requested-Action 1943 19 | Check-Balance-Result 1944 20 | Cost-Information 1945 21 | Currency-Code 1946 22 | Cost-Unit SubType 1947 23 | VolumeUsedAfterTariffSwitch 1948 24 | TariffSwitchInterval 1949 25 | TimeIntervalafterTariffSwitchUpdate 1950 26..255 | **Available for IANA registration** 1952 The semantic of the above-listed SubTypes is described in Section 4. 1954 Following the policies outline in [RFC3575] the available SubTypes 1955 (i.e., value 0 and values 26-255) with a description of their 1956 semantic will be assigned after Expert Review initiated by the O&M 1957 Area Directors in consultation with the RADEXT working group chairs 1958 or the working group chairs of a designated successor working group. 1959 Updates can be provided based on expert approval only. A designated 1960 expert will be appointed by the O&M Area Directors. No mechanism to 1961 mark entries as "deprecated", or to delete entries from the registry 1962 is envisioned. 1964 Each registration must include a number for the SubType and the 1965 semantic of the SubType. 1967 8.3. New Registry: Update-Reason 1969 Section 4.3.10 defines the Update-Reason SubType. IANA is asked to 1970 create a registry for the values contained in the Update-Reason 1971 SubType, as shown in Figure 10. Each registry entry consists of a 8 1972 bit number together with a description of the update reason. 1974 Following the policies outline in [RFC3575] the available values 1975 together with a description of their semantic will be assigned after 1976 Expert Review initiated by the O&M Area Directors in consultation 1977 with the RADEXT working group chairs or the working group chairs of a 1978 designated successor working group. Updates can be provided based on 1979 expert approval only. A designated expert will be appointed by the 1980 O&M Area Directors. No mechanism to mark entries as "deprecated", or 1981 to delete entries from the registry is envisioned. 1983 8.4. New Registry: Termination-Action 1985 Section 4.3.14 defines the Termination-Action SubType. IANA is asked 1986 to create a registry for the values contained in the Termination- 1987 Action SubType, as shown in Figure 11. Each registry entry consists 1988 of a 8 bit number together with a description of the termination 1989 action. 1991 Following the policies outline in [RFC3575] the available values 1992 together with a description of their semantic will be assigned after 1993 Expert Review initiated by the O&M Area Directors in consultation 1994 with the RADEXT working group chairs or the working group chairs of a 1995 designated successor working group. Updates can be provided based on 1996 expert approval only. A designated expert will be appointed by the 1997 O&M Area Directors. No mechanism to mark entries as "deprecated", or 1998 to delete entries from the registry is envisioned. 2000 8.5. New Registry: Requested-Action 2002 Section 4.3.17 defines the Requested-Action SubType. IANA is asked 2003 to create a registry for the values contained in the Requested-Action 2004 SubType, as shown in Figure 12. Each registry entry consists of a 8 2005 bit number together with a description of the requested reason. 2007 Following the policies outline in [RFC3575] the available values 2008 together with a description of their semantic will be assigned after 2009 Expert Review initiated by the O&M Area Directors in consultation 2010 with the RADEXT working group chairs or the working group chairs of a 2011 designated successor working group. Updates can be provided based on 2012 expert approval only. A designated expert will be appointed by the 2013 O&M Area Directors. No mechanism to mark entries as "deprecated", or 2014 to delete entries from the registry is envisioned. 2016 8.6. New Registry: Check-Balance-Result 2018 Section 4.3.18 defines the Check-Balance-Result SubType. IANA is 2019 asked to create a registry for the values contained in the Check- 2020 Balance-Result SubType, as shown in Figure 13. Each registry entry 2021 consists of a 8 bit number together with a description of the 2022 requested reason. 2024 Following the policies outline in [RFC3575] the available values 2025 together with a description of their semantic will be assigned after 2026 Expert Review initiated by the O&M Area Directors in consultation 2027 with the RADEXT working group chairs or the working group chairs of a 2028 designated successor working group. Updates can be provided based on 2029 expert approval only. A designated expert will be appointed by the 2030 O&M Area Directors. No mechanism to mark entries as "deprecated", or 2031 to delete entries from the registry is envisioned. 2033 8.7. New Registry: AvailableInClient-Extended 2035 Section 4.3.18 defines the PrePaid Accounting Capability (PPAC) 2036 attribute with the AvailableInClient-Extended field. IANA is asked 2037 to create a registry for the values contained in the 2038 AvailableInClient-Extended field, as shown in Section 4.1. Each 2039 registry entry consists of a 8 bit number together with a description 2040 of the capability. Note that this is a bitmask and only 8 values are 2041 available for registration via IANA. 2043 Following the policies outline in [RFC3575] the available values 2044 together with a description of their semantic will be assigned after 2045 Expert Review initiated by the O&M Area Directors in consultation 2046 with the RADEXT working group chairs or the working group chairs of a 2047 designated successor working group. Updates can be provided based on 2048 expert approval only. A designated expert will be appointed by the 2049 O&M Area Directors. No mechanism to mark entries as "deprecated", or 2050 to delete entries from the registry is envisioned. 2052 9. Acknowledgements 2054 The authors would like to thank Christian Guenther, Bernard Aboba, 2055 and John Loughney for their feedback throughout the development of 2056 this document. 2058 10. References 2060 10.1. Normative References 2062 [RFC2119] Bradner, S., "RFC 2119: Key words for use in RFCs to 2063 Indicate Requirement Levels", March 1997. 2065 [RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC 2066 2865: Remote Authentication Dial In User Server (RADIUS)", 2067 June 2000. 2069 10.2. Informative References 2071 [I-D.ietf-radext-filter-rules] 2072 Congdon, P., "RADIUS Attributes for Filtering and 2073 Redirection", draft-ietf-radext-filter-rules-03 (work in 2074 progress), July 2007. 2076 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 2077 Authentication Protocol (EAP)", RFC 2284, March 1998. 2079 [RFC2866] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. 2081 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS 2082 Extensions", June 2000. 2084 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 2085 Authentication Dial In User Service)", RFC 3575, 2086 July 2003. 2088 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 2089 Adoba, "RFC 3576: Dynamic Authorization Extensions to 2090 Remote Authentication Dial-In User Service (RADIUS)", 2091 February 2003. 2093 [RFC3748] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2094 Levkowetz, "RFC 3748: Extensible Authentication Protocol", 2095 June 2004. 2097 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 2098 Loughney, "RFC 4006: Diameter Credit Control Application", 2099 August 2005. 2101 Appendix A. Example flows 2103 This section presents certain example flows that involve the RADIUS 2104 prepaid extensions. By no means is the intent of this section to 2105 specify or recommend business logic, rating strategies, and 2106 application-level behaviour. The intent of this section is purely to 2107 illustrate some fictive scenarios and the RADIUS prepaid message 2108 flows that could be associated with these scenarios. The contents of 2109 this section should be regarded as a collection of informative 2110 examples that aim to provide guidance to implementors. 2112 A.1. A simple flow 2114 End user PPC PPS 2116 user logs on 2117 ------(1)---------> 2118 Access Request 2119 {RADIUS BASE AVPS, 2120 PPAC=00...00011} 2121 -------(2)--------> 2123 [allocates 2124 5MB quota] 2126 Access Accept 2127 {RADIUS BASE AVPS, 2128 PPAQ={QID=5, VQ = 5MB, 2129 VTH = 4.5 MB}} 2130 <-------(3)-------- 2132 service provision/metering 2133 -------(4)---------> 2135 4.5 MB consumed 2137 Access Request 2138 {RADIUS BASE AVPS, 2139 PPAQ={QID=5, VQ=4.5MB, 2140 REASON=THRESHOLD REACHED}} 2141 -------(5)---------> 2143 [allocates another 7MB 2144 to the access service] 2146 Access Accept 2147 {RADIUS BASE AVPS, 2148 PPAQ={QID=8, VQ=12MB, 2149 VTH = 11.5 MB}} 2150 <----------(6)-------------- 2151 user logs off 2152 ------(7)------- 2153 Access Request 2154 {RADIUS BASE AVPS, 2155 PPAQ={QID=8, VQ=7 MB, 2156 REASON=ACCESS SERV TERMINATED}} 2157 -------(8)---------> 2159 [reimburses 2160 user account] 2162 AA Accept 2163 {RADIUS BASE AVPS} 2164 <-------(9)-------- 2166 Figure 18: A simple example message flow 2168 The user logs on (1). The PPC sends a RADIUS Access Request message 2169 to the PPS (2), and includes the prepaid-specific PPAC AVP. This AVP 2170 indicates that both duration-based and volume-based metering is 2171 supported. However, it also indicated that multiple services, rating 2172 groups and resource pools are not supported. Note that, since this 2173 is not an "Authorize-Only" message, no PPAQ attribute with Update 2174 Reason="initial request" is included (see Section 3.7.1). The PPS 2175 then authenticates the user and authorizes the access service, as is 2176 usual in RADIUS. Note that the PPAC AVP is appended by the PPC in at 2177 least the last message that is sent to the home AAA server during 2178 this possibly multiple-round exchange. 2180 If authentication and authorization is successful (in this example 2181 this is assumed), then the PPS identifies the user's prepaid account 2182 from the included base RADIUS AVPs, and determines the capabilities 2183 of the PPC from the PPAC attribute. Assuming that sufficient funds 2184 are available in the user's prepaid account, the PPS reserves some of 2185 these and rates the service. In this example, the PPS reserves, say, 2186 2 Euros and determines that the access service is rated at 0.4 Euro 2187 per MB. This results in 5 MB of quota being granted. The PPS also 2188 determines that the PPC should ask for this quota to be replenished 2189 once 4.5 MB have been consumed. Thus, it creates an Access Accept 2190 message with a Volume-Threshold indication of 4.5MB. It further 2191 associates the QID=5 to this reservation. This identifier can be 2192 used to later uniquely identify the prepaid session, user, account, 2193 etc. The resulting Access Accept message is sent to the PPC (3). 2195 Upon reception of message (4), the PPC provides the access service to 2196 the user and meters it accordingly. At some point in time, the 2197 threshold is reached, i.e., 4.5MB of "access service" have been 2198 consumed by the user. At that point, the PPC generates an Authorize- 2199 Only Access Request that contains the usual RADIUS attributes and a 2200 PPAQ attributes that reports the amount of consumed quota, and the 2201 request for replenishment, i.e., the Update-Reason= THRESHOLD REACHED 2202 (5). Note that the QID in this message is the same as the one 2203 previously received from the PPS. 2205 Upon reception of message (5), the PPS identifies the user and his 2206 account from the QID. In also determines that a prepaid session is 2207 ongoing, and that enough credit remains in the prepaid account in 2208 order for the access service to continue being provided. Since 4.5 2209 MB have been consumed, the PPS subtracts 1.8 Euros from the user's 2210 prepaid account. The PPS decides to reserve another 2.8 euros from 2211 the user's account. (This results in 3 euros being reserved in total 2212 at this point in time.) As the access service is rated at 0.4 euros 2213 per MB, the PPS determines that another 7 MB of quota should be 2214 granted. This results in a total cumulative quota allocation of 12 2215 MB for the access service. The PPS further calculates the new 2216 threshold value of 11.5 MB. Since this is a new quota reservation, 2217 the PPS also allocates a new QID to it, in this example QID=8. The 2218 resulting RADIUS message is sent to the PPC (6). 2220 Upon reception of message (6), the PPC updates its records and 2221 continues provisioning access to the user. At some point the user 2222 logs off (7). The PPC must then report how many resources were 2223 consumed, so that the PPC can subtract the appropriate monetary 2224 amount from the user's prepaid account. To this end the PPC 2225 constructs an Authorize-Only Access Request message with a PPAQ 2226 attributes for the access service. In this example, 7 MB were 2227 consumed by the access service in total. The PPC reports 7 MB its 2228 final message (8). The PPS correlates the report, using the QID, to 2229 the previous session state. It determines, from the previous 2230 records, that the access service had consumed another 4.5 MB before 2231 (as indicated in message (6)). This means that, of the 7 MB, only 2232 3.5 MB have not yet been subtracted from the user's account. Thus, 2233 the PPS subtracts another 1.4 euros from the user's account and, 2234 since the session is to be terminated (REASON=ACCESS SERVICE 2235 TERMINATED), releases any reserved monetary amount. 2237 The PPS responds with an Access Response as required by the RADIUS 2238 base specification (9). 2240 A.2. A flow with prepaid tariff switching 2242 End user PPC PPS 2243 user logs on 2244 ------(1)---------> 2245 Access Request 2246 {RADIUS BASE AVPS, 2247 PPAC=00...00111} 2248 -------(2)--------> 2250 [allocates 2251 20MB quota] 2253 Access Accept 2254 {RADIUS BASE AVPS, 2255 PPAQ={QID=5, VQ = 20MB, 2256 VTH = 18 MB}, PTS={ 2257 QID=5, PTS{TSI=300sec, 2258 TITSU=6000sec}} 2259 <-------(3)------- 2261 service provision/metering 2262 -------(4)---------> 2264 5900 seconds 2265 passed 2266 Access Request 2267 {RADIUS BASE AVPS, 2268 PPAQ={QID=5, VQ=14MB, 2269 REASON=TITSU APPROACH.}, 2270 TSI={QID=5, VUATS=11MB}} 2271 -------(5)---------> 2273 [allocates another 10MB 2274 to the access service] 2276 Access Accept 2277 {RADIUS BASE AVPS, 2278 PPAQ={QID=8, VQ=30MB, 2279 VTH = 28 MB},PTS={ 2280 QUD=8, PTS=95 sec}} 2281 <----------(6)-------------- 2283 user logs off 2284 ------(7)------- 2286 Access Request 2287 {RADIUS BASE AVPS, 2288 PPAQ={QID=8, VQ=17 MB, 2289 REASON=ACCESS SERV TERMINATED}, 2290 PTS={QID=8, VUATS=2.5 MB} 2291 -------(8)---------> 2293 [reimburses 2294 user account] 2296 AA Accept 2297 {RADIUS BASE AVPS} 2298 <-------(9)-------- 2300 Figure 19: Example message flow with Tariff Switch 2302 The user logs on (1). The PPC sends a RADIUS Access Request message 2303 to the home AAA server (2), and includes the prepaid-specific PPAC 2304 AVP. This AVP indicates that both duration-based and volume-based 2305 metering is supported, as well as tariff switching. The home AAA 2306 server then may authenticate and user and authorize the access 2307 service, as is usual in RADIUS. Note that the PPAC AVP is appended 2308 by the PPC in at least the last message that is sent to the PPS 2309 during this possibly multiple-round exchange. 2311 If authentication and authorization is successful (in this example 2312 this is assumed), the PPS identifies the user's prepaid account from 2313 the included base RADIUS AVPs, and determines the capabilities of the 2314 PPC from the PPAC attribute. In this example, it is assumed that a 2315 tariff switch is about to occur in 300 seconds from the current time. 2316 Suppose that the access service is currently rated at 0.5 euros per 2317 MB and in the next tariff period it is rated at 0.6 euros per MB. 2318 Suppose further that a third tariff period is about to start in 6000 2319 seconds from current time and that that access service is rated at 2320 0.8 euros per MB in that period. The PPS then decides to reserve 12 2321 euros from the user's account. Since it is conceivable that the user 2322 may consume all allocated quota in the (more expensive) "0.6-euro" 2323 period, the PPS reserves 20 MB of quota, and determines a threshold 2324 value of 18 MB. It constructs a Radius Access Accept message with a 2325 PPAQ attribute that reflects these choices, and carries a Quota 2326 Identifier QID=5. It further adds a PTS AVP in the message which is 2327 linked to the PPAQ via the common QID value. The PTS AVP contains a 2328 TSI attribute indicating that a tariff switch will occur in 300 2329 seconds. It also includes a TITSU attribute with the value of 6000 2330 seconds. This is included in order to make sure that the PPC will 2331 report the consumed quota before the "2-euro" tariff period will 2332 start. The message is sent to the PPC (3). 2334 Upon reception of message (3), the PPC provides the access service to 2335 the user and meters it accordingly (4). It also keeps track of time. 2337 That is, it remembers how many octets are consumed before and how 2338 many after the tariff switch that will take place in 300 seconds. 2340 In this example it is assumed that the user consumes the allocated 2341 quota rather slowly. In particular, nearly 6000 seconds (the value 2342 indicated by TITSU SubType) pass without the threshold of 18 MB being 2343 reached. The PPC notices this and must therefore report usage and 2344 request the quota to be replenished despite the fact that the 2345 threshold has not been reached. In this example, it decides to do so 2346 100 seconds before the 6000 seconds are reached. To this end, it 2347 constructs an Authorization Access Request message including a PPAQ 2348 that indicates that 14 MB have been consumed up to now. It also 2349 includes a PTS attribute in order to indicate, using the VUATS 2350 SubType, that 11 MB of these were consumed after the tariff switch. 2351 The message is sent to the the PPS (5). 2353 The PPS can link the message to previous session state via the QID. 2354 It now rates the consumed volume as follows. The 11 MB that were 2355 consumed after the tariff switch correspond to 11 * 0.6 = 6.6 euros 2356 and the remaining 14-11=3 MB to 3 * 0.5 = 1.5 euros. Thus, the PPS 2357 subtracts the amount of 6.6+1.5=8.1 euros from the user's account, 2358 which leads to a remainder of 12 - 8.1 = 3.9 euros being reserved. 2360 The PPS now determines that message (5) was sent in order to 2361 replenish the quota for this prepaid session. This can be deduced 2362 from the UPDATE REASON field, which indicates that the PPC sent this 2363 message because the time indicated by the TITSU SubType is 2364 approacing. The PPS now determines that enough credit remains in the 2365 user's prepaid account in order for the access service to continue 2366 being provided and decides to reserve another 8.9 euros from the 2367 user's account. Since it is conceivable that the user will consume 2368 the 6 unused MB of quota from the previous allocation, as well as the 2369 entire quota that is to be allocated now, entirely in the "0.8-euro" 2370 period, the quota that should now be granted in addition to the 2371 previous 20 MB should be 10 MB. This is because 0.9 of the 8.9 euros 2372 are being reserved in order to "cover the worst case scenario". The 2373 fact that 0.9 euros are reserved for this purpose is due to the fact 2374 that the unused 6 MB from the previous allocation correspond to 4.8 2375 euros (with 0.8 euros per MB). This is 4.8 - 3.9 = 0.9 euros more 2376 than the amount of funds that are still "reserved" from the previous 2377 allocation. (After this reservation, the total amount of reserved 2378 money is 8.9 + 3.9 = 12.8 euros, which corresponds to 16 (10+6) MB 2379 being consumed in the "0.8-euro" period.) 2381 Since quotas are encoded in a cumulative way in RADIUS, the PPS 2382 includes a VolumeQuota of 30 MB into the Access Accept message (6). 2383 The PPS further calculates the new threshold value of 28 MB. Since 2384 this is a new quota reservation, the PPS also allocates a new QID to 2385 it, in this example QID=8. The resulting RADIUS message is sent to 2386 the PPC (6). 2388 Upon reception of message (6), the PPC updates its records and 2389 continues providing access to the user. At some point the user logs 2390 off (7). The PPC must then report how many resources were consumed, 2391 so that the PPC can subtract the appropriate monetary amount from the 2392 user's prepaid account. To this end the PPC constructs an Authorize- 2393 Only Access Request message with a PPAQ attributes for the access 2394 service. In this example, 17 MB were consumed by the access service 2395 in total. The PPC reports 17 MB its final message (8). The PPS 2396 correlates the report, using the QID, to the previous session state. 2397 It determines, from the previous records, that the access service had 2398 consumed 14 MB before (as indicated in message (5)). This means 2399 that, of the 17 MB, only the monetary equivalent for 3 MB have not 2400 yet been subtracted from the user's account. The PPS calculates how 2401 much should be deducted from the user's account as follows. Since 2402 the VUATS SubType indicates that 2.5MB were consumed after the tariff 2403 switch, only 0.5 MB were consumed before that. Thus, the monetary 2404 equivalent is 0.5 * 0.6 + 2.5 * 0.8 = 3.6 euros. That is, the PPS 2405 subtracts 3.6 euros from the user's prepaid account. Since the 2406 session has by now be terminated by the PPC (REASON=ACCESS SERVICE 2407 TERMINATED), the PPS now releases any reserved monetary amount, in 2408 this example 12.8 - 3.6 = 9.2 euros. 2410 The PPS responds with an Access Response as required by the RADIUS 2411 base specification (9). 2413 Remark: In this example, two tariff switches take place. In other 2414 scenarios, of course, only one tariff switch may occur. In such 2415 scenarios the TITSU SubType is not used. 2417 A.3. Resource pools and Rating Groups 2419 End user PPC PPS 2421 user logs on 2422 ------(1)---------> 2424 Access Request 2425 {RADIUS BASE AVPS, 2426 PPAC=00...00101111} 2427 -------(2)--------> 2429 [allocates 2430 5MB quota] 2432 Access Accept 2433 {RADIUS BASE AVPS, 2434 PPAQ={QID=5, VQ = 5MB, 2435 poolID=1,mult=1}} 2436 <-------(3)-------- 2438 service provision/metering 2439 -------(4)---------> 2441 user requests service A 2442 -------(5)---------> 2444 Access Request 2445 {RADIUS BASE AVPS,PPAQ={ 2446 SID="A", RGROUP=1}} 2447 -------(6)--------> 2449 [allocates 50 min 2450 quota] 2452 Access Accept 2453 {RADIUS BASE AVPS, 2454 PPAQ={QID=7, DQ=3000sec 2455 poolID=1,RGROUP=1, SID="A" 2456 mult=1747.63}} 2457 <---------(7)--------------- 2459 user requests service B 2460 -------(8)--------> 2462 Pool 1 close to exhaustion 2464 Access Request 2465 {RADIUS BASE AVPS, 2466 PPAQ={QID=5, VQ=4MB, 2467 REASON=QUOTA REACHED, 2468 PoolID=1, mult=1} 2469 PPAQ={QID=7, DQ=3300sec 2470 REASON=QUOTA REACHED, 2471 PoolID=1, mult=1747.63, 2472 SID="A",RGROUP=1}} 2473 -------(9)---------> 2475 [allocates another 2476 3 MB to access service 2477 and 30 minutes to 2478 service "A"] 2480 Access Accept 2481 {RADIUS BASE AVPS, 2482 PPAQ={QID=8, VQ=8MB, 2483 PoolID=1, mult=1, RGROUP=1}, 2484 PPAQ={QID=9, DQ=4800sec 2485 PoolID=1, mult=1747.63, 2486 SID="A"}} 2487 \ <----------(10)-------------- 2489 user logs off 2490 ------(11)------- 2491 Access Request 2492 {RADIUS BASE AVPS, 2493 PPAQ={QID=8, VQ=6.5MB, 2494 REASON=ACCESS SERV TERMINATED, 2495 PoolID=1, mult=1} 2496 PPAQ={QID=9, DQ=5400sec 2497 REASON=ACCESS SERV TERMINATED, 2498 PoolID=1, mult=1747.63, 2499 SID="A",RGROUP=1}} 2500 -------(12)---------> 2502 [reimburses 2503 user account] 2505 AA Accept 2506 {RADIUS BASE AVPS 2507 <------(13)-------- 2509 Figure 20: Example message flow with resource pools and rating groups 2511 The user logs on (1). The PPC sends a RADIUS Access Request message 2512 to the PPS (2), and includes the prepaid-specific PPAC AVP, 2513 indicating that multiple services, rating groups and resource pools 2514 are supported. Note that, since this is not an "Authorize- Only" 2515 message, no PPAQ attribute with Update Reason="initial request" is 2516 included (see Section 3.7.1). The PPS then may authenticate the user 2517 and authorize the access service, as is usual in RADIUS. Note that 2518 the PPAC AVP is appended by the PPC in at least the last message that 2519 is sent to the PPS during this possibly multiple-round exchange. 2521 If authentication and authorization is successful (in this example 2522 this is assumed), the PPS identifies the user's prepaid account from 2523 the included base RADIUS AVPs, and determines the capabilities of the 2524 PPC from the PPAC attribute. Assuming that sufficient funds are 2525 available in the user's prepaid account, the PPS reserves some of 2526 these and rates the service. In this example, the PPS reserves 5 2527 Euros and determines that the access service is rated at 1 Euro per 2528 MB. In anticipation that the user requests more chargeable services 2529 throughout this prepaid session, and since this is supported by the 2530 PPC, the PPS further associates a resource pool with this 2531 reservation, in this example PoolID=1. The PPC also specifies the 2532 multiplier = 1 for the access service. Note that, since 5MB = 2533 5242880 octets, 1 unit in the resource pool corresponds to 5 / 2534 5242880 euros, which is about 0.000095367431640625 Eurocents. 2535 (However, the PPC does not need to know that.) Moreover, the PPS 2536 associates the QID=5 to this reservation. This identifier can be 2537 used to later uniquely identify the prepaid session, user, account, 2538 etc. The resulting Access Accept message is sent to PPC (3). 2540 Upon reception of message (3), the PPC provides the access service to 2541 the user and meters it accordingly (4). That is, for every octet 2542 consumed, the PPC subtracts 1 unit (since the multiplier is 1) from 2543 the resouce pool with PoolID=1. 2545 At some point in time, the user requests another chargeable service, 2546 namely service A (5). The PPC generates an Authorize-Only Access 2547 Request that contains the usual RADIUS attributes and the Service-ID 2548 identifying service A (6). The PPC has determined that service A is 2549 rated in an identical way as at least one more service. Thus, 2550 service A has been configured to belong to a rating group, in this 2551 example the group with Rating-Group-ID=1. This identifier is 2552 included is message (6). 2554 Upon reception of message (6), the PPS identifies the user and his 2555 account from the base RADIUS attributes, the fact that a prepaid 2556 session is ongoing, and determines that enough credit remains in the 2557 prepaid account in order for service A to be provided. The PPS also 2558 determines that service A is rated at 0.10 euros per minute. The PPS 2559 decides to reserve another 5 euros from the users account; this 2560 corresponds to 50 minutes or, as encoded in the DurationQuota 2561 SubType, 3000 seconds. As service A draws from the same prepaid 2562 account as the access service, the PPS associates this reservation 2563 with the same resource pool as the previous reservation (QID=5), 2564 namely the pool with PoolID=1. Note that, in order for the abstract 2565 units in the pool to be consistent, the multiplier has to be 1747.63. 2566 This is because each second corresponds to about 0.10 / 60 = 0.00167 2567 euros, which is about 1747.63 times the value of an abstract resource 2568 pool unit, as this was determined by the first allocation of quota to 2569 the pool (i.e., 0.000095367431640625 Eurocents). Since this is a new 2570 quota reservation, the PPS also allocates a new QID to it, in this 2571 example QID=7. The resulting RADIUS message is sent to the PPC (7). 2573 Upon reception of message (7), the PPC adjusts the units in resource 2574 pool 1. That is, it first determines how much quota had been 2575 allocated to service A in the past, and subtracts this from the quota 2576 reservation found in the message. Since this is the first quota 2577 reservation for service A, there is nothing to subtract. Thus, it 2578 adds 3000 * 1747.63 = 5242890 units to the pool and remembers that 2579 3000 seconds have been allocated to service A during this prepaid 2580 session. The PPC then provides service A to the user, and meters it 2581 against resource pool 1. That is, for every second it subtracts 2582 1747.63 units from the pool. 2584 At some point in time, the user requests service B (8). The PPC 2585 determines that service B is rated exactly in the same way as service 2586 A, i.e., that they belong to the same rating group, namely the one 2587 with Rating-Group-ID=1. Since this rating group has been effectively 2588 authorised by the allocation of quota with QID=7, the PPC provides 2589 service B to the user immediately. It is rated in the same way as 2590 service A, i.e., for every second provided, 1747.63 units are 2591 subtracted from credit pool 1. 2593 At some point in time, resource pool 1 is close to exhaustion. (For 2594 example, the PPC may determine that the pool is "close to exhaustion" 2595 when has less than 10% its initial amount of units.) At that point, 2596 the PPC needs to ask for replenishment for the pool. Suppose that, 2597 at that point in time, 4MB of "access service", 45 minutes of 2598 "service A", and 10 minutes of "service B" were provided to the user. 2599 Note that this corresponds to (4*1048576) + (55*60*1747.63) = 4194304 2600 + 5767179 = 9961483 abstract service units from the pool. The PPC 2601 constructs an Authorize-Only Access Request message that reports the 2602 usage for the "access service" and "service A". This message 2603 contains two PPAQ attributeS, is sent to the PPS (9). Note that is 2604 the message it appears that "service A" has consumed more than it was 2605 allocated (i.e., 55 minutes although only 50 minutes were initially 2606 allocated to it). This is not a a problem since the PPS knows that 2607 "service A" was drawing from the same pool as the "access service" 2608 and that the "access service" did only consume 4 out of the 5 MB it 2609 was allocated. 2611 Upon reception of message (9), the PPS subtracts 4 euros from the 2612 user's account for the "access service" and another 5.5 euros for 2613 "service A". (This includes the charge incurred by "service B" up to 2614 that point in time, although the PPS is not aware of "service B" 2615 being provisioned to the user.) The PPS then determines that 2616 sufficient funds remain in the prepaid account in order for both 2617 services to be continued. The PPS decides to reserve another 3MB for 2618 the access service and 30 minutes for "service A". This corresponds 2619 to 3+3=6 euros. Since in RADIUS prepaid the quotas are encoded in a 2620 cumulative manner, the PPAQ attribute that grants the quota for the 2621 "access service" contains a Volume-Quota SubType of 8MB (8388608 2622 octets), which is the 5MB that were initially allocated, plus the 3MB 2623 allocated now. The resource pool identifier is, as previously, 2624 PoolID=1 and the multiplier is 1. Similarly, the PPAQ that grants 2625 quota for "service A" contains 4800 seconds (the initial 3000 plus 2626 1800 that correspond to the 30 additional minutes). Again, the 2627 PoolID=1 and multiplier=1747.63. The resulting Access Response 2628 message is sent to the PPC (10). 2630 When the PPC received message (10) it checks how much quota has been 2631 allocated previously to the "access service". It finds that the 2632 answer is 5MB (5242880 octets); thus, out of the 8MB (8388608 octets) 2633 that are indicated by the PPAQ with QID=8, only 3MB (3145728 octets) 2634 have not yet been added to resource pool 1. The PPC thus adds 2635 3145728 abstract units to resource pool 1 (since the multiplier is 2636 1). The PPC then acts similarly on the other PPAQ attribute that 2637 exists in message (11). That is, the PPC determines that 3000 2638 seconds of quota for "service A" had already been added to the pool. 2639 Thus only 1800 out of the 4800 should be additionally added to the 2640 pool. Since the applicable multiplier here is 1747.63, the PPC adds 2641 further 3145734 abstract units to the pool 1. 2643 The PPC then continues to provide the access service, "service A" and 2644 "service B" to the user, and meters them against the pool, as 2645 previously. 2647 At some point the user logs off (11). The PPC must then report how 2648 many resources were consumed, so that the PPC can subtract the 2649 appropriate monetary amount from the user's prepaid account. To this 2650 end the PPC constructs an Authorize-Only Access Request message with 2651 two PPAQ attributes; one for the access service and one for "service 2652 A". Suppose that, in total, 6.5MB were consumed by the access 2653 service, 70 minutes were consumed by "service A" and 20 minutes by 2654 "service B". The PPC reports 6.5MB (6815744 octets) and 90 minutes 2655 (5400 seconds) in its final message (12). The PPS determines, from 2656 the previous records, that the access service consumed another 2.5MB 2657 (since 4MB out of the 6.5MB were already reported in message (9), and 2658 that "service A" consumed further 600 seconds. This corresponds to 2659 2.5 + (600/60)*0.1 = 2.5+ 1=3.5 euros. Thus, the PPS only subtracts 2660 2.5 out of the 6 previously reserved euros from the user's prepaid 2661 account and responds with an Access Response as required by the 2662 RADIUS base specification (13). 2664 A.4. One-time charging 2665 End user PPC PPS 2667 user requests ring tone 2668 ------(1)---------> 2670 Access Request 2671 {RADIUS BASE AVPS, 2672 PPAQ={QID=321, SID=X, RQ=650, 2673 REASON=10 (ONE-TIME CHARGING}} 2674 -------(2)---------> 2676 [rates 650 abstract units 2677 deducts from user's account] 2679 Access Accept 2680 {RADIUS BASE AVPS} 2681 <----------(3)-------------- 2683 ring tone is delivered 2684 <------(4)------- 2686 Figure 21: Example message flow with one-time charging 2688 The user requests a chargeable ring tone (1). The PPC sends a RADIUS 2689 Access Request message to the PPS (2), and includes a PPAQ attribute 2690 with Update Reason="one-time charging" is included (see 2691 Section 3.8.6). The Service ID indicates to the PPS that the 2692 charging event is connected to a ring tone, so that the PPS can rate 2693 the event accordingly. The PPAQ also contains a unique Quota 2694 Identifier. 2696 The PPS then may authenticate the user as is usual in RADIUS. If 2697 authentication is successful (in this example this is assumed), the 2698 home AAA server forwards the PPC converts the 650 reported abstract 2699 units into monetary value, according to the service type, and debit 2700 the user's account accordingly. This happens, of course, only if 2701 sufficient funds are available in the user's prepaid account. The 2702 PPC then responds with an an Access Accept message (3). The PPS adds 2703 a "session timeout = 0 AVP" (see Section 3.8.6). 2705 A.5. Price enquiry 2706 End user PPC PPS 2708 user requests AoC 2709 ------(1)---------> 2711 Access Request 2712 {RADIUS BASE AVPS, 2713 PPAQ={SID=X, VQ=10MB, 2714 REQ_ACT=2(PRICE ENQUIRY}} 2715 -------(2)---------> 2717 [rates 10MB for requested 2718 service] 2720 Access Accept 2721 {RADIUS BASE AVPS, 2722 PPAQ={SID=X, VQ=10MB, 2723 COST INFORMATION= 0.6 euros 2724 per MB}} 2725 <----------(3)-------------- 2727 AoC is delivered 2728 <------(4)------- 2730 Figure 22: Example message flow with price enquiry (advice of charge) 2732 Please refer to Section 2.7.3 for an explanation of this message 2733 flow. 2735 A.6. Balance check 2736 End User PPC PPS 2738 Access Request 2739 {RADIUS BASE AVPS, 2740 PPAQ={SID=X, VQ=10MB, 2741 REQ_ACT=BALANCE CHECK}} 2742 -------(2)---------> 2744 [rates requested 2745 Service and checks 2746 remaining funds] 2748 Access Accept 2749 {RADIUS BASE AVPS, 2750 PPAQ={SID=X, VQ=10MB, 2751 BALANCE_CHECK_RESULT}} 2752 <----------(3)-------------- 2754 Figure 23: Example message flow with balance check 2756 Please refer to Section 2.7.4 for an explanation of this message 2757 flow. 2759 Appendix B. Translation between RADIUS Prepaid and Diameter Credit 2760 Control 2762 In scenarios where the service metering device uses the "RADIUS 2763 prepaid" (RPP) protocol for accounting and prepaid charging while the 2764 AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, 2765 a translation agent that enables the interoperation of both systems, 2766 is desirable. This also applies vice versa, i.e., in scenarios where 2767 the AAA infrastructure uses RADIUS and the service metering device 2768 uses Diameter. 2770 The idea of such a translation agent would be to convert incoming RPP 2771 (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It 2772 would be, in principle, desirable for the translation agent to be 2773 stateless. That is, the agent should not be required to internally 2774 maintain information about each ongoing RADIUS or Diameter session. 2775 However, under the current specification of RPP and DCC, this appears 2776 to be impossible due to a number of reasons. These include the 2777 following. 2779 1. The transport mechanism for DCC is TCP, which requires per- 2780 session state to be maintained at both endpoints of the 2781 communication. Note, however, that, in principle, each DCC 2782 message could be sent over a dedicated TCP connection which is 2783 torn down as soon as the message is sent. This, however, is 2784 likely to be unacceptable in terms of efficiency. 2786 2. While RPP messages encode the cumulative amount of consumed/ 2787 requested resources, DCC messages carry the difference from the 2788 previous message. This means that the translation agent has to 2789 maintain the current amount of consumed/requested resources in 2790 order to be able to calculate the correct amount to be put into 2791 an outgoing message. 2793 The translator maps each incoming RPP (resp. DCC) message into an 2794 outgoing DCC (resp. RPP) message, and possibly establishes or updates 2795 local state that is associated with the session. The translated 2796 (i.e., outgoing) message is a function of the incoming message as 2797 well as existing state that is associated with the current session. 2799 Translation occurs on an attribute-by-attribute basis. Certain 2800 attributes are translated without consideration of local per-session 2801 state. Other attributes, namely those that are bound to a particular 2802 session, require such consideration. The translation agent has to 2803 identify the session (and possibly subsession) an incoming message 2804 belongs to in order to consult the appropriate local per-session 2805 state. 2807 Note that certain DCC attributes cannot be translated due to their 2808 semantics not being present in RPP, and vice versa. This results in 2809 the messages, in which these attributes occur, not being delivered to 2810 their intended destination. In such cases it is desirable to inform 2811 the originator about the failure and terminate the session. 2813 In each scenario (i.e., RPP client / DCC AAA infrastructure and DCC 2814 client / RPP AAA infrastructure), the translator operates in two 2815 directions, namely RPP to DCC and vice versa. In the following 2816 sections, the notation c->s means that the attribute in question may 2817 occur only in the direction from the client to the server. The 2818 notation s->c denotes the converse and the notation c<->s denotes 2819 that the attribute may occur in messages that are directed in either 2820 direction. 2822 B.1. Session Identification 2824 The translation agent has to keep per-session state in order to 2825 perform its task. A session may be identified based on the RPP 2826 identifier or the DCC session identifier. That is, the translation 2827 agent should always maintain a pair of (RPP, DCC) session identifiers 2828 and maintain the per-session state in association with that pair. 2829 This per-session state must be addressable by either of these two 2830 identifiers. Moreover, an RPP session identifier must uniquely 2831 correspond to a DCC identifier. (If this holds, the converse also 2832 holds.) Each subsession identifier within an RPP session must also 2833 uniquely correspond to a subsession identifier within its 2834 corresponding DCC session. (If this holds the converse also holds.) 2836 B.2. Translation between RADIUS Prepaid and Diameter Credit Control 2838 This section describes the translator in the "RPP client / DCC AAA 2839 infrastructure" case. In other words, in this section it is assumed 2840 that the client "talks" RPP and the AAA inftrastructure "talks" DCC. 2841 The translator is assumed to sit somewhere in the middle and to 2842 mediate between client and server. 2844 For each RPP AVP (i.e., AVPs that are specified in the present 2845 document), the transformation into a semantically equivalent DCC AVP 2846 (if such an AVP exists), along with what per-session state the 2847 translator has to create or consult, is described. For clarity of 2848 exposition, each RPP AVP is addressed in a separate subsection. 2849 Since in this scenario, the PPC is typically the initiator a session, 2850 the focus is on the RPP AVPs. 2852 B.2.1. PPAC (c<->s) 2854 A DCC client is assumed to always support Volume metering, Duration 2855 metering, Resource metering, Pools, Rating groups, and Tariff 2856 Switching. Thus, if a PPAQ that indicates any of the above is sent 2857 client->server, the translator does the following: It lets message go 2858 through but remembers what exactly the client supports. If the 2859 server later requests (servier -> client direction) an unsupported 2860 metering to be performed, send failure to server and cause the 2861 session to be terminated at the client. 2863 If a PPAC indicates support for multiple services (0x00000020), the 2864 translator maps this onto a DCC Multiple-Services- Indicator AVP. 2866 B.2.2. Service Termination Attribute (c->s) 2868 The Diameter base protocol assumes that the client always supports 2869 dynamic session termination. If this AVP is present, the translator 2870 does not need to do anything, i.e., there exists no DCC AVP that this 2871 AVP can be mapped to. If this AVP is absent, the message in which it 2872 appears should either be discarded and originator should be informed 2873 of a failure, or the message can be passed on (without this AVP being 2874 mapped onto a DCC AVP). However, in the latter case, the translator 2875 has to remember that the client does not support dynamic termination. 2876 Thus, the translatior has to initiate the normal session termination 2877 procedure with the client when (if) dynamic termination is later 2878 initiated by the server. 2880 B.2.3. Quota Identifier Attribute (c<->s) 2882 When quota is allocated for the first time by the DCC server, the 2883 translator has to create a QID AVP, as required by this 2884 specification. The translator later uses a QID AVP that is sent in 2885 the client-to-server direction in order to identify the corresponding 2886 DCC session. The QID has to be saved in the translator's per session 2887 state. 2889 B.2.4. Volume Quota Attribute (c<->s) 2891 If this AVP occurs in a message that is sent in the server-to-client 2892 direction, it is translated into a Granted-Service-Unit AVP with an 2893 embedded CC-Total-Octets AVP. 2895 If this AVP occurs in a message that is sent in the client-to-server 2896 direction, then it is translated into a Used-Service-Unit AVP with an 2897 embedded CC-Total-Octets AVP. Note that only the difference between 2898 current cumulative quota for the (sub)session and the quota in 2899 incoming messages is indicated in the translated DCC message. Local 2900 state is updated with cumulative consumed resources. 2902 Conversely, if the server grants quota using the DCC Granted-Service- 2903 Unit AVP with an embedded CC-Total-Octets AVP, then the translation 2904 agent must translate this into a Volume Quota Attribute. Again, 2905 local state must be consulted so that the cumulative amount of octets 2906 is indicated in the Volume Quota attribute. 2908 B.2.5. Duration Quota Attribute (c<->s) 2910 If this AVP occurs in a message that is sent in the server-to-client 2911 direction, it is translated into a Granted-Service-Unit AVP with an 2912 embedded CC-Time AVP. 2914 If this AVP occurs in a message that is sent in the client-to-server 2915 direction, then it is translated into a Used-Service-Unit AVP with an 2916 embedded CC-Time AVP. Note that only the difference between current 2917 cumulative quota for the (sub)session and the quota in incoming 2918 messages is indicated in the translated DCC message. Local state is 2919 updated with cumulative consumed resources (i.e., time). 2921 Conversely, if the server grants quota using the DCC Granted-Service- 2922 Unit AVP with an embedded CC-Time AVP, then the translation agent 2923 must translate this into a Duration Quota attribute. Again, local 2924 state must be consulted so that the cumulative amount of seconds is 2925 indicated in the Duaration Quota attribute. 2927 B.2.6. Resource Quota Attribute (c<->s) 2929 If this AVP occurs in a message that is sent in the server-to-client 2930 direction, it is translated into a Granted-Service-Unit AVP with an 2931 embedded CC-Service-Specific-Units AVP. 2933 If this AVP occurs in a message that is sent in the client-to-server 2934 direction, then it is translated into a Used-Service-Unit AVP with an 2935 embedded CC-Service-Specific-Units AVP. Note that only the 2936 difference between current cumulative quota for the (sub)session and 2937 the quota in incoming messages is indicated in the translated DCC 2938 message. Local state is updated with cumulative consumed resources 2939 (i.e., resources). 2941 Conversely, if the server grants quota using the DCC Granted-Service- 2942 Unit AVP with an embedded CC-Service-Specific-Units AVP, then the 2943 translation agent must translate this into a Resource Quota 2944 attribute. Again, local state must be consulted so that the 2945 cumulative amount of resource units is indicated in the Resource 2946 Quota attribute. 2948 Note that the "resource" type is application dependent. This means 2949 that a DCC application unit corresponds to n RPP application units, 2950 where n may be any real number. If n is not 1, then the RPP/DCC 2951 translator must be aware of that and translate resource units 2952 accordingly. 2954 B.2.7. Value Digits Attribute (c<->s) 2956 The encoding of this AVP is similar in RPP and DCC, and the value it 2957 holds may have to be evaluated in conjunction with an acommpanying 2958 "Exponent" AVP. It should be kept in mind that, in RPP the 2959 cumulative amount of granted/consumed quota is typically encoded into 2960 an AVP of this type, while in DCC only the difference from a previous 2961 message. 2963 B.2.8. Exponent Attribute (c<->s) 2965 The encoding of this AVP is similar in RPP and DCC, and the value it 2966 holds may have to be evaluated in conjunction with an acommpanying 2967 "Value Digits" AVP. It should be kept in mind that, in RPP the 2968 cumulative amount of granted/consumed quota is typically encoded into 2969 a related "Value Digits" and "Exponent" AVP pair, while in DCC only 2970 the difference from a previous message is encoded into such a pair. 2972 B.2.9. Volume/Duration/Resource Threshold Attributes (s->c) 2974 In DCC the concept of "threshold" does not exist. Instead, the DCC 2975 client is assumed to ask for the replenishment of quota in good time. 2976 In RPP, on the other hand, the server may optionally include a 2977 threshold AVP, as an indication to the PPC about when to ask for 2978 quota replenishment. 2980 Thus, in this scenario, there is no need for the translator to ever 2981 include a threshold attribute into the messages that it sends to the 2982 PPC. If, however, there is a need for a threshold attribute to be 2983 present in order to avoid a possible service provision 2985 B.2.10. Update Reason Attribute (c->s) 2987 The DCC AVP that is semantically closer to the Update Reason AVP than 2988 any other AVP is the CC-Request-Type AVP. This AVP indicates whether 2989 the message is which it appears is intended to indicate an "initial", 2990 an "intermediate" or a "final interrogation". Morever, in case of 2991 the session being terminated at the client, it indicates the reason 2992 for this termination. 2994 The following list lists the possible values of an "Update Reason" 2995 attribute, along with corresponding values for the CC-Request-Type 2996 AVP. 2998 o Pre-initialization: No action/value defined. 3000 o Initial Request: Typically an "intial interrogation" is triggered 3001 as a result of the reception of the message that contains this 3002 Update Reason AVP. Hence, CC-Request-Type AVP indicates 3003 "INITIAL_REQUEST". 3005 o Threshold Reached: The reception of the message containing this 3006 Update Reason AVP typically triggers an "intermediate 3007 interrogation". Hence, CC-Request-Type AVP indicates 3008 "UPDATE_REQUEST". 3010 o Quota Reached: The reception of the message containing this Update 3011 Reason AVP typically triggers an "intermediate interrogation". 3012 Hence, CC-Request-Type AVP indicates "UPDATE_REQUEST". 3014 o TITSU Approaching: The reception of the message containing this 3015 Update Reason AVP typically triggers an "intermediate 3016 interrogation". Hence, CC-Request-Type AVP indicates 3017 "UPDATE_REQUEST". 3019 o Remote Forced Disconnect: Reception of such an Update Reason 3020 indicates that the client has terminated the session. The 3021 corresponding value for the CC-Request-Type AVP is 3022 "TERMINATION_REQUEST". 3024 o Client Service Termination: Reception of such an Update Reason 3025 indicates that the client has terminated the session. The 3026 corresponding value for the CC-Request-Type AVP is 3027 "TERMINATION_REQUEST". 3029 o "Access Service" Terminated: Reception of such an Update Reason 3030 indicates that the client has terminated the session. The 3031 corresponding value for the CC-Request-Type AVP is 3032 "TERMINATION_REQUEST". 3034 o Service not established: Reception of such an Update Reason 3035 indicates that the client has terminated the session. The 3036 corresponding value for the CC-Request-Type AVP is 3037 "TERMINATION_REQUEST". 3039 o One-Time Charging: Such an Update Reason indicates that a one-time 3040 charging event is initiated by the client. The corresponding 3041 value for the CC-Request-Type AVP is "EVENT_REQUEST". Note that a 3042 "Requested-Action: AVP MUST also be included in the outgoing DCC 3043 message. Typically, this would be of the type "DIRECT_DEBITING", 3044 or "REFUND_ACCOUNT", depending on other AVPs present in the 3045 message. 3047 B.2.11. PrepaidServer Attribute (s<->c) 3049 The PPC typically never sets the value of a PrepaidServer attribute. 3050 Instead, it repeats those values that it receives from the AAA 3051 infrastructure, in this scenario from the translator. This attribute 3052 is therefore not used in a translation scenario. Nevertheless, the 3053 translator must make sure that messages about the same RPP session 3054 are forwarded to the same DCC server, throughout the whole session. 3055 This may be easy to guarantee since the transport of Diameter is TCP. 3057 B.2.12. Service-ID Attribute (s<->c) 3059 The DCC equivalent of a RPP "Service-ID" AVP is the combination of 3060 Service-Context-Id and Service-Identifier AVPs. The translator must 3061 keep a static equivalence table of the RPP Service-ID and the 3062 corresponding DCC combination in order to correctly translate an RPP 3063 service identifier into DCC and back. 3065 B.2.13. Rating-Group-ID Attribute (s<->c) 3067 The DCC equivalent of a RPP "Rating-Group-ID" AVP is also called a 3068 "Rating-Group-ID". Depending on the configuration, this AVP may 3069 contain the same value on both the RPP and the DCC side of the 3070 communication. If, however, static rating groups are configured 3071 between the RCC client and the translator, and different rating 3072 groups between the DCC server and the translator, then the translator 3073 has to maintain a static translation table for the rating group 3074 identifier. In any case, the translation of a rating group AVP, is 3075 not a function of the translator's local per-session state. 3077 B.2.14. Termination-Action Attribute (s->c) 3079 The DCC equivalent of the "Termination-Action" AVP is called the 3080 "Final-Unit-Action" AVP. In this scenario (RPP client and DCC AAA 3081 infrastructure), a DCC "Final-Unit-Action" AVP is translated into a 3082 "Termination-Action" AVP. The following list contains the possible 3083 "Final-Unit-Action" values along with their "Termination-Action" 3084 equivalent. 3086 o TERMINATE (DCC): This value has a direct equivalent in RPP, also 3087 called "Terminate". 3089 o REDIRECT (DCC): If this value appears in a "Final-Unit-Action" 3090 AVP, then a "Redirect-Server-Address" AVP must also appear in the 3091 same DCC message. The translator translates these two AVPs into a 3092 "Termination-Action" with value "Redirect/Filter" and an 3093 eqiovalent NAS-Filter-Rule attribute (specified in http:// 3094 www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt). 3096 o RESTRICT_ACCESS (DCC): If this value appears in a "Final-Unit- 3097 Action" AVP, then a "Restriction-Filter-Rule" AVP must also appear 3098 in the same DCC message. The translator translates these two AVPs 3099 into a "Termination-Action" with value "Redirect/Filter" and an 3100 eqiovalent Filter-ID attribute (specified in http://www.ietf.org/ 3101 internet-drafts/draft-ietf-radext-ieee802-00.txt). 3103 o In the absence of a "Final-Unit-Action" AVP, the DCC server 3104 assumes that the DCC client will ask for replenishment of quota at 3105 some suitable time. In RPP, this is explicitly conveyed via a 3106 "Termination-Action" AVP with the value "Request More Quota". 3107 Thus, in the absence of a "Final-Unit-Action" AVP, the translator 3108 in this scenario appends such an AVP into the outgoing RPP 3109 message. 3111 B.2.15. Pool-ID Attribute (s<->c) 3113 The DCC equivalent of a RPP "Pool-ID" AVP is also called a "Pool-ID". 3114 Typically, no translation needs to be done to the "Pool-ID" 3115 attribute. 3117 B.2.16. Multiplier Attribute (s<->c) 3119 The multiplier attribute, which is a pair of "Value-Digits" and 3120 "Exponent" AVPs, typically needs no translation, since the value it 3121 carries (inside a "Value-Digits" and an "Exponent" AVP) represents 3122 the rating of the service or rating group to which it refers, with 3123 respect to abstract units. As such, the same multiplier value would 3124 typically applyt be conveyed from a DCC server to an PPC, and vice 3125 versa. 3127 B.2.17. Requested-Action Attribute (c->s) 3129 The "Requested Action" AVP can be directly translated into its DCC 3130 equivalent, which carries the same name. 3132 1. Balance Check (PCC): CHECK_BALANCE (DCC) 3134 2. Price Enquiry (PCC): PRICE_ENQUIRY (DCC) 3136 B.2.18. Check-Balance-Result Attribute (s->c) 3138 This attribute carries only a binary value. Hence, its translation 3139 is straightforward. 3141 B.2.19. Cost-Information Attribute (s->c) 3143 This attribute consists of a Value-Digits AVP, an Exponent AVP, a 3144 Currency Code AVP, and a Cost-Unit AVP. All these AVPs do likewise 3145 exist in DCC, and carry identical semantics in the context of the 3146 "Cost-Information" AVP. Thus, the translation of this attribute is 3147 straightforward. 3149 B.2.20. VolumeUsedAfterTariffSwitch attribute (c->s) 3151 This attribute carries the amount of octets that were consumed after 3152 a tariff change. It always appears in a message with an accompanying 3153 PPAQ attribute in which the total amount of octets (i.e., those that 3154 were consumed both before and after the tariff switch) is reported. 3155 Thus, the translation agent can compute the amount of octets that 3156 were consumed before the tariff change. 3158 In DCC, the two amounts, i.e., the octets that were consumed before a 3159 tariff change and those that were consumed afterwards, are reported 3160 in separate Used-Service-Unit AVPs. The two Used-Service-Unit AVPs 3161 have an embedded CC-Total-Octets AVP that indicates the appropriate 3162 amount of octets. Furthermore, the Used-Service-Unit AVP that 3163 carries the amount that was consumed before the tariff switch also 3164 carries an embedded Tariff-Change-Usage AVP with the value 3165 UNIT_BEFORE_TARIFF_CHANGE (0). Similarly, the Used-Service-Unit AVP 3166 that carries the amount that was consumed after the tariff switch 3167 also carries an embedded Tariff-Change-Usage AVP with the value 3168 UNIT_AFTER_TARIFF_CHANGE (1). 3170 Authors' Addresses 3172 Avi Lior 3173 Bridgewater Systems 3174 303 Terry Fox Drive 3175 Ottawa, Ontario Suite 100 3176 Canada 3178 Email: avi@bridgewatersystems.com 3180 Parviz Yegani 3181 Cisco 3182 Mobile Wireless Group, Cisco Systems 3183 3625 Cisco Way, San Jose, California 95134 3184 USA 3186 Email: pyegani@cisco.com 3188 Kuntal Chowdhury 3189 Starent Networks 3190 30 International Place, 3rd Floor 3191 Tewksbury, MA 01876 3192 USA 3194 Email: kchowdhury@starentnetworks.com 3196 Hannes Tschofenig 3197 Nokia Siemens Networks 3198 Linnoitustie 6 3199 Espoo 02600 3200 Finland 3202 Phone: +358 (50) 4871445 3203 Email: Hannes.Tschofenig@nsn.com 3204 URI: http://www.tschofenig.com 3206 Andreas Pashalidis 3207 NEC 3208 Kurfuersten-Anlage 36 3209 Heidelberg 69115 3210 Germany 3212 Email: Andreas.Pashalidis@netlab.nec.de 3214 Full Copyright Statement 3216 Copyright (C) The IETF Trust (2008). 3218 This document is subject to the rights, licenses and restrictions 3219 contained in BCP 78, and except as set forth therein, the authors 3220 retain all their rights. 3222 This document and the information contained herein are provided on an 3223 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3224 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3225 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3226 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3227 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3228 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3230 Intellectual Property 3232 The IETF takes no position regarding the validity or scope of any 3233 Intellectual Property Rights or other rights that might be claimed to 3234 pertain to the implementation or use of the technology described in 3235 this document or the extent to which any license under such rights 3236 might or might not be available; nor does it represent that it has 3237 made any independent effort to identify any such rights. Information 3238 on the procedures with respect to rights in RFC documents can be 3239 found in BCP 78 and BCP 79. 3241 Copies of IPR disclosures made to the IETF Secretariat and any 3242 assurances of licenses to be made available, or the result of an 3243 attempt made to obtain a general license or permission for the use of 3244 such proprietary rights by implementers or users of this 3245 specification can be obtained from the IETF on-line IPR repository at 3246 http://www.ietf.org/ipr. 3248 The IETF invites any interested party to bring to its attention any 3249 copyrights, patents or patent applications, or other proprietary 3250 rights that may cover technology that may be required to implement 3251 this standard. Please address the information to the IETF at 3252 ietf-ipr@ietf.org. 3254 Acknowledgment 3256 Funding for the RFC Editor function is provided by the IETF 3257 Administrative Support Activity (IASA).