idnits 2.17.00 (12 Aug 2021) /tmp/idnits48383/draft-lior-radius-prepaid-extensions-08.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1831. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1837. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 43), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 72 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 126 has weird spacing: '... has suffic...' == Line 1490 has weird spacing: '...es that the c...' == Line 1755 has weird spacing: '...hout it the N...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note that the role of the PPS is not to record accounting messages and therefore it SHOULD not respond with an Accounting Response packet. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A PPAQ that contains a Service-Id is associated with that Service. A PPAQ that contains a Rating-Group-Id is associated with that Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a Service-Id. A PPAQ that contains neither a Rating-Group-Id or a Service-Id applies to the ôAccess Serviceö. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 17, 2005) is 6151 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3576' on line 855 == Missing Reference: 'RFC2284' is mentioned on line 1889, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) == Unused Reference: 'RFC2026' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: 'RFC2868' is defined on line 1597, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 1605, but no explicit reference was found in the text == Unused Reference: 'REDIRECT' is defined on line 1615, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lior 3 INTERNET-DRAFT Bridgewater Systems 4 Category: Informational P. Yegani 5 draft-lior-radius-prepaid-extensions-08.txt Cisco 6 Expires: 18 January, 2006 K. Chowdhury 7 Starent Networks 8 H. Tschofenig 9 C. Guenther 10 Siemens 11 July 17, 2005 13 PrePaid Extensions to Remote Authentication Dial-In User Service 14 (RADIUS) 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 29, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). All Rights Reserved. 45 Abstract 46 This draft presents an extension to the Remote Authentication Dial- 47 In User Service (RADIUS) protocol to support charging for prepaid 48 services. The charging models supported are namely: volume-based 49 charging, duration-based charging and one-time-based charging. 51 Table of Contents 53 1. Introduction...................................................4 54 1.1 Terminology................................................5 55 1.2 Requirements language......................................5 56 2. Overview.......................................................6 57 2.1 Prepaid Charging Models....................................6 58 2.2 Architectural Model........................................6 59 2.3 Motivation................................................11 60 3. Operations....................................................13 61 3.1 General Requirements......................................13 62 3.1.1 Broker AAA Requirements..............................13 63 3.2 Authentication and Authorization for Prepaid Enabled SADs.14 64 3.3 Session Start Operation...................................16 65 3.4 Mid-Session Operation.....................................16 66 3.5 Dynamic Operations........................................18 67 3.5.1 Unsolicited Session Termination Operation............19 68 3.5.2 Unsolicited Change of Authorization Operation........19 69 3.6 Termination Operation.....................................20 70 3.7 Mobile IP Operations......................................20 71 3.8 Operation considerations for Multiple prepaid services....21 72 3.8.1 Initial Quota Request................................22 73 3.8.2 Quota Update.........................................22 74 3.8.3 Termination..........................................23 75 3.8.4 Dynamic Operations...................................23 76 3.8.5 Support for Resource Pools...........................23 77 3.8.6 One-Time-Charging....................................24 78 3.8.7 Error Handling.......................................24 79 3.9 Accounting Considerations.................................25 80 3.10 SAD Operation............................................25 81 3.11 Interoperability with Diameter Credit Control Application25 82 4. Attributes....................................................25 83 4.1 PPAC Attribute............................................26 84 4.2 Session Termination Capability............................27 85 4.3 PPAQ Attribute............................................27 86 4.4 Prepaid Tariff Switching (PTS)............................34 87 4.5 Table of Attributes.......................................36 88 5. Security Considerations.......................................37 89 5.1 Authentication and Authorization..........................37 90 5.2 Replenishing Procedure....................................37 91 6. IANA Considerations...........................................37 92 7. Normative References..........................................38 93 8. Informative References........................................39 94 9. Call Flows....................................................39 95 9.1 Simple Concurrent Services................................40 96 9.2 One-time Charging.........................................43 97 Contributor......................................................43 98 Acknowledgments..................................................43 99 Author's Addresses...............................................43 100 Intellectual Property Statement..................................44 101 Disclaimer of Validity...........................................44 102 Copyright Statement..............................................45 103 Expiration Date..................................................45 104 10. Appendix A û use cases.......................................45 105 10.1 Simple prepaid use case..................................45 106 10.2 Support for Multi-Services...............................47 107 10.3 Resource Pools...........................................48 108 10.4 Support for Complex Rating Functions.....................49 109 10.5 One-Time-based Charging..................................50 110 10.6 Support for Tariff Switching.............................51 111 10.7 Support for Roaming......................................53 112 10.8 Termination of a prepaid session.........................53 113 10.9 Querying and Rebalancing Prepaid Resources...............54 115 1. 116 Introduction 118 This draft describes extensions for the RADIUS protocol. These 119 extensions are meant to enable service providers to charge and bill 120 their customers using prepaid accounts. 122 A prepaid service subscriber is a user who has purchased a contract 123 according to which he will receive a particular data service for 124 either a period of time or a quantity of data. In the typical 125 prepaid scenario, the service provider verifies that the subscriber 126 has sufficient funds in his account before delivering the service. 127 Only if sufficient funds are available is the service provided to 128 the user. 130 Note that the means by which the subscriber obtains funds is outside 131 the scope of this document. Also note that, in some scenarios, the 132 subscriber's account may be used to fund multiple services, some of 133 which may use the extensions defined in this documents, and some 134 may use other mechanisms. While the interworking of the mechanisms 135 described in this document with other mechanisms should be possible 136 and straightforward, how this could be done depends on the external 137 mechanisms and is, as such, outside the scope of this 138 document. 140 The business driver behind the protocol extensions defined in this 141 document is to increase participation (i.e. a service provider's 142 subscriber base) and thus to increase revenues. In particular, the 143 extensions were designed with the following goals in mind. 145 - Make use of existing infrastructure as much as possible, and 146 thereby limit the amount of necessary capital expenditures, 147 - provide the ability to rate service requests in real-time, 148 - provide the ability to charge the user's account - charge prior to 149 service provision, 150 - protect against revenue loss, i.e. prevent an end user from 151 obtaining service when the available funds are not sufficient, 152 - protect against fraud, and 153 - be as widely deployable over dialup, wireless and WLAN networks. 155 The architecture between the entities that execute the RADIUS 156 protocols with the extensions defined in this document assumes that 157 rating of chargeable events does not occur in the element 158 that provides the service. Instead, the rating may be performed at a 159 dedicated server, termed the ôprepaid enabled AAA serverö or simply 160 ôprepaid serverö. Alternatively, the actual rating may occur in an 161 entity behind this prepaid server. Furthermore, business logic may 162 dictate a time-dependent tariff model, for example that the price 163 for a service may switch at 8pm from a high to a low tariff. The 164 extensions defined in this document support such scenarios. 166 Furthermore, this documents assumes an architecture where a `quota 167 server' is available which, through co-ordination with the rating 168 entity and a centralized account balance manager, is able to 169 provide a quota indication for a particular user when requested. 170 This quota server may or may not coexist in the prepaid server. 172 1.1 173 Terminology 175 Network Access Server As in RADIUS. 176 (NAS) 177 Prepaid Client(PPC) The entity which triggers the RADIUS message 178 exchange including prepaid extensions 179 defined in this document. The PPC typically 180 resides in the NAS. 181 Prepaid Server(PPS) The entity that interacts with the Prepaid 182 Client using the RADIUS prepaid extensions 183 defined in this document. 184 Home network The entity which maintains the userÆs 185 profile and prepaid account. 186 WLAN Wireless Local Area Network 187 Service Event 188 Access Service The service that is provided to the user 189 when the user is authenticated and 190 authorized. 192 Furthermore, the following terms are used in this document. Mobile 193 IP and AAA terminology: Home agent (HA), Home network, Home AAA 194 (HAAA), Broker AAA (BAAA), Visited AAA (VAAA) and Foreign Agent (FA) 196 1.2 197 Requirements language 198 In this document, several words are used to signify the requirements 199 of the specification. These words are often capitalized. The key 200 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 202 this document are to be interpreted as described in [RFC2119]. 204 2. 205 Overview 207 This section provides an overview of the prepaid charging models, 208 and their associated architectures, that are supported by the 209 extensions proposed in this document. 211 2.1 212 Prepaid Charging Models 214 A number of models of how to charge customers for data services in a 215 prepaid manner are supported, as follows. 217 . Volume-based charging (VBC): (e.g. 2 Cents/KiloByte) 218 . Duration-based charging (DBC): (e.g. 3 Cents/minute) 219 . Subscription-based charging (SBC): (e.g. Dollars/month) 220 . Event-based charging (EBC): (e.g. 7 Cents/URL or email) 222 Whether the user account is a dedicated prepaid account or a general 223 account (such as a current bank account) is outside the scope of 224 this document. 226 2.2 227 Architectural Model 229 The architectural model assumed in this document encompasses the 230 following entities. 232 (1) Service Access Device (SAD): This entity provides a data 233 service to the users, and typically coincides with the NAS. The 234 SAD executes the RADIUS client which, for the purposes of this 235 document, is termed the PPC. When prepaid service is used the 236 SAD collects service event information and reports it while or 237 after services are provided to the user. This event information 238 is sent to the PPS using the extensions defined in this 239 document. 240 (2) The PPS: The RADUIS server. If real-time credit control is 241 required, the PPC (SAD) contacts the PPS with service event 242 information included before the service is provided. The PPS 243 performs a credit check and allocates a portion of available 244 credit to the service event. 245 (3) The rating entity: This entity converts the credit that is 246 allocated by the PPS into a time or volume amount, called the 247 ôquotaö. This quota is then returned to the requesting PPC 248 (SAD) (via the PPS). The rating entity may also determine that 249 during service provision a tariff switch will occur. In this 250 case the rating entity will include details of when exactly 251 tariff switch will occur. 253 The requesting SAD (PPC) monitors the provision of the service 254 according to the instructions returned by the PPS. After service 255 completion or on a subsequent request for service, the PPS deducts 256 the corresponding amount of credit from the user account. When a 257 user terminates an on-going service, the PPC informs the PPS with a 258 suitable indication about the unused portion of the allocated quota. 259 The PPS is then able to refund the user account appropriately. 261 Multiple PPSs MAY be deployed for reasons of redundancy and load 262 balancing. The system MAY also employ multiple rating servers. 263 Prepaid accounts MAY be located in a centralized database. The 264 detailed architecture of the system and its interfaces are outside 265 the scope of this specification. 267 accounting 268 +------------+ +-----------+ protocol +--------------+ 269 | User |<----->| Service | | | 270 | | | Access |<------------>| Accounting | 271 | Device | | Device |<-----+ | Server | 272 +------------+ +-----------+ | +--------------+ 273 (PPC) | 274 | 275 | +--------------+ 276 +------>| Prepaid | 277 prepaid | Server | 278 protocol +--------------+ 280 Figure 1 Basic Prepaid Architecture 281 The PPS and the accounting server in this architecture are logical 282 entities. The real configuration MAY combine them into a single 283 host. 285 The SAD MUST have the ability to meter the usage for a prepaid data 286 session. This usage includes time or volume (e.g. number of bytes). 288 In roaming scenarios using mobile IP the PPC may run on the Home 289 Agent. Furthermore, the device running the PPC may also have 290 ôDynamic Session Capabilitiesö such as the ability to terminate a 291 data session or change the filters associated with a specific data 292 session by processing ôDisconnectö messages and ôChange of 293 Authorizationö messages as per [RFC3576]. 295 This document assumes that the PPS is used as the AAA server. There 296 are three types of AAA server, as follows. (i) The AAA server in the 297 home network (HAAA), which is responsible for authentication of the 298 subscriber. In addition, the HAAA communicates with the PPS using 299 the RADIUS protocol in order to authorize subscribers. (ii) The AAA 300 server in the visited network (VAAA) which exists only in roaming 301 scenarios and is responsible for forwarding the RADIUS messages to 302 the HAAA. The VAAA may also modify the messages. Note that, in 303 certain roaming deployments, the visited network may be connected to 304 the home network via one or more broker networks. (iii) The AAA 305 server in one of the aforementioned broker networks (BAAA), which is 306 responsible for forwarding messages and does not play an active role 307 in the prepaid data service delivery. A BAAA obviously exists only 308 in those roaming deployments where the VAAA and the HAAA are 309 connected via the BAAA of a broker network. 311 This document assumes that the PPS communicates with the HAAA for 312 the purposes of authorisation. Additionally, the PPS interfaces to 313 entities which 315 - Keep the subscriberÆs account balance (balance manager), 316 - Rate access service requests in real-time (Rating Engine), and 317 - Manage quota for a particular prepaid service (Quota Server). 319 Three deployment scenarios are presented in the remainder of this 320 section. The first scenario is depicted in Figure 2. In this 321 scenario, the SAD, which runs the PPC, the HAAA, and the PPS are 322 located in the same provider network. 324 The Subscriber Device establishes a connection with one of possibly 325 multiple SADs in the network. The selected SAD communicates with a 326 HAAA server. However, in order to provide redundancy, multiple HAAA 327 may be available. 329 The network has one or more PPSs. The interface between the HAAA and 330 the PPS is implemented using the RADIUS protocol together with the 331 extensions described in this document. However, in cases where the 332 PPS does not implement the RADIUS protocol, the implementation would 333 have to map the requirements defined in this document to a 334 functionally equivalent protocol. 336 +------+ +-----+ 337 | | | | 338 +--------+ +--------+ +--| HAAA |--+--| PPS | 339 | | | | | | | | | | 340 | Subscr.| | Service| | +------+ | +-----+ 341 | |---| Access |--+ | 342 | Device | | Device | | +------+ | +-----+ 343 | | | | | | | | | | 344 +--------+ +--------+ +--| HAAA |--+--| PPS | 345 | | | | 346 +------+ +-----+ 348 Figure 2 Basic Prepaid Access Architecture 350 The second scenario, depicted in Figure 3, is based on a static 351 roaming architecture that is typical of a wholesale scenario for 352 Dial-Up users or a broker scenario used in Dial-Up or WLAN roaming 353 scenarios. 355 +----+ +----+ +----+ +-----+ 356 | | | | | | | | 357 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 358 | | | | | | | | | | | | | | | | 359 |Sub | |Service| | +----+ | +----+ | +----+ | +-----+ 360 | |--|Access |-+ | | | 361 |Device| |Device | | +----+ | +----+ | +----+ | +-----+ 362 | | | | | | | | | | | | | | | | 363 +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | 364 | | | | | | | | 365 +----+ +----+ +----+ +-----+ 367 | Visited | |Broker | | Home | 368 | Network | |Network| | Network | 370 Figure 3 Static Roaming Prepaid Architecture 372 As in the basic prepaid architecture the subscriberÆs device 373 establishes a connection with the SAD. The SAD communicates with the 374 VAAA using the RADIUS protocol. The VAAA, in turn, communicates 375 using the RADIUS protocol with BAAA servers in the broker network. 376 There maybe more then one Broker Network between the Visited Network 377 and the Home Network. The Home Network is the same as in the 378 architecture depicted in Figure 2. 380 The third scenario is a roaming scenario where the network utilises 381 Mobile-IP. It is depicted Figure 4. In this scenario the mobile 382 device moves between networks that use different technologies such 383 as between WLAN and Broadband. Mobile-IP addresses this type of 384 mobility and therefore we need not be concerned with the underlying 385 network technology. 387 +------+ +-------+ +----+ +----+ +----+ +-----+ 388 | | |Service| | | | | | | | | 389 |Subscr| |Access +-----|VAAA|--|BAAA|--|HAAA|--| PPS | 390 | |--|Device | | | | | | | | | 391 |Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+ 392 | | | | | | 393 +------+ +------ + | | 394 | | | +----+ 395 | | | | | 396 |ROAMS +------------------+ HA | 397 | | | | 398 V +----+ | +----+ 399 +------+ +-------+ | | | | 400 | | |Service| +-|VAAA+------+ | 401 |Subscr| |Access | | | | | 402 | |--|Device +-+ +----+ | 403 |Device| | (FA) | | 404 | | | +------------------------+ 405 +------+ +-------+ 406 Figure 4 Roaming using Mobile-IP and pre-paid enabled SADs 408 In Figure 4, the Subscriber Device establishes a session with the 409 SAD in the foreign network. The setup for this access service is 410 identical to the cases covered above. Note that the SAD may be 411 collocated with the Foreign Agent (FA) if Mobile-IPv4 is being used. 412 As the subscriber device moves, it establishes a connection with 413 another SAD possibly in another foreign network. The prepaid data 414 service should continue to be available. When a device associates to 415 another SAD it MUST re-authenticate at the new SAD and de-associate 416 or log off from the old SAD. Furthermore, any unused quota at the 417 old SAD MUST be credited into the subscriberÆs account immediately. 418 This has to happen immediately because otherwise, if the 419 subscriberÆs funds are low, he may be denied service at the new SAD. 421 Note that, if the SADs communicate directly with each other then 422 there could be a way to accelerate the handoff procedure. In 423 particular, the subscriber could be refunded more quickly. 424 Unfortunately, handoff procedures are specific to the underlying 425 network technologies and vary significantly in terms of delay. 427 2.3 428 Motivation 430 It has been asked ôWhy not use existing RADIUS attributes to 431 construct a protocol for prepaid scenarios? This will allow us to 432 have a solution with existing devices without code modification.ö 434 It is indeed possible to construct a solution for prepaid billing 435 scenarios using existing RADIUS attributes. The RADIUS server would 436 send an Access-Accept message containing a Session-Timeout(27) and 437 include a Termination-Action(29) in the RADIUS-request. Upon 438 receiving the Access-Accept message, the NAS would meter the 439 duration of the session and upon termination of the session the NAS 440 would generate an Access-Request message again. The RADIUS server 441 would then re-authenticate the session and reply with an Access- 442 Accept message indicating the amount of additional time in a 443 Session-Timeout(27). Alternatively, it would responds with an 444 Access-Reject message if there were no more resources in the userÆs 445 account. 447 Moreover, if the user terminates the session prematurely, the NAS 448 would recover any unused time from the accounting stream. 450 There are several problems with such a solution: 452 - It only supports time-based accounting. The solution presented in 453 this document supports both time and volume based prepaid. 455 - Using accounting messages to recoup unused time may be problematic 456 because RADIUS accounting messages are not delivered in real-time. 457 A RADIUS server may store-and-forward accounting messages in 458 batches. The solution presented in this document does not rely on 459 Accounting Packets at all. It uses Access-Request, messages which do 460 flow through any network in real-time. Delaying accounting messages 461 may cause revenue leakage. 463 - Session-Timeout(27) is not a mandatory attribute. If a prepaid 464 subscriber is being serviced by a NAS that does not adhere to 465 Session-Timeout then that subscriber may use the service for an 466 undetermined period of time. 468 - Termination-Action(29) presents its own issues. Firstly the 469 behaviour of Termination-Action(29) is not mandatory. Secondly, 470 according to RFC2865, Termination-Action fires when the provision of 471 the service has completed. However, service should not be terminated 472 when negotiating additional quota, because this should happen in a 473 manner transparent to the subscriber. Because Termination-Action 474 occurs when the Service is completed it is unclear whether or not 475 user experience would be affected. The RADIUS server might even 476 allocate a new IP address to the subscriberÆs device. Furthermore, 477 the RADIUS server has no way of telling why the Access-Request 478 message was generated. The RADIUS server might have to wait for the 479 corresponding accounting packet to determine the reason for this 480 Access-Request message. Finally, re-authenticating the subscriber 481 may take too long. The solution presented in this document allows 482 quota replenishing to occur in an undisruptive manner from the user 483 perspective. No re-authentication is required and quotas can be 484 negotiated prior to the available credit running out. 486 - Due to the fact that the standard RADIUS attributes are not 487 mandatory, the correct prepaid operation is really an act of faith 488 on the part of the RADIUS server. If Session-Timeout(27) and/or 489 Termination-Action(29) are not supported, the prepaid subscriber 490 might be able to obtain the service for free. The solution described 491 in this document requires that a prepaid-aware SAD informs the 492 RADIUS server, regardless of whether or not the latter supports the 493 prepaid extensions. The RADIUS server can then determine whether or 494 not service should be granted. For example, if a prepaid subscriber 495 is connected to a NAS that does not support prepaid, the RADIUS 496 server can either instruct the NAS to tunnel the traffic to another 497 entity in the home network (e.g. the Home Agent) that supports 498 prepaid, or it provide only a restricted service.] 500 The solution presented in this document requires the support of two 501 mandatory and one optional attribute. Furthermore, it does not 502 require a great amount of additional code at a NAS that already 503 supports time or volume metering. The solution requires that RADIUS 504 entities advertise their prepaid capabilities in an Access-Request 505 and that they generate an Access-Request Authorize-Only packet to 506 obtain more quota when or before the current quota is used up. It 507 also requires the NAS to send an Access-Request with Authorize-Only 508 when the session terminates in order to refund the subscriberÆs 509 account appropriately. 511 The solution provided in this document is extensible. For example, 512 the protocol can be extended to support tariff switching and other 513 prepaid business models. 515 The extensions described in this document were designed based on a 516 number of use cases and scenarios. An overview of these can be found 517 in Appendix A. 519 3. 520 Operations 522 3.1 523 General Requirements 525 3.1.1 526 Broker AAA Requirements 528 Broker AAA (BAAA) servers MUST support the Message-Authenticator(80) 529 attribute as defined in [RFC2869]. If they are used, they forward 530 the RADIUS packets as usual to the appropriate RADIUS servers. 532 Accounting messages are not needed to deliver a prepaid service. 533 However, accounting messages can be used to keep the PPS up to date 534 as to what is happening with the prepaid data session. Therefore, a 535 BAAA SHOULD deliver RADIUS Accounting messages using the pass 536 through mode described in [RFC2866]. 538 3.2 539 Authentication and Authorization for Prepaid Enabled SADs 541 The SAD initiates the authentication and authorization procedure by 542 sending a RADIUS Access-Request to the HAAA. 544 If the SAD has PPC capabilities, it MUST include the PPAC(TBD) 545 attribute in the RADIUS Access-Request. The PPAC(TBD) attribute 546 indicates to the PPS which prepaid capabilities are possessed by the 547 SAD. These are required in order to complete the prepaid 548 authorization procedure. 550 If the SAD supports the Disconnect-Message or the Change-of- 551 Authorization capabilities, then it SHOULD include the Dynamic- 552 Capabilities attribute. 554 In certain deployments, there may be other ways to terminate a data 555 session, or change authorization of an active session. For example, 556 some SADs provide a session termination service via Telnet or SNMP. 557 In these cases, the AAA server MAY add the Dynamic-Capabilities 558 message to the Access-Request. Upon receiving the Change-of- 559 Authorization message, the AAA server would then be responsible for 560 terminating the session using the means that are supported by the 561 device. 563 If the authentication procedure involves multiple message exchanges 564 (as in EAP), the SAD MUST include the PPAC(TBD) attribute and the 565 Dynamic-Capabilities attribute (if used) in at least the last 566 Access-Request of the authentication procedure. 568 The Access-Request is sent as usual to the HAAA. The packet may pass 569 through one or more BAAA. 571 Once the Access-Request arrives at the HAAA, the HAAA authenticates 572 the subscriber. If this fails, the HAAA sends an Access-Reject 573 message to the client. If authentication succeeds, the HAAA 574 determines whether or not the subscriber is a prepaid subscriber. 575 (How this is done is beyond the scope of this document.) If the 576 subscriber is not a prepaid subscriber, then the HAAA responds as 577 usual with an Access-Accept or an Access-Reject message. If the 578 subscriber is a prepaid subscriber then the HAAA SHALL forward the 579 Access-Request to the PPS for further authorization. 581 The Access-Request contains the PPAC(TBD) attribute and the Dynamic- 582 Capabilities attribute if one was included. The User-Name(1) 583 attribute MAY be set to a value that represents the subscriberÆs 584 identifier. This attribute is used by the PPS to locate his 585 account. For added security, the HAAA MAY also set the User- 586 Password(2) attribute to the password used between the HAAA and the 587 PPS. 589 The PPS locates the subscriberÆs account and authorizes him. During 590 this procedure, the PPS takes into consideration the SAD PPC 591 Capabilities. 593 Upon successful authorization, the PPS generates an Access-Accept 594 containing the PPAC(TBD) attribute and the PPAQ(TBD) attribute. 596 The PPAC attribute returned to the client indicates the type of 597 prepaid service to be provided for the session. The PPAQ(TBD) 598 attribute includes the following. 600 - The QUOTA-ID, which is set by the PPS to a unique value that is 601 used to correlate subsequent quota requests; 603 - Volume and/or Time quotas, which are set to values representing a 604 portion of the subscribers credit; 606 - It MAY contain a Time or Volume Threshold that controls when the 607 SAD should request additional quota; 609 - The IP address of the Serving PPS and one or more alternative 610 PPSs. This is used by the HAAA to route subsequent quota 611 replenishing messages to the appropriate PPS(s). 613 Note: Idle-Timeout(28) can be used to trigger the premature 614 termination of a prepaid service, for example as a result of 615 inactivity. 617 Depending on site policies, after failed authorization, the PPS may 618 generate an Access-Reject to terminate the session immediately. 619 Alternatively, the PPS may generate an Access-Accept blocking some 620 or all of the traffic and/or redirect some or all of the traffic to 621 a location to a fixed server. (This feature could be used, for 622 example, to prompt the user to replenish their account.) Blocking of 623 traffic is achieved by either Filter-ID(11) or NAS-Filter-Rule(see 624 Redirect I-d). Redirection is achieved by sending Redirect-Id or 625 Redirect-Rule, HTTP Redirection defined in the Redirect I-d. The 626 time period before the session is blocked/redirected is specified by 627 the Session-Timeout(27) attribute. 629 Upon receiving an Access-Accept from the PPS, the HAAA appends the 630 usual service attributes and forward the packet to the SAD. The 631 HAAA SHOULD NOT overwrite any attributes already set by the PPS. If 632 the HAAA, receives an Access-Reject message, it will simply forward 633 the packet to its client. Depending on site policies, if the HAAA 634 does not receive an Access-Accept or an Access-Reject message from 635 the PPS it MAY do nothing or send an Access-Reject or an Access- 636 Accept message back to the PPC. 638 3.3 639 Session Start Operation 641 The start of the session is indicated by the arrival of an 642 Accounting-Request(Start) packet. The Accounting-Request (Start) MAY 643 be routed to the PPS such that it can confirm the initial quota 644 allocation. 646 Note that the role of the PPS is not to record accounting messages 647 and therefore it SHOULD not respond with an Accounting Response 648 packet. 650 If the PPS does not receive the Accounting-Request(start) message it 651 will only know that the session has started upon the first reception 652 of a quota replenishment operation. 654 If the PPS does not receive indication directly (via Accounting- 655 Request(start)) or indirectly, it SHOULD after some configurable 656 time, deduce that the Session has not started. If the SAD supports 657 termination capabilities, the PPS SHOULD send a Disconnect Message 658 to the SAD to ensure that the session is indeed dead. 660 3.4 661 Mid-Session Operation 663 During the lifetime of a prepaid data session the SAD requests the 664 replenishment of the quotas using Authorize-Only Access-Request 665 messages. 667 Once either the allocated quota has been exhausted or the threshold 668 has been reached, the SAD MUST send an Access-Request with 669 Servicetype(6) set to a value of ôAuthorize Onlyö and the PPAQ(TBD) 670 attribute. 672 The SAD MUST also include NAS identifiers, and Session identifier 673 attributes in the Authorize Only Access-Request. The Session 674 Identifier should be the same as the one used during the Access- 675 Request. For example, if the User-Name(1) attribute was used in the 676 Access-Request it MUST be included in the Authorize Only Access- 677 Request, especially if the User-Name(1) attribute is used to route 678 the Access-Request to the Home AAA server. 680 The Authorize Only Access-Request MUST NOT include a User Password 681 and MUST NOT include a Chap Password. In order to authenticate the 682 message, the SAD MUST include a Message-Authenticator(80) attribute. 683 The SAD computes the value for the Message-Authenticator according 684 to [RFC2869]. 686 When the HAAA receives the Authorize-Only Access-Request that 687 contains a PPAQ(TBD), it SHALL validate the message using the 688 Message-Authenticator(80) as per [RFC2869]. If the HAAA receives an 689 Authorize Only Access-Request that contains a PPAQ(TBD) but not a 690 Message-Authenticator(80) it SHALL silently discard the message. An 691 Authorize Only Access-Request message that does not contain a 692 PPAQ(TBD) is either erroneous or belongs to another application (for 693 example, a Change of Authorization message [RFC3576]). In this case 694 the Authorize Only Access-Request is either silently discarded or 695 handled by another application. 697 Once the Authorize Only Access-Request message is validated, the 698 HAAA SHALL forward the Authorize Only Access-Request to the 699 appropriate PPS. The HAAA MUST forward the Authorize Only Access- 700 Request to the PPS specified in the PPAQ(TBD). The HAAA MUST add an 701 Message-Authenticator(80) to the message, according to [RFC2869]. 702 As with the Access-Request message, the HAAA MAY modify the User- 703 Name(1) attribute such that it represents the userÆs internal 704 prepaid account in the PPS. Note the PPS may also use the Quota-ID 705 sub-attribute contained within the PPAQ(TBD) to locate the user 706 account. 708 Upon receiving the Authorize Only Access-Request containing a 709 PPAQ(TBD) attribute, the PPS MUST validate the Message- 710 Authenticator(80) as described in [RFC2869]. If validation fails, 711 the PPS MUST silently discard the message. If it receives an 712 Authorize Only Access-Request message that does not contain a 713 PPAQ(TBD) it MUST silently discard the message. 715 The PPS locates the prepaid session state using the Quota Id 716 contained within the PPAQ(TBD). The PPS takes the most recently 717 allocated quota and subtracts it from the userÆs balance. If 718 sufficient balance remains, the PPS authorizes the PPS and allocates 719 additional quota. The PPS may also calculate a new threshold value. 721 Upon successful re-authorization, the PPS generates an Access-Accept 722 containing the PPAQ(TBD) attribute. The Access-Accept message MAY 723 contain Servicetype(6) set to Authorize-Only and MAY contain the 724 Message-Authenticator(80). 726 Depending on site policies, upon unsuccessful authorization, the PPS 727 generates an Access-Reject or an Access-Accept with Filter-Id(11) or 728 Ascend-Data-Filter (if supported) attribute and the Session- 729 Timeout(27) attribute such that the subscriber can get access to a 730 restricted set of locations for a short period of time. This feature 731 could be used to enable users to replenish their accounts, create 732 new accounts, or to browse free content. 734 Upon receiving the Access-Accept from the PPS, the HAAA SHALL return 735 the packet to its client. If the HAAA receives an Access-Reject 736 message, it forwards the packet. Depending on site policies, if the 737 HAAA does not receive an Access-Accept or an Access-Reject message 738 from the PPS it MAY do nothing or it MAY send an Access-Reject 739 message back to its client. 741 Upon receiving an Access-Accept, the SAD SHALL update its quotas and 742 threshold parameters with the values contained in the PPAQ(TBD) 743 attribute. Note that the PPS MAY update the PrePaidServer 744 attribute(s) and these may have to be saved as well. 746 Upon receiving an Access-Accept message that contains an Filter- 747 Id(11), an Ascend-Data-Filter attribute, or Session Timeout(27), the 748 SAD SHALL restrict the subscriber session accordingly. 750 3.5 751 Dynamic Operations 752 The PPS may take advantage of the dynamic capabilities that are 753 supported by the SAD as advertised in the Dynamic-Capabilities 754 attribute during the initial Access-Request. 756 There are two types of action that the PPS may perform. Firstly, it 757 may request the session to be terminated. Secondly, it may request 758 the attributes associated with the session to be modified. More 759 specifically, it may modify a previously sent PPAQ(TBD) 761 Both of these actions require that the session be uniquely 762 identified at the SAD. As a minimum the PPS MUST 764 - provide either the NAS-IP-Address(4) or the NAS-Identifier(32) 765 - provide at least one session identifier such as User-Name(1), 766 Framed-IP-Address(), the Accounting-Session-Id(44). 768 Other attributes could be used to uniquely identify a prepaid data 769 session. 771 3.5.1 772 Unsolicited Session Termination Operation 774 At anytime during a session the PPS may send a Disconnect Message in 775 order to terminate a session. This capability is described in 776 detail in [RFC3576]. The PPS sends a Disconnect Message that MUST 777 contain identifiers that uniquely identify the data session and the 778 SAD servicing that session. 780 If the SAD receives a Disconnect-Message, it responds with either a 781 Disconnect-ACK message (if it is able to terminate the session) or 782 with a Disconnect-NAK packet (otherwise). 784 Upon successful termination of a session the SAD MUST return any 785 unused quota to the PPS by issuing an Authorize Only Access-Request 786 containing the PPAQ which contains any unused Quota and the Update- 787 Reason set to ôRemote Forced Disconnectö. 789 3.5.2 790 Unsolicited Change of Authorization Operation 792 At any time during the session the PPC may receive a Change of 793 Authorization (CoA) message. A PPS may send a new Quota to either 794 add or to remove quota that is allocated to the service. 796 If the Change of Authorization contains a PPAQ then that PPAQ 797 overrides a previously received PPAQ. The PPS MUST NOT change the 798 units used in the PPAQ. 800 If the newly received PPAQ reduces the amount of allocated quota 801 beyond what is already used then the SAD accepts the new PPAQ and 802 act as it normally would when the quota is used up. For example, if 803 the threshold is reached then is request a quota update. 805 3.6 806 Termination Operation 808 The termination phase is initiated when (i) the subscriber logs off, 809 (ii) the subscriberÆs balances is exhausted, or (iii) when the SAD 810 receives a Disconnect Message. 812 In the case where the user logged off, or the SAD receives a 813 Disconnect Message, the SAD sends an Authorize-Only Access-Request 814 message with a PPAQ(TBD) and Update-Reason attribute set to either 815 ôClient Service terminationö or ôRemote Forced disconnectö. This 816 message indicates the already consumed quota. 818 In the case where the currently allocated quota is exhausted, if the 819 PPAQ(TBD) contained Termination-Action field, the SAD follows the 820 specified action (which would be to immediately terminate the 821 service), requests more quota, or redirects/filters the service. 823 3.7 824 Mobile IP Operations 826 In roaming scenarios with Mobile-IP, the prepaid data session should 827 be maintained transparently if the HA is acting as the SAD. 829 As the subscriber device associates with the new SAD (AP or PDSN 830 that supports PPC capability), the SAD sends a RADIUS Access-Request 831 and the subscriber is re-authenticated and reauthorized. The SAD 832 MUST include the PPAC(TBD) attribute in the RADIUS Access-Request. 833 In this manner the procedure follows the Authentication and 834 Authorization procedure described earlier. 836 If the HA was acting as the SAD before handoff, the userÆs prepaid 837 session does not undergo any change after the handoff because the 838 Mobile IP session is anchored at the HA and the userÆs Home IP 839 address remains the same. 841 In the case of a wireless access point or PDSN acting as the SAD it 842 is likely that the userÆs IP address will change (Care of Address). 843 The prepaid session will be affected by this. In this scenario the 844 SAD shall send an Access-Request message which is routed to the home 845 network and MUST reach the prepaid system that is serving this 846 session. The prepaid system correlates the new authorization 847 request with the existing active session and assigns a quota to the 848 new request. Any outstanding quota at the old SAD MUST be returned 849 to the prepaid system if the Mobile-IP nodes (HA and FA) support 850 registration revocation (Mobile IPv4 only). Specifically, the quota 851 SHOULD be returned when the SAD sends the Authorize Only Access- 852 Request with PPAQ(TBD) Update-Reason set to either ôRemote Forced 853 disconnectö or ôClient Service terminationö. In order to trigger 854 the sending of this last Authorize Only Access-Request, the prepaid 855 system may issue a Disconnect Message [3576] to the SAD. 857 Even if the subscriber moves to a SAD that does not have prepaid 858 capabilities can the prepaid data service continue. This can be done 859 by requesting the Home Agent (assuming that has such capabilities) 860 to take over the responsibilities of the SAD (i.e. metering). This 861 scenario will be discussed in a later version of this document. 863 3.8 864 Operation considerations for Multiple prepaid services 866 This section describes the support for multiple prepaid services on 867 a single SAD. Message flows illustrating the various interactions 868 are presented at the end of this document. 870 A SAD that supports prepaid operations for multi-services SHOULD set 871 the ôMulti-Services Supportedö bit in the PPAC. 873 When working with multi-services, we need to differentiate between 874 the services. A Service-Id attribute is used in the PPAQ(TBD) to 875 uniquely differentiate between the services. The exact definition 876 of the Service-Id attribute is outside the scope of this document. 878 A PPAQ that contains a Service-Id is associated with that Service. 879 A PPAQ that contains a Rating-Group-Id is associated with that 880 Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a 881 Service-Id. A PPAQ that contains neither a Rating-Group-Id or a 882 Service-Id applies to the ôAccess Serviceö. 884 3.8.1 885 Initial Quota Request 887 When operations with multi-services is desired, the SAD requests the 888 initial quota for the Service by sending a PPAQ containing the 889 Service-Id for that Service in an Authorize-Only Access-Request 890 packet. Similarly, if the SAD supports Rating-Groups then it may 891 request a quota for the Rating-Group by sending a PPAQ containing 892 the Rating-Group-Id. In both cases the Update-Reason is set to 893 ôInitial-Requestö. 895 The Authorize-Only Access-Request message may contain more than one 896 PPAQ. The Authorize-Only Access-Request MUST includes one or more 897 attributes that serve to identify the session so that it can be 898 linked to the original authentication. Which Session Identifiers 899 are included is up to specific deployments. The Authorize-Only 900 message must contain the Message-Authenticator(80) attribute for 901 integrity protection of the Authorize-Only Access-Request message. 903 Upon receiving an Authorize-Only Access-Accept message containing 904 one or more PPAQs, the prepaid system allocates resources to each 905 PPAQ. Each PPAQ is assigned a unique QID that MUST appear in 906 subsequent PPAQ updates for that service or rating-group. 907 Additionally, the PPAQ MUST contain the Service-ID or Group-ID, 908 unless the PPAQ is a generic ôAccess Serviceö. 910 3.8.2 911 Quota Update 913 Once the services start to utilize their allotted quota they will 914 eventually need to replenish their quotas (either the threshold is 915 reached or no more quota remains). To replenish the quota the PPC 916 sends an Authorize-Only Access-Request message containing one or 917 more PPAQs. Each PPAQ MUST contain the appropriate QID, Service-ID 918 or Group-ID (or neither the Service-ID or Group-Id if the quota 919 replenishment is for the ôAccess Serviceö). The Update-Reason filed 920 indicates either ôThreshold reachedö(3), or ôQuota reachedö(4). The 921 Authorize-Only message must contain session identifiers. 923 Upon receiving an Authorize-Only Access-Request packet with one or 924 more PPAQs the PPS responds with a new PPAQ for that service. The 925 PPAQ contains a new QID, the Service-Id or Rating-Group-Id, a new 926 Quota. If the PPS does not grant additional quota to the service it 927 MUST include the Termination-Action subfield in the PPAQ that will 928 instruct the SAD what to do with the service. 930 3.8.3 931 Termination 933 When the allotted quota for a service is exhausted the SAD shall act 934 in accordance to the Termination-Action field set in the Quota. If 935 the Termination-Action field is absent then the service MUST be 936 terminated. 938 If the service is to be terminated then the SAD shall send a PPAQ 939 with the appropriate QID, the Service-Id, the used quota, and 940 Update-Reason set to ôClient Service Terminationö. 942 If the ôAccess Serviceö has terminated, then all other services must 943 be terminated as well. In this case the SAD MUST report on all 944 issued quotas for the various services. The Update-Reason field 945 should be set to ôAccess Service Terminatedö. 947 3.8.4 948 Dynamic Operations 950 Dynamic operations for multi-services are similar to dynamic 951 operations described for single service operations. The prepaid 952 system may send a COA message containing a PPAQ for an existing 953 service instance. The SAD matches the PPAQ with the service using 954 the Service-ID attribute. The new quota could differ from the 955 previously allocated value. The SAD must react to the new value 956 accordingly. 958 A disconnect message terminates the ôAccess Serviceö. As such the 959 SAD MUST report all unused quotas by sending an Authorize Only 960 Access Request message containing a PPAQ for each active service. 961 The Update-Reason shall indicate that the reason for the update. 963 3.8.5 964 Support for Resource Pools 966 If the PPC supports pools as indicated by setting the ôPools 967 supportedö bit in the PPAC(TBD) then the PPS may associate a Quota 968 with a Pool by including the Pool-Id and the Pool-Multiplier in the 969 PPAQ(TBD). 971 When Resource Pools are used, the PPAQ must not use the threshold 972 field. 974 3.8.6 975 One-Time-Charging 977 To initiate a One-Time charge the PPC includes the PPAQ attribute in 978 an Access-Request packet. The Access Request packet MUST include a 979 Message-Authenticator(80) and an Event-Timestamp(55) attribute. 981 The Service Id field of the PPAQ identifies the prepaid service. 982 The amount to be charged is specified using the Resource Quota and 983 Resource Quota overflow subtypes. If the value specified is 984 negative then the resources are credited to the userÆs account. 986 The QID field MUST be set to a unique value and is used by the PPS 987 to detect duplicates. The Update Reason field MUST be set to One- 988 Time Charging. 990 Upon receiving a One-Time charge PPAQ, the RADIUS server 991 authenticates the user and, if successful, passes the PPAQ to the 992 PPS. The PPS locates the account and debits or credits it 993 accordingly. The PPS MUST respond to the PPS with an Access-Accept 994 message if successful, or an Access-Reject message otherwise. 996 The RADIUS server shall respond to the SAD with an Access Accept 997 message. Since this is a one-time charge the SAD must not allow the 998 session to continue. Therefore, the RADIUS server should include in 999 the Access-Accept a Session-Timeout set to 0. Upon receiving an 1000 Access-Accept response the SAD shall generate an Accounting Stop 1001 message. 1003 A PPAQ used for One-Time charging may appear in an Authorize-Only 1004 Access Request. This is the case when the session already exists. 1005 The PPS responds with an Access-Accept to indicate that the userÆs 1006 account has been debited or an Access-Reject otherwise. 1008 3.8.7 1009 Error Handling 1011 If the PPS receives a PPAQ with an invalid QID it MUST ignore that 1012 PPAQ. 1014 If the PPS receives a PPAQ containing a Service-Id, or a Rating- 1015 Group-Id that it does not recognize, then it MUST ignore that PPAQ. 1017 If the PPC receives a PPAQ containing a Service-Id, or a Rating- 1018 Group-Id that it does not recognize, then it must ignore that PPAQ. 1020 If the PPC receives a PPAQ that contains a Pool-Id without a Pool- 1021 Multiplier or a Pool-Multiplier without a Pool-Id it must ignore 1022 that PPAQ. 1024 3.9 1025 Accounting Considerations 1027 Although typically generated, accounting messages are not required 1028 to deliver a prepaid data service. When generated, accounting 1029 messages are used for auditing purposes and for billing. 1031 Accounting messages associated with prepaid data sessions should 1032 include the PPAQ(TBD) attribute. 1034 3.10 1035 SAD Operation 1037 To be completed 1039 3.11 1040 Interoperability with Diameter Credit Control Application 1042 The RADIUS prepaid extensions need to interoperate with the Diameter 1043 protocol. Two possibilities exist: The AAA infrastructure is 1044 Diameter based and the SAD are RADIUS based, or the SAD is Diameter 1045 based and the AAA infrastructure is RADIUS based. 1047 The Diameter Credit Control Application [DIAMETERCC] describes how 1048 to implement a prepaid accounting system using an Diameter based 1049 infrastructure. 1051 1053 4. 1054 Attributes 1056 This draft is using the RADIUS [RFC2865] namespace. 1058 4.1 1059 PPAC Attribute 1061 The PrepaidAccountingCapability (PPAC) attribute is sent in the 1062 Access-Request message by a prepaid capable NAS and is used to 1063 describe the prepaid capabilities of the NAS. The PPAC is present 1064 in an Access-Accept message by the PPS to indicate the type of 1065 metering that is to be applied to this session. 1067 0 1 2 3 1068 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 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | TYPE | LENGTH | SUBtype 1 | LENGTH | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | AvailableInClient (AiC) | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 TYPE : value of PPAC 1076 LENGTH: 8 1077 VALUE : String 1079 The value MUST be encoded as follows: 1081 Subtype (=1) : Subtype for AvailableInClient attribute 1082 Length : Length of AvailableInClient attribute 1083 (= 6 octets) 1084 AvailableInClient (AiC): 1086 The optional AvailableInClient Subtype, generated by the PPC, 1087 indicates the metering capabilities of the NAS and shall be bitmap 1088 encoded. The possible values are: 1090 0x00000001 Volume metering supported. 1091 0x00000002 Duration metering supported. 1092 0x00000004 Resource metering supported. 1093 0x00000008 Pools supported 1094 0x00000010 Rating groups supported 1095 0x00000020 Multi-Services supported. 1096 0x00000040 Tariff Switch supported. 1098 Others Reserved 1100 4.2 1101 Session Termination Capability 1103 The value shall be bitmap encoded rather than a raw integer. This 1104 attribute shall be included RADIUS Access-Request message to the 1105 RADIUS server and indicates whether or not the NAS supports Dynamic 1106 Authorization. 1108 0 1 2 3 1109 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 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | TYPE | LENGTH | String | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 Type : value of Session Termination Capability 1115 Length: = 4 1116 String encoded as follows: 1118 0x00000001 Dynamic Authorization Extensions (rfc3576) is 1119 supported. 1121 4.3 1122 PPAQ Attribute 1124 One or more PPAQ(TBD) attributes are sent in an Access Request, 1125 Authorize Only Access-Request and Access-Accept messages. In an 1126 Access Request message, the PPAQ attribute is used to facilitate 1127 One-Time charging transactions. In Authorize Only Access-Request 1128 messages it is used for One-Time charging, report usage and the 1129 request for further quota. It is also used to request prepaid quota 1130 for a new service instance. In an Access-Accept message it is used 1131 to allocate the (initial and subsequent) quotas. 1133 When multiple services are supported, a PPAQ is associated with a 1134 specific service as indicated by the presence of a Service-Id, a 1135 Rating-Group-Id, or the ôAccess Serviceö (as indicated by the 1136 absence of a Service-Id and a Rating-Group-Id). 1138 The attribute consists of a number of subtypes. Unused subtypes are 1139 omitted from the message. 1141 0 1 2 3 1142 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 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | TYPE | LENGTH | SUBtype 1 | LENGTH | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | QuotaIdentifier (QID) | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | SUBtype 2 | LENGTH | Volume Quota | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Volume Quota | SUBtype 3 | LENGTH | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | VolumeQuotaOverflow (VQO) | SUBtype 4 | LENGTH | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | VolumeThreshold (VT) | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | SUBtype 5 | LENGTH | VolumeThresholdOverflow (VTO) | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | SUBtype 6 | LENGTH | DurationQuota (DQ) | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | DurationQuota (DQ) | SUBtype 7 | LENGTH | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | DurationThreshold (DT) | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | SUBtype 8 | LENGTH | Update-Reason attribute (UR) | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | SUBtype 9 | LENGTH | PrePaidServer | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | PrePaidServer | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | SUBtype 10 | LENGTH | Service-Id | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | SUBtype 11 | LENGTH | Rating-Group-Id | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | | SUBtype 12 | LENGTH | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Termination-Action | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | SUBtype 13 | LENGTH | Pool-Id | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | | SUBtype 14 | LENGTH | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Pool-Multiplier | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | SUBtype 15 | LENGTH | Resource-Quota | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | | SUBtype 16 | LENGTH | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Resource-Quota-Overflow | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | SUBtype 18 | LENGTH | Resource-Threshold | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 Type : Value of PPAQ 1198 Length: variable, greater than 8 1200 String: The String value MUST be encoded as follows: 1202 Subtype (=1): Subtype for QuotaIDentifier attribute 1203 Length : Length of QuotaIDentifier attribute (= 6 octets) 1205 QuotaIDentifier (QID): 1207 The QuotaIDentifier subtype is generated by the PPS together with 1208 the allocation of a Volume or Duration Quota. The on-line quota 1209 update RADIUS Access-Request message sent from the SAD to the PPS 1210 shall include a previously received QuotaIDentifier. 1212 Subtype (=2): Subtype for VolumeQuota attribute 1213 Length : length of VolumeQuota attribute (= 6 octets) 1215 VolumeQuota (VQ): 1217 The optional VolumeQuota subtype is only present if Volume Based 1218 charging is used. In a RADIUS Access-Accept message (PPS to SAD 1219 direction), it indicates the Volume (in octets) allocated for the 1220 session by the PPS. In RADIUS Authorize Only Access-Request 1221 message (SAD to PPS direction), it indicates the total used 1222 volume (in octets) for both forward and reverse traffic. 1224 Subtype (=3): Subtype for VolumeQuotaOverflow 1225 Length : length of VolumeQuotaOverflow attribute (= 4 octets) 1227 VolumeQuotaOverflow (VQO): 1229 The optional VolumeQuotaOverflow subtype is used to indicate how 1230 many times the VolumeQuota counter has wrapped around 2^32 over 1231 the course of the service being provided. 1233 Subtype (=4): Subtype for VolumeThreshold attribute 1234 Length : length of VolumeThreshold attribute (= 6 octets) 1236 VolumeThreshold (VT): 1238 The VolumeThreshold Subtype shall always be present if 1239 VolumeQuota is present in a RADIUS Access-Accept message (PPS to 1240 SAD direction). It is generated by the PPS and indicates the 1241 volume (in octets) that shall be consumed before a new quota 1242 should be requested. This threshold should not be larger than the 1243 VolumeQuota. 1245 Subtype (=5): Subtype for VolumeThresholdOverflow 1246 Length : Length of VolumeThresholdOverflow attribute 1247 (= 4 octets) 1249 VolumeThresholdOverflow (VTO): 1251 The optional VolumeThresholdOverflow subtype is used to indicate 1252 how many times the VolumeThreshold counter has wrapped around 1253 2^32 over the course of the service being provided. 1255 Subtype (=6): Subtype for DurationQuota attribute 1256 Length : length of DurationQuota attribute (= 6 octets) 1258 DurationQuota (DQ): 1260 The optional DurationQuota Subtype is only present if Duration 1261 Based charging is used. In RADIUS Access-Accept message (PPS to 1262 SAD direction), it indicates the Duration (in seconds) allocated 1263 for the session by the PPS. In on-line RADIUS Access-Accept 1264 message (PPC to PPS direction), it indicates the total Duration 1265 in seconds) since the start of the accounting session related to 1266 the QuotaID. 1268 Subtype (=7): Subtype for DurationThreshold attribute 1269 Length : length of DurationThreshold attribute (= 6 octets) 1271 DurationThreshold (DT): 1273 The DurationThreshold subtype shall always be present if 1274 DurationQuota is present in a RADIUS Access-Accept message (PPS 1275 to SAD direction). It represents the duration (in seconds) after 1276 which new quota should be requested. This threshold should not be 1277 larger than the DurationQuota. 1279 Subtype (=8): Subtype for Update-Reason attribute 1280 Length : length of Update-Reason attribute (= 4 octets) 1282 Update-Reason attribute (UR): 1284 The Update-Reason subtype shall be present in the on-line RADIUS 1285 Access-Request message (SAD to PPS direction). It indicates the 1286 reason for initiating the on-line quota update operation. Update 1287 reasons 4, 5, 6, 7 and 8 indicate that the associated resources 1288 are released at the client side, and therefore the PPS shall not 1289 allocate a new quota in the RADIUS Access_Accept message. 1291 1. Pre-initialization 1292 2. Initial Request 1293 3. Threshold Reached 1294 4. Quota Reached 1295 5. Remote Forced Disconnect 1296 6. Client Service Termination 1297 7. ôAccess Serviceö Terminated 1298 8. Service not established 1299 9. One-Time Charging 1301 Subtype (=9) : Subtype for PrePaidServer attribute 1302 Length : Length of PrePaidServer 1303 (IPv4 = 6 octets, IPv6= 18 octets 1305 PrePaidServer: 1307 The optional, multi-value PrePaidServer attribute indicates the 1308 address of the serving prepaid system. If present, the Home 1309 RADIUS server uses this address to route the message to the 1310 serving PPS. The attribute may be sent by the Home RADIUS server. 1312 If present in the incoming RADIUS Access-Accept message, the PDSN 1313 shall send this attribute back without modifying it in the 1314 subsequent RADIUS Access-Request message, except for the first 1315 one. If multiple values are present, the PDSN shall not change 1316 their order. 1318 Subtype (=10) : Subtype for Service ID 1319 Length : Length of Service ID 1321 Service-Id: 1323 Opaque string that uniquely describes a service instance to which 1324 prepaid metering should be applied. A Service-Id could be an IP 1325 5-tuple (source address, source port, destination address, 1326 destination port, protocol). If Service-ID is present in the PPAQ 1327 the PPAQ refers to that service. If a PPAQ does not contain a 1328 Service-Id then the PPAQ refers to the Access Service. 1330 Subtype (=11) : Subtype for Rating-Group-Id 1331 Length : 6 1333 Rating-Group-Id 1335 Identifies that this PPAQ is associated with resources allocated 1336 to a Rating Group with the corresponding ID. 1338 Subtype (=12) : Subtype for Termination-Action 1339 Length : 6 1341 This field is an enumeration of the action to take when the PPS does 1342 not grant additional quota. Valid actions are as follows: 1344 0 Reserved 1345 1 Terminate 1346 2 Request More Quota 1347 3 Redirect/Filter 1349 Subtype (=13) : Pool-Id 1350 Length : 6 1352 Identifies the Pool that this quota is to be associated with. 1354 Subtype (=14) : Pool-Multiplier 1355 Length : 6 1357 The pool-multiplier determines the weight that resources are 1358 inserted into the pool and the rate at which resources are taken out 1359 of the pool by this service or Rating-Group. 1361 Subtype (=15) : Subtype for Resource-Quota 1362 Length : 6 1364 The optional Resource-Quota subtype is only present if Resource 1365 Based or one-time charging is used. In the RADIUS Access-Accept 1366 message (PPS to SAD direction) it indicates the Resources 1367 allocated for the session by the PPS. In RADIUS Authorize Only 1368 Access-Request message (SAD to PPS direction), it indicates the 1369 resources used in total, including both incoming and outgoing 1370 chargeable traffic. In one-time charging scenarios, the subtype 1371 represents the number of units to charge or credit the user. 1373 Subtype (=16) : Subtype for Resource Quota Overflow 1374 Length : 6 1376 Subtype (=18) : Subtype for ResourceThreshold 1377 Length : 6 1379 NOTES: 1381 Volume-Quota, Time-Quota, or Resource-Quota MUST appear in the 1382 attribute. If Volume Quota appears, Volume Threshold may also 1383 appear. 1385 A PPAQ MUST NOT contain both a Service-Id and a Rating-Group-Id. 1387 A PPAQ that does not contain a Service-ID or a Rating-Group-Id 1388 applies to the ôAccess Serviceö. 1390 When the PPAQ contains a Pool-Id it MUST also contain the Pool- 1391 Multiplier. 1393 4.4 1394 Prepaid Tariff Switching (PTS) 1396 This specification defines the PTS attribute to allow for 1397 changeovers from one rate to another during service provision. 1399 Support for tariff switching is OPTIONAL for both PPC and PPS. PPCs 1400 use the flag "Tariff Switching supported" of the AvailableInClient 1401 subtype of the PPAC attribute to indicate support for tariff 1402 switching. PPSs employ the PTS attribute to announce their support 1403 for tariff switching. Details of this will be specified after the 1404 format of the PTS attribute has been defined. 1406 If a RADIUS message contains a PTS attribute, it MUST also contain 1407 at least one PPAQ attribute. If a RADIUS Access-Request message 1408 contains a PTS attribute or a "Tariff Switching supported" flag, it 1409 MUST also contain an Event-Timestamp RADIUS attribute (see 1410 [RFC2869]). 1412 0 1 2 3 1413 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 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | TYPE | LENGTH | SUBtype 1 | LENGTH | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | QuotaIDentifier (QID) | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | SUBtype 2 | LENGTH | VolumeUsedAfter- | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | TariffSwitch (VUATS) | SUBtype 3 | LENGTH | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | VUATSOverflow (VUATSO) | SUBtype 4 | LENGTH | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | TariffSwitchInterval (TSI) | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | SUBtype 5 | LENGTH | TimeIntervalAfter- | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | TariffSwitchUpdate (TITSU) | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 Type : Value of PTS 1433 Length: variable, at least 8 1434 Subtype (=1): QuotaIDentifier (QID) 1435 Length : Length of QuotaIDentifier Subtype (= 6 octets) 1437 The QID subtype MUST be present in each PTS attribute. In an 1438 online RADIUS Access-Request message sent from the PPC to the 1439 PPS, its value MUST be a quota identifier received previously 1440 from the PPS and MUST be the same as a quota identifier of one of 1441 the PPAQ attributes included the same RADIUS message. 1443 A PPAQ attribute that is transported along with a PTS attribute 1444 and has the same quota identifier value as the PTS attribute in 1445 its own QID subfield shall be referred to as "accompanying PPAQ 1446 attribute". If a PPS receives an Access-Request message from a 1447 PPC, it associates a unique quota identifier to this request. 1448 Thus, a quota identifier also identifies a particular service. 1450 Subtype (=2): VolumeUsedAfterTariffSwitch (VUATS) 1451 Length : Length of VolumeUsedAfterTariffSwitch Subtype 1452 (= 6 octets) 1454 The VolumeUsedAfterTariffSwitch subtype SHALL be used in online 1455 RADIUS Access-Request messages (PPC to PPS direction). It 1456 indicates the volume (in octets) used during a session after the 1457 last tariff switch for the service specified via the QID subfield 1458 and the accompanying PPAQ attribute (see the remarks under 1459 "Subtype 1: QID"). 1461 Subtype (=3): VUATSOverflow (VUATSO) 1462 Length : Length of VUATSOverflow Subtype (= 4 octets) 1464 If an online RADIUS Access-Request message contains a VUATS 1465 subfield and if the VolumeUsedAfterTariffSwitch has wrapped 1466 around 2^32 over the course of provisioning the service 1467 identified via the QID subfield, then the VUATSO subfield MUST be 1468 present in the PTS attribute. In this case, it indicates how 1469 many times the VolumeUsedAfterTariffSwitch has wrapped around 1470 2^32. In all other cases, the VUATSO subfield MUST NOT be 1471 present in the PTS attribute. 1473 Subtype (=4): TariffSwitchInterval (TSI) 1474 Length : Length of TSI Subtype (= 6 octets) 1476 The TSI subtype MUST be present in each PTS attribute that is 1477 part of a RADIUS Access-Accept message (PPS to PPC direction). 1478 It indicates the interval (in seconds) between the value of 1479 Event-Timestamp RADIUS attribute (see [RFC2869]) of the 1480 corresponding RADIUS Access-Request message and the next tariff 1481 switch condition. 1483 Subtype (=5): TimeIntervalafterTariffSwitchUpdate (TITSU) 1484 Length : Length of TITSU Subtype 1485 (= 6 octets) 1487 The PPS MUST include the TITSU subtype if there is another tariff 1488 switch period after this period. The TITSU attributes encodes 1489 the number remaining seconds of current tariff period. If this 1490 attribute is zero or omitted, it is assumes that the current 1491 tariff period lasts until further notice. If TITSU is specified, 1492 the PPC must send a quota update before the current period ends. 1494 If a RADIUS message contains a PTS attribute, it MUST also contain 1495 at least one PPAQ attribute. The PTS is associated with the PPAQ by 1496 the QID. If multiple services are supported and if the PPAQ is 1497 associated with a service as indicated by the Service-Id sub- 1498 atrribute of the PPAQ, then the PTS refers to the tariff switch for 1499 that service. If the PPAQ does not have a Service-Id, then the PTS 1500 refers to tariff switch for the Access-Service. 1502 If a PPC supports tariff switching then it MUST set the 0x00000040 1503 (Tariff switching supported) flag of the AvailableInClient subtype 1504 of the PPAC attribute that is contained in the Access-Request packet 1505 starting the session. 1507 4.5 1508 Table of Attributes 1510 TO BE COMPLETED. 1512 Request Accept Reject Challenge # Attribute 1514 Authorize_Only Request Accept Reject 1516 5. 1517 Security Considerations 1519 The extended RADIUS protocol described in this document is subject 1520 to a number of potential attacks, in a manner similar to the RADIUS 1521 without these extensions. It is recommended that IPsec be employed 1522 to protect against certain of the attacks. 1524 If IPsec is not available, usage of the extensions described in this 1525 document improve the overall security of RADIUS. The various 1526 security enhancements are explained in the following sections. 1528 5.1 1529 Authentication and Authorization 1531 RADIUS is susceptible to replay attacks during the Authentication 1532 and Authorization procedures. A successful replay of the initial 1533 Access-Request could result in an allocation of an initial quota. 1535 To thwart such an attack... 1537 5.2 1538 Replenishing Procedure 1540 A successful replay attack of the Authorize Only Access-Request 1541 could deplete the subscribers prepaid account. 1543 To be completed. 1545 6. 1546 IANA Considerations 1548 This document requires the assignment of new Radius attributes type 1549 numbers for the following attributes: 1551 1) Prepaid-Accounting-Capability (PPAC) 1552 with subtype: 1553 AvailableInClient 1555 2) Prepaid-Accounting-Operation (PPAQ) 1556 with subtypes: 1557 QuotaID (QID) 1558 VolumeQuota (VQ) 1559 VolumeQuotaOverflow (VQO) 1560 VolumeTreshold (VT) 1561 VolumeTresholdOverflow (VTO) 1562 DurationQuota (DQ) 1563 DurationTreshold (DT) 1564 UpdateReason (UR) 1565 PrePaidServer (PPS) 1566 ServiceID (SID) 1567 RatingGroupId (RGID) 1568 TerminationAction (TA) 1569 PoolID (PID) 1570 PoolMultiplier (PM) 1571 Cost (COST) 1572 TariffChangeTime (TCT) 1574 3) Prepaid-Tariff-Switch (PTS) 1576 4) Session-Termination-Capability (STC) 1578 5) International-Mobile-Subscriber-Identity (IMSI) 1580 7. 1581 Normative References 1583 [RFC2026] Bradner, S., "The Internet Standards Process -- 1584 Revision 3", RFC 2026, October 1996. 1585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1586 Requirement Levels", RFC 2119, March 1997. 1587 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 1588 "Remote Authentication Dial In User Server 1589 (RADIUS)", RFC 2865, June 2000. 1591 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 1592 2000. 1594 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 1595 Extensions", RFC 2869, June 2000. 1597 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., 1598 Holdrege, M., Goyret, I., "RADIUS Attributes for 1599 Tunnel Protocol Support" , RFC 2868, June 2000. 1600 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., 1601 Aboba, B., "Dynamic Authorization Extensions to 1602 Remote Authentication Dial-In User Service 1603 (RADIUS)", RFC 3576, February 2003. 1605 [RFC3748] Aboba, B., et al., "Extensible Authentication 1606 Protocol", RFC 3748, June 2004. 1608 8. 1609 Informative References 1611 [DIAMETERCC] Hakkala, H., et al., "Diamter Credit-Control 1612 Application", Internet Draft, AAA WG, April 2004, 1613 Work in Progress. 1615 [REDIRECT] "RADIUS Redirection", Internet Draft, Work in 1616 progress. 1618 9. 1619 Call Flows 1621 This section describes the flows associated with various scenarios 1622 that are mentioned in this document. The following fields are used 1623 in the call flows: 1625 RADIUS packets: 1627 AR Access Request 1628 ARA Access Accept 1629 AC Accounting Requests 1630 A Authorize-Only Access-Request 1631 AA Access-Accept for Authorize- 1632 Only Access-Request 1634 RADIUS Attributes: 1636 PPAQ PPAQ as defined in this 1637 specification 1638 SID One or more attributes 1639 representing the Session that 1640 the RADIUS packets is correlated 1641 to. 1642 PPAC PPAC as defined in this 1643 specification 1644 ASID Acct-Session-Id as defined by 1645 RADIUS 1646 MSID Acct-Multi-Session-Id as define 1647 by RADIUS 1649 PPAQ fields: 1651 SRVID Service-Id 1652 Reason Update-Reason 1653 QID Quota-Id 1655 9.1 1656 Simple Concurrent Services 1658 In this scenario the PPC authenticates and authorizes the user. The 1659 PSS responds with Quota for the ôAccess Serviceö instance. The NAS 1660 then request quota for Service-A. 1662 Accounting is turned on. 1664 NAS/ RADIUS/ 1665 PPC PPS 1666 === === 1667 | | 1668 | AR{SID,PPAC} | 1669 A |-------------------------------------------------->| 1670 | | 1671 | ARA{SID,PPAQ(QID=1,Q=100)} | 1672 B |<--------------------------------------------------| 1673 | | 1674 | AC(start){ASID=25,MSID=13} | 1675 C |-------------------------------------------------->| 1676 | | 1677 | A{SID,PPAQ(SRVID=SA, Reason=Initial} | 1678 D |-------------------------------------------------->| 1679 | | 1680 | AA{SID,PPAQ(QID=200,SRVID=SA, Q=50)} | 1681 E |<--------------------------------------------------| 1682 | | 1683 | AC(start){ASID=30,MSID=13, PPAQ } | 1684 F |-------------------------------------------------->| 1685 | | 1686 | A{SID, PPAQ(QID=200 SRVID=SA, Q=50 Reason=Quota)}| 1687 G |-------------------------------------------------->| 1688 | | 1689 | AA{SID,PPAQ(QID=300,SRVID=SA, Q=100)} | 1690 H |<--------------------------------------------------| 1691 | | 1692 | A{SID, | 1693 | PPAQ(QID=1, Q=100 Reason=Quota), | 1694 | PPAQ(QID=300, SRVID=SA Q=100 Reason=Quota)} | 1695 I |-------------------------------------------------->| 1696 | | 1697 | AA{SID, 1698 | PPAQ(QID=3, Q=200), | 1699 | PPAQ(QID=303, SRVID=SA Q=150)} | 1700 J |<--------------------------------------------------| 1702 A This is the initial Access-Request that indicates the prepaid 1703 capabilities of the NAS. In this example indicates that 1704 Concurrent Sessions are supported. Access-Request also 1705 includes SID (Session Id) which is the Session Identifier 1706 assigned by this NAS to session. The formal of the session 1707 identifier is outside the scope of this document. 1708 B RADIUS authenticates the user and determines that he has a 1709 prepaid account. RADIUS responds with a PPAQ for the ôAccess 1710 Serviceö (PPAQ does not contain a Service-ID or Rating-Group- 1711 ID). The PPAQ has a QID=1 assigned by the Prepaid System and 1712 Quota of Q=100. The quota could be time or volume and may or 1713 may not have a threshold associated with it. 1714 C The NAS starts the Access Service and generates an Accounting- 1715 Request (Start) message as normal. It includes the Acct- 1716 Session-Id and may include the Acct-Multi-Session-Id. 1717 D The NAS is about to start a new Service, call it Service-A. 1718 It sends an Authorize-Only access request to RADIUS. The SID 1719 links this Authorize-Only access request to the initial 1720 Authentication & Authorization (Step-A and Step-B).The 1721 Authorize-Only message contains a PPAQ requesting quota for 1722 Service-A, Update-Reason = Initial-Request. 1724 E The PPS checks the resources available to the user and assigns 1725 50 units (time/volume etc) to this service. RADIUS sends an 1726 Access Accept message contain a PPAQ assigning quota Q=50 for 1727 Service-A. The PPAQ contains a QID = 200. 1728 F The NAS starts Service-A and sends an Accounting-Request 1729 (Start) message for that service. Acct-Multi-Session-Id can be 1730 used to tie all of the sessions in the accounting streams 1731 together. 1732 G Quota for Service-A requires refreshing, the quota was 1733 completely used). An Authorize-Only message is sent 1734 containing a PPAQ with QID = 200 which corresponds to the 1735 prior QID received for this service. Note QID is sufficient 1736 for the PPS server to link this request to the previous 1737 request and hence to the original authentication steps. 1738 Therefore SID is not really required. The PPAQ will report the 1739 used part of the quota (50 units). 1740 H RADIUS deducts the used quota from the users accounts and 1741 reserves 50 more additional units for a total quota of 100 1742 (Q=100) for Service-A. It sends back a PPAQ with QID=300. 1743 I NAS needs to refresh both the ôAccess Serviceö and Service-A. 1744 It sends an Authorize Only message contain two PPAQs, one for 1745 the Main Service with QID=1 and one for Service-A with 1746 QID=300. Each PPAQ reports the resources that were consumed 1747 so far and the reason why the update is being sent. 1748 J RADIUS responds back with two PPAQs. The PPAQ without the 1749 Service-Id grants an additional 100 units for a total of 200 1750 units to the ôAccess Serviceö û QID=3; the other PPAQ, 1751 containing SRVID=SA grants an additional 50 units for a total 1752 quota to service-a of 150 units û QID=303. 1754 This step illustrates why SRVID needs to be specified in the 1755 PPAQ. Without it the NAS would be unable to differentiate 1756 between the PPAQs. QIDs are not sufficient to correlate the 1757 PPAQ to a service since they may be changed by the PPS at 1758 every transaction. 1760 Note how each PPAQ attribute represents a sequential conversation 1761 about a service between the PPC and the PPS in this example. The 1762 links between the messages are the QIDs and the Service-Ids. 1764 Also note that a SID is needed to tie the Authorize-Only messages to 1765 the Authentication steps. This SID is only really needed the first 1766 time a PPAQ is sent. 1768 Although accounting messages have an Accounting-Session-ID, that is 1769 not enough to enable the back end system to associate that 1770 accounting message with a particular Service. We therefore need the 1771 PPAQ in the accounting message. 1773 9.2 1774 One-time Charging 1776 In this One-time charging example, the PPC authenticates and 1777 authorizes the user and requests charging for a service event 1778 requested by the user. The PPC already knows the price to charge 1779 for the service event identified by SRVID=SA. 1781 Contributor 1783 We would like to thank Hannes Tschofenig for his contributions to 1784 this draft. 1786 Acknowledgments 1788 The authors would like to thank Mark Grayson (Cisco), Nagi Jonnala 1789 and Tseno Tsenov for their contribution to this draft. 1791 Author's Addresses 1793 Avi Lior Parviz Yegani, Ph.D. 1794 Bridgewater Systems Mobile Wireless Group 1795 303 Terry Fox Drive Cisco Systems 1796 Suite 100 3625 Cisco Way 1797 Ottawa Ontario San Jose, CA 95134 1798 Canada USA 1799 avi@bridgewatersystems.com pyegani@cisco.com 1801 Kuntal Chowdhury Hannes Tschofenig 1802 Starent Networks Siemens 1803 30 International Place, 3rd Flr Otto-Hahn-Ring 6 1804 Tewksbury, MA 01876 81739 Munich 1805 kchowdhury@starentnetworks.com Germany 1806 hannes.tschofenig@siemens.com 1808 Christian Guenther 1809 Siemens 1810 Otto-Hahn-Ring 6 1811 81739 Munich 1812 Germany 1813 christian.guenther@siemens.com 1815 Intellectual Property Statement 1817 The IETF takes no position regarding the validity or scope of any 1818 Intellectual Property Rights or other rights that might be claimed 1819 to pertain to the implementation or use of the technology described 1820 in this document or the extent to which any license under such 1821 rights might or might not be available; nor does it represent that 1822 it has made any independent effort to identify any such rights. 1823 Information on the IETF's procedures with respect to rights in IETF 1824 Documents can be found in BCP 78 and BCP 79. 1826 Copies of IPR disclosures made to the IETF Secretariat and any 1827 assurances of licenses to be made available, or the result of an 1828 attempt made to obtain a general license or permission for the use 1829 of such proprietary rights by implementers or users of this 1830 specification can be obtained from the IETF on-line IPR repository 1831 at http://www.ietf.org/ipr. 1833 The IETF invites any interested party to bring to its attention any 1834 copyrights, patents or patent applications, or other proprietary 1835 rights that may cover technology that may be required to implement 1836 this standard. Please address the information to the IETF at ietf- 1837 ipr@ietf.org. 1839 Disclaimer of Validity 1841 This document and the information contained herein are provided on 1842 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1843 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1844 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1845 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1846 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1847 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1849 Copyright Statement 1851 Copyright ¨ The Internet Society (2005). This document is subject to 1852 the rights, licenses and restrictions contained in BCP 78, and 1853 except as set forth therein, the authors retain all their rights. 1855 Expiration Date 1857 This memo is filed as draft-lior-radius-extensions-for-prepaid- 1858 06.txt, and will expire 20 July, 2005. 1860 10. 1861 Appendix A û use cases 1863 In this appendix we present a set of use cases and scenarios based 1864 on which the extensions in this document were designed. It is 1865 assumed that the subscriber possesses a valid prepaid account with a 1866 service provider, for example a WLAN operator. 1868 In order to maintain generality, the use cases refer to the 1869 communications between the SAD and the network. The connection 1870 between the UserÆs Device and the SAD, which typically involves 1871 setting up a layer 2 session, e.g. a PPP session or a GPRS PDP 1872 Context, is specific to a given network technology and the details 1873 do not affect the operation of the prepaid service. 1875 10.1 1876 Simple prepaid use case 1878 A subscriber connects to his home network. As usual, the Access 1879 Device that is servicing the subscriber uses the AAA infrastructure 1880 to authenticate and authorize the subscriber. 1882 The SAD sends a RADIUS Access-Request to the AAA server in order to 1883 authenticate and authorise the subscriber with respect to the 1884 requested service. The Access-Request contains the subscriber 1885 credentials and may contain the prepaid capabilities of the SAD. 1886 Prepaid capabilities MUST be included if the SAD supports them. 1888 The AAA System proceeds with the authentication procedure. This may 1889 involve several message exchanges such as in EAP [RFC2284]. Once 1890 the subscriber has been authenticated, the AAA system determines 1891 that the subscriber is a prepaid subscriber and requests 1892 authorisation. The request MUST include the prepaid capabilities of 1893 the serving SAD. 1895 The system validates that the subscriber has a prepaid account and 1896 that the account is active. It further validates that the SAD has 1897 the appropriate prepaid capabilities. If all is in order, the 1898 prepaid system authorises the subscriber to use the network. 1899 Otherwise it rejects the request. The decision is sent to the AAA 1900 system. The response includes attributes to indicate the allocation 1901 of a portion of the subscriberÆs credit. This portion is called the 1902 ôinitial quotaö (in units of time or volume) and optionally a 1903 threshold value. 1905 A portion only of the userÆs funds is allocated because the user may 1906 be engaged in other services that may draw on the same account. For 1907 example, the user may be engaged in a data session and a voice 1908 session. Although these two services would draw from the same 1909 account, they form separate parts of the overall system. If the 1910 entire quota was allocated to the data session then the user would 1911 have no more funds for a voice session. 1913 The AAA system incorporates the attributes received from the prepaid 1914 System into an Access-Accept message that it sends to the SAD. Note 1915 that the AAA system is responsible for authorizing the service 1916 whereas the prepaid system is responsible for prepaid authorization. 1918 Upon receiving the Access-Response, the SAD starts the prepaid data 1919 session and meters the session based on time or volume, as indicated 1920 in the message. 1922 Once the usage for the session approaches the allocated limit (as 1923 expressed by the threshold), the SAD will request additional quota. 1924 Re-authorization for additional quota flows through the AAA system 1925 to the prepaid System. The prepaid System revalidates the 1926 subscriberÆs account and subtracts the previously allocated quota 1927 from the current balance. If there is remaining balance, it 1928 reauthorizes the request with an additional quota allotment. 1929 Otherwise, the prepaid System rejects the request. Note the 1930 replenishing of the quotas is a re-authorization procedure and does 1931 not require the subscriber to authenticate himself again. 1933 It is important to note that the prepaid System is maintaining 1934 session state for the subscriber. This state includes how much 1935 account balance was allocated during the last quota enquiry and how 1936 much is left in the account. Therefore, it is required that all 1937 messages about the session reach the same (and correct) prepaid 1938 system. 1940 Upon receiving a re-allotment of the quota, the SAD continues to 1941 provide the data service until the new threshold is reached. If the 1942 request for additional quota cannot be fulfilled then the SAD lets 1943 the subscriber use the remaining quota and terminates the session. 1945 Alternatively, instead of terminating the session, the SAD may 1946 restrict the data session such that the subscriber can only reach a 1947 particular web server. This web server maybe used to allow the 1948 subscriber to replenish their account. This restriction can also be 1949 used to allow new subscribers to set up prepaid accounts in the 1950 first place. 1952 Should the subscriber terminate the session before the quota is 1953 exhausted, the remaining balance allotted to the session MUST be 1954 refunded into the subscriberÆs account. 1956 While the Access Device is waiting for the initial quota, the 1957 subscriber may have dropped the connection/session. The entire 1958 allocated quota MUST be credited back to the subscribers account in 1959 this case. 1961 10.2 1962 Support for Multi-Services 1964 Examples of services that the user may be using are browsing the 1965 web, participating in a VoIP conversation, watching streaming video 1966 and downloading a file. Some operators may want to distinguish 1967 between these services. Some services are billed at different rates 1968 and services may be metered differently. Therefore, the prepaid 1969 solution needs to be able to distinguish services, and allocate 1970 quotas to the services using different units (e.g. time, volume) and 1971 allow for those quotas to be utilized at different rates. 1973 +---------+ 1974 | Session | 1975 +---------+ 1976 | 1977 V N 1978 +--------------+ +-------+ 1979 | Service |------>| Quota | 1980 | (service-Id) | +-------+ 1981 +--------------+ 1983 As shown in the above diagram, a Session may be associated with 1984 multiple (N) services. Each service is identified by a Service-ID. 1985 The format of the Service-ID is not in the scope of this document 1986 but the Service-ID could be expressed as an IP flow using the 5- 1987 tuple {Source-IP and Port, Destination-IP and Port, protocol type}. 1988 Each service is allocated an appropriate quota metric. 1990 10.3 1991 Resource Pools 1993 When working with multiple services a new problem arises because one 1994 service may utilize its quota faster than another service. When the 1995 userÆs balance is close to exhaustion, a situation could arise where 1996 one service is unable to obtain quota while another service has 1997 plenty of quota remaining. Unless the quotas can be rebalanced, the 1998 SAD would then have to terminate that service. Indeed, even before 1999 that happens, the services could generate an excessive amount of 2000 traffic as the they update their quotas. 2002 One method to solve these problems is to utilize resource pools. 2003 Resource pools enable the allocation of resources to several 2004 services of a session by allocating resources to a pool and have 2005 services draw their quota from the pool at a rate appropriate to 2006 that service. When the quota allocated to the pool is close to 2007 exhaustion, the entire pool is replenished. 2009 +-----------+ 2010 | Service-A |-----+ +--------+ 2011 +-----------+ | Ma | | 2012 +-------->| | 2013 | Pool | 2014 +-------->| (1) | 2015 +-----------+ | Mb | | 2016 | Service-B |-----+ +--------+ 2017 +-----------+ 2019 As the figure above shows, Service-A and Service-B are bound to 2020 Pool(1). Ma and Mb are the pool multipliers (that are associated 2021 with Service-A and Service-B respectively) that determine the rate 2022 at which Service-A and Service-B draw from the pool. 2024 The pool is initialized by taking the quota allocated to each 2025 service and multiplying it by Mn. Therefore, the amount of 2026 resources allocated to a pool is given by: 2028 Poolr = Ma*Qa + Mb*Qb + . . . 2030 A Pool is empty if: 2032 Poolr <= Ca*Ma + Cb*Mb + . . . 2034 where: 2035 Ca,Cb are the consumed resources of Service-A and Service-B 2036 respectively. 2038 Note that the resources assigned to the pool are not associated with 2039 a metric. That is, Service-A can be rated at $1 per Mbyte and 2040 Service-B can rated at $0.10 per Minute. In this case if we allocate 2041 $5 worth of resources on behalf of service-A to the pool we would 2042 set Ma = 10 and place 50 units into the pool. If we allocate $5 on 2043 behalf of Service-B to the Pool, then M=1 and place 50 units into 2044 the Pool. The pool would have a total sum of 100 units to be shared 2045 between the two services. Each Mbyte used by Service-A will draw 10 2046 units from the pool and each minute used by Service-B will draw 1 2047 unit from the pool. 2049 10.4 2050 Support for Complex Rating Functions 2052 The rating of a service can be quite complex. While some operators 2053 follow linear charging models, others may wish to apply more complex 2054 functions. For example, a service provider may wish to rate a 2055 service such that the first N Mbytes are free, then the next M 2056 Mbytes are rated at $1 per Mbyte and volume above M bytes be rated 2057 at $0.50 per Mbyte. Such a function could be implemented by repeated 2058 message exchanges with the prepaid system. 2060 To avert the need to exchange many messages while still supporting 2061 such complex rating functions the notion of a ôRating Groupö is 2062 introduced. A Rating Group is provisioned at the SAD. As 2063 illustrated in the figure below, a Rating Group is associated with 2064 one or more services and defines the rate that the services 2065 associated with the Rating Group consume the quota. 2067 +-----------+ 2068 | Service-A |------+ 2069 +-----------+ | +--------------+ +-------+ 2070 +---->| | | Quota | 2071 | Rating Group |------>| or | 2072 +-----------+ +---->| | | Pool | 2073 | Service-B |------+ +--------------+ +-------+ 2074 +-----------+ 2076 During consumption of a service that is associated with a Rating 2077 Group, the PPC sends the ID of the Rating Group to the PPS. The 2078 prepaid service authorizes the Rating Group by allocating a quota to 2079 it and optionally assigning it to a Resource Pool. 2081 When service that belongs to an authorized Rating Group is 2082 instantiated, the PPC does not need to authorize this service. This 2083 limits the amount of traffic between the PPC and the PPS. 2085 10.5 2086 One-Time-based Charging 2088 One-Time-based Charging is used for charging of service events 2089 without an ongoing session. That is, the service is provisioned 2090 instantaneously, as far as charging is concerned. An example of 2091 such an event is the purchase of a ring-tone. Subscription based 2092 services can also be modeled as a One-Time event. In this case the 2093 one-time service event is the purchase of a subscription 2095 For a given user, one-time-based charging may occur in parallel with 2096 other charging models. For example, the subscriber may access a 2097 website which is metered (based on time or volume) while he also 2098 purchase the right to use a ring tone (a one-time-based event). 2099 Note: it is up to the service providers to decide whether or not the 2100 user will be charged for the download of the tone and also be 2101 charged for the time and volume required to download the ring-tone. 2102 The facilities provided by this document gives the service provider 2103 the capability to achieve their service charging business goals. 2104 For example, should the service provider choose not to charge for 2105 the download volume or time, then they can treat the download IP 2106 flow as a separate service that is exempt from charging. 2108 The SAD signals one-time-based charging to the PPS with an 2109 indication that identifies the service and the units that need to be 2110 debited from the userÆs account. 2112 One-time-based charging may occur under two conditions: the (a) SAD 2113 may not have a authenticated context (or access to an authenticated 2114 context) for the subscriber), or (b) the SAD has access to 2115 authenticated context for the subscriber. In the former case the 2116 SAD will have to authenticate the subscriber. For example, the user 2117 maybe authenticated by the SAD providing access service. However 2118 when the user accesses the subscription server to purchase a 2119 subscription, the subscription server may not have access to the 2120 authentication context of the subscriber and thus will have to 2121 authenticate the subscriber from scratch. Authentication of the 2122 subscriber and the generation of the one-time charging event will 2123 happen in conjunction. 2125 Note that one-time-based charging can also be used to credit the 2126 prepaid userÆs account. For example, the SAD can return resources to 2127 the subscriber by issuing a one-time charge request that includes 2128 the amount of resources to be credited into the account. 2130 10.6 2131 Support for Tariff Switching 2133 The PPC and the PPS may support tariff switching as described 2134 earlier. For example, as shown in the figure below, traffic before 2135 18:00 may be rated at ær1Æ and traffic after 18:00 hours is rated at 2136 ær2Æ. The PPC reports usage before and after the switch occurs. 2137 Tariff switching only makes sense for volume based metering where 2138 the volume is billed at different rates. 2140 18:00 2141 ------------------+----------------- 2142 r1 | r2 2143 ------------------+----------------- 2144 ^ ^ 2145 |<----TSI---> | 2146 | | 2147 Access-Accept Access-Request 2149 The PPC it indicates support for tariff switching by setting the 2150 appropriate bit in the PPAC. If the PPS needs to signal a tariff 2151 switch time it will send a PTS attribute which indicates the point 2152 in time when the switch will occur. This indication represents the 2153 number of seconds from current time (TarrifSwitchInterval TSI). 2155 At some point after the tariff switch the PPC sends another Access- 2156 Request, as a result of either the user having logged off or the 2157 volume threshold being reached. The PPC reports how much volume was 2158 used using the PPAQ in total and how much volume was used after the 2159 tariff switch using the PTSÆs VUATS subtype. 2161 If the PPC sends this message before the tariff switch, the PPS will 2162 respond with another PTS where the TSI is appropriately updated. 2164 In situations with multiple tariff switches, as shown below, the PPS 2165 MUST specify the length of the tariff switch period using the 2166 TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute. 2168 18:00 23:30 2169 ------------------+---------------------+-------------- 2170 r1 | r2 | r3 2171 ------------------+---------------------+-------------- 2172 ^ ^ ^ 2173 |<----TSI---><-----------|-------->|TITSU 2174 | | 2175 Access-Accept Access-Request 2177 When a TITSU is specified in the PTS, the PPC MUST generate an 2178 Access-Request within the time after TSI and before TITSU expires. 2179 Note that, typically, the PPC will be triggered by the Volume 2180 Threshold. However, it is possible that, during period r2, 2181 insufficient traffic is generated and thus the threshold is not 2182 reached. Even in this case PPC MUST generate an Access-Request in 2183 good time. Also note that separate services flows may have 2184 individual tariff periods. 2186 10.7 2187 Support for Roaming 2189 In certain networks it is essential for prepaid data services to be 2190 available to roaming subscribers. Support for both static and 2191 dynamic roaming models is needed. In a static roaming scenario the 2192 subscriber connects to a foreign network which has a roaming 2193 agreement either directly with the home network, or through a broker 2194 network. When the subscriber logs into another foreign network, a 2195 new login procedure has to be executed. 2197 In a dynamic roaming scenario the subscriber may move between 2198 networks while maintaining his connection. In such a scenario the 2199 data session is seamlessly handed off between the networks. 2201 In both roaming scenarios, the subscriber always authenticates 2202 himself to the home network. Authorization for the prepaid session 2203 and quota replenishing occurs at the home network and more 2204 specifically at the prepaid system where state is being maintained. 2206 Dynamic roaming is challenging because a subscriber who established 2207 a prepaid data session may move to another Access Device that does 2208 not support the prepaid functionality. Even in this case the system 2209 should be able to continue the prepaid session. 2211 10.8 2212 Termination of a prepaid session 2214 When fraud or an error is detected, the either only the affected 2215 session, or all sessions of the affected subscriber should be 2216 terminated. 2218 It may happen that the prepaid system enters a state where it is 2219 unclear whether or not the data session is in progress. Under such a 2220 condition, the system may wish to terminate the session in order to 2221 make sure that the user is not billed for this potential inactivity. 2223 Certain handoff procedures used in dynamic roaming scenarios require 2224 that the system terminates the subscribers prepaid data session at a 2225 SAD. This is the case, for example, when time-based prepaid is used 2226 and the mobile subscriber performs a dormant handoff. 2228 10.9 2229 Querying and Rebalancing Prepaid Resources 2231 It should be possible for the PPS to Query the current resource 2232 consumption at a SAD and adjust the userÆs account balance. 2234 For example, a request to the PPS is made (e.g. a one-time charging 2235 event) but the userÆs account is depleted but resources have been 2236 allocated to the SAD. The PPS should have the ability to query the 2237 SAD and if it has the spare resources to reassign the quotas to the 2238 SAD and to the pending request. Note that the PPS doesnÆt know 2239 resource usage until the SAD request for more resources. This can 2240 be a long time. 2242 In the absence of this capability the PPS can minimize the effect of 2243 this phenomenon by allocating small quotas û a practice that 2244 results in more message exchanges.