idnits 2.17.00 (12 Aug 2021) /tmp/idnits35124/draft-guenther-radext-ppebc-00.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 905. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 912. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 918. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 934), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 851 has weird spacing: '...in RFCs to In...' -- 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 11, 2004) is 6516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' ** Downref: Normative reference to an Informational RFC: RFC 2866 == Outdated reference: A later version (-22) exists of draft-lior-radius-prepaid-extensions-03 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Radext C. Guenther 3 Internet-Draft H. Tschofenig 4 Expires: January 9, 2005 Siemens 5 July 11, 2004 7 Prepaid Extensions to Radius for Event-based Charging 8 draft-guenther-radext-ppebc-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 9, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 In event-based charging procedures, customers get charged for service 44 usage per se. This type of charging can be independent of data 45 volume transferred, time period of service availment, or user 46 subscription status. This memo introduces Radius attributes 47 appropriate for event-based charging with debiting of prepaid user 48 accounts. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Use Cases and Message Flows . . . . . . . . . . . . . . . . . 8 56 4.1 Price Enquiry . . . . . . . . . . . . . . . . . . . . . . 8 57 4.2 Direct Debiting . . . . . . . . . . . . . . . . . . . . . 9 58 4.3 Amount Reservation . . . . . . . . . . . . . . . . . . . . 10 59 4.4 Amount Capture . . . . . . . . . . . . . . . . . . . . . . 11 60 5. New Radius Attributes for Event-based Charging . . . . . . . . 13 61 5.1 Service-Name . . . . . . . . . . . . . . . . . . . . . . . 13 62 5.2 Requested-Action . . . . . . . . . . . . . . . . . . . . . 13 63 5.3 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 5.4 Currency-Code . . . . . . . . . . . . . . . . . . . . . . 15 65 5.5 Charging-Session-Id . . . . . . . . . . . . . . . . . . . 16 66 5.6 International Mobile Subscriber Identity (IMSI) . . . . . 17 67 6. Radius Messages for Event-based Charging . . . . . . . . . . . 19 68 6.1 Price Enquiry Request . . . . . . . . . . . . . . . . . . 19 69 6.2 Price Enquiry Response . . . . . . . . . . . . . . . . . . 20 70 6.3 Direct Debiting Request . . . . . . . . . . . . . . . . . 20 71 6.4 Direct Debiting Response . . . . . . . . . . . . . . . . . 21 72 6.5 Amount Reservation Request . . . . . . . . . . . . . . . . 21 73 6.6 Amount Reservation Response . . . . . . . . . . . . . . . 21 74 6.7 Amount Capture Request . . . . . . . . . . . . . . . . . . 22 75 6.8 Amount Capture Response . . . . . . . . . . . . . . . . . 22 76 6.9 Reject . . . . . . . . . . . . . . . . . . . . . . . . . . 22 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 81 9.2 Informative References . . . . . . . . . . . . . . . . . . . 26 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 83 Intellectual Property and Copyright Statements . . . . . . . . 28 85 1. Introduction 87 There are several models of how to charge customers for availing data 88 services: 90 Volume-based charging (VBC): (e.g., 2 Cent/KiloByte), 91 Duration-based charging (DBC): (e.g., 3 Cent/minute), 92 Subscription-based charging (SBC): (e.g., 5 Dollar/month+service), 93 Event-based charging (EBC): (e.g., 7 Cent/URL or email). 95 Charging models can be further divided into those with debiting of 96 prepaid user accounts and those with debiting of non-prepaid accounts 97 (such as current accounts at banks). 99 Volume- and time-based charging with debiting of prepaid accounts is 100 being treated in [I-D.draft-lior-radius-prepaid-extensions-03] by 101 defining appropriate attributes for the Remote Authentication Dial-In 102 User Service (Radius). In event-based charging procedures, customers 103 get charged for service usage per se. This type of charging can be 104 independent of data volume transferred, time period of service 105 availment, or user subscription status. This memo introduces Radius 106 attributes appropriate for event-based charging with debiting of 107 prepaid user accounts. 109 2. Terminology 111 This document uses the following terms and acronyms: 113 Radius Server: This is a server that offers the backend 114 infrastructure for authentication and authorization via the 115 protocol described in [RFC2865], and for accounting as described 116 in [RFC2866]. 117 Radius Client: This entity is responsible for passing user 118 information to designated Radius Servers and then for acting on 119 the responses received. 120 Event: The occasion that triggers the execution of a charging 121 procedure in relation to data service availment. Example: An http 122 request demanding access to a chargeable data service. 123 Volume-based Charging (VBC): A service usage charging procedure that 124 is based on the data volume transferred to the service user for 125 the purpose of service execution. Example: 2 Cent/KByte. 126 Duration-based Charging (DBC): A service usage charging procedure 127 that is based on the time period the user avails the service. 128 Example: 3 Cent/minute. 129 Subscription-based Charging (SBC): A service usage charging procedure 130 that is based on the fact that the user has previously subscribed 131 to the service in question. Example: 5 Dollar/month and service. 132 Event-based Charging (EBC): A service usage charging procedure that 133 is based on service availment per se. Example: 7 Cent/URL. 134 Event Handler (EH): The network entity that is responsible for 135 detecting chargeable events (e.g., an http request for a value 136 content) and for deciding which type of charging (e.g., VBC, DBC, 137 EBC, SBC, or combination of them) is to employed. From the Radius 138 point of view, this entity acts as Radius Client. 139 Rating Entity (RE): The network entity that accounts for calculating 140 cost information regarding a given data service. From a Radius 141 perspective, this entity acts as a Radius Server. 142 Charging Handler (CH): The network entitiy that is responsible for 143 executing charging-related tasks such as, for instance, price 144 enquiry and debiting. From the Radius point of view, this entity 145 can act both as Radius Server and Client. 146 Accounts Database (AD): The network entity that supplies the Charging 147 Handler with information regarding user accounts (e.g., account 148 balance information). Within the scope of this specification, the 149 AD is concerned with prepaid user accounts only. 150 Service Provider (SP): The network entity that offers a chargeable 151 data service. Access requests to chargeable data services of a SP 152 are detected and handled by the Event Handler. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 3. Framework 160 The Radius messages defined in this memo transfer information related 161 to event-based charging among network entities such as an Event 162 Handler (EH), a Rating Entity (RE), a Charging Handler (CH), and a 163 Service Provider (SP). The possible communication architectures for 164 these Radius messages can vary in terms of Radius message interaction 165 between the entities EH, RE, CH, and SP. Figure 1 depicts a basic 166 network structure in which the RE and CH are separated entities 167 acting as Radius Servers towards the EH which acts the role of a 168 Radius Client: 170 User 171 | 172 +-----+-----+ 173 | Terminal | 174 | Device | 175 | (TD) | 176 +-----+-----+ 177 | 178 | 179 +----------+ +-----+-----+ 180 | Event | | | 181 | Policy | | | 182 | Database +----+ Event | 183 | (EPD) | | Handler | 184 +----------+ | (EH) | 185 +----------+ | | +-----------+ +----------+ 186 | Rating | | | | Charging | | Accounts | 187 | Entity +----+ +----+ Handler +----+ Database | 188 | (RE) | | | | (CH) | | (AD) | 189 +----------+ +-----+-----+ +-----------+ +----------+ 190 | 191 +-----+-----+ 192 | Service | 193 | Provider | 194 | (SP) | 195 +-----------+ 197 Figure 1: Framework with EH-RE Connection 199 The basic steps of operation in this network topology and its 200 variations are the following: first, the user requests access to a 201 certain data service. A user, for example, enters an URL into his or 202 her web browser, selects an appropriate link, or clicks on a user 203 menue item. 205 The EH permanently scans the service access requests it is 206 responsible for (e.g., it scans all http requests) in order to sort 207 out requests for chargeable events. The EH falls back to an Event 208 Policy Database (EPD) which helps distinguishing between chargeable 209 and non-chargeable events and - in case of chargeable events - also 210 helps deciding which type of charging (e.g., VBC, DBC, SBC, EBC, or 211 combinations of them) is to be employed. A Rating Entity (RE) 212 supplies the EH with cost information related to given data services 213 (price enquiry). 215 This specification is dedicated to the case of event-based charging 216 with debiting to prepaid user accounts. In this case, the Charging 217 Handler (CH) accounts for the following tasks: 219 Debiting: To debit the user's prepaid account directly (i.e., without 220 amount reservation) prior to service delivery or afterwards, 221 Amount Reservation: To reserve a certain amount of money from the 222 user's prepaid account (not applicable in usage scenarios with 223 direct debiting, i.e., without amount reservation), and 224 Amount Capture: To capture a reserved amount of money after 225 successful service execution (not applicable in usage scenarios 226 with direct debiting). 228 Prior to service execution, the user will usually get informed about 229 the terms for service availment (especially, costs). If (s)he 230 accepts these conditions, the desired service is delivered to the 231 user. 233 In a variation of the first architectural model as shown in Figure 1, 234 the RE has no direct Radius connection to the EH but builds up a 235 Radius Server/Client pair along with the CH. Towards the EH, the CH 236 acts as Radius Server: 238 User 239 | 240 +-----+-----+ 241 | Terminal | 242 | Device | 243 | (TD) | 244 +-----+-----+ 245 | 246 | 247 +----------+ +-----+-----+ +-----------+ 248 | Event | | | | Rating | 249 | Policy | | | | Entity | 250 | Database +----+ Event | | (RE) | 251 | (EPD) | | Handler | +-----+-----+ 252 +----------+ | (EH) | | 253 | | +-----+-----+ +----------+ 254 | | | Charging | | Accounts | 255 | +----+ Handler +----+ Database | 256 | | | (CH) | | (AD) | 257 +-----+-----+ +-----------+ +----------+ 258 | 259 +-----+-----+ 260 | Service | 261 | Provider | 262 | (SP) | 263 +-----------+ 265 Figure 2: Framework with CH-RE Connection 267 The basic steps of operation in this model are mostly the same as for 268 the first model - but this time, the EH does not only leave charging 269 of user accounts but also rating of events to other network entities. 271 4. Use Cases and Message Flows 273 This section describes some use cases in which the Radius attributes 274 and messages specified in this memo are helpful: price enquiry, 275 direct debiting, amount reservation, and amount capture. 277 4.1 Price Enquiry 279 The RE is responsible for calculating price information related to a 280 given data service. Depending on which Radius connections the RE has 281 to the other network entities, the EH (see Figure 1), the CH (see 282 Figure 2), or the SP can request this type of information by means of 283 an Price Enquiry Request message. If no failure of any kind occurs, 284 the RE sends a Price Enquiry Response back to the Charging Handler: 286 +---------------+ +---------------+ 287 | EH/CH/SP | | Rating Entity | 288 +---------------+ +---------------+ 289 | | 290 | Price Enquiry Request | 291 |---------------------------------------------->| 292 | | 293 | | 294 | Price Enquiry Response | 295 |<----------------------------------------------| 296 | | 298 Figure 3: Price Enquiry Message Flow: Successful Case 300 In case of an error (e.g., the RE is not able to calculate the 301 desired information, or the data provided by the EH are not 302 sufficient to process the Price Enquiry Request appropriately), the 303 RE will respond with a Reject message: 305 +---------------+ +---------------+ 306 | EH/CH/SP | | Rating Entity | 307 +---------------+ +---------------+ 308 | | 309 | Price Enquiry Request | 310 |---------------------------------------------->| 311 | | 312 | | 313 | Reject | 314 |<----------------------------------------------| 315 | | 317 Figure 4: Price Enquiry Message Flow: Failure Case 319 4.2 Direct Debiting 321 Debiting of prepaid accounts can be preceded by reserving a 322 sufficient amount from the prepaid account or can go without such an 323 amount reservation. The latter case is referred to as 'direct 324 debiting' which can occur prior to service execution or afterwards. 326 This specification defines Radius messages suitable for direct 327 debiting initiation (request) and confirmation (response). These are 328 exchanged between an Event Handler (EH) and a Charging Handler (CH) 329 as follows: 331 +---------------+ +------------------+ 332 | Event Handler | | Charging Handler | 333 +---------------+ +------------------+ 334 | | 335 | Direct Debiting Request | 336 |---------------------------------------------->| 337 | | 338 | | 339 | Direct Debiting Response | 340 |<----------------------------------------------| 341 | | 343 Figure 5: Direct Debiting Message Flow: Successful Case 345 Of course, the CH will first check whether the prepaid user account 346 has sufficient cover. If this is not the case, the CH will 347 substitute its response message by an error message: 349 +---------------+ +------------------+ 350 | Event Handler | | Charging Handler | 351 +---------------+ +------------------+ 352 | | 353 | Direct Debiting Request | 354 |---------------------------------------------->| 355 | | 356 | | 357 | Reject | 358 |<----------------------------------------------| 359 | | 361 Figure 6: Direct Debiting Message Flow: Failure Case 363 4.3 Amount Reservation 365 Besides messages for direct debiting, this specification also defines 366 Radius messages for use cases with reservation of amounts of money 367 (or of non-monetary units; to be detailed in future versions of this 368 document) from user accounts. Reserved amounts are then captured at 369 a later point of time. Amount reservation is initiated by an Amount 370 Reservation Request and confirmed in case of success by an Amount 371 Reservation Response as follows: 373 +---------------+ +------------------+ 374 | Event Handler | | Charging Handler | 375 +---------------+ +------------------+ 376 | | 377 | Amount Reservation Request | 378 |---------------------------------------------->| 379 | | 380 | | 381 | Amount Reservation Response | 382 |<----------------------------------------------| 383 | | 385 Figure 7: Amount Reservation Message Flow: Successful Case 387 Amount reservation cannot take place at the CH's site if there is not 388 enough cover of the prepaid user account. This circumstance is 389 indicated to the EH by means of a Reject message: 391 +---------------+ +------------------+ 392 | Event Handler | | Charging Handler | 393 +---------------+ +------------------+ 394 | | 395 | Amount Reservation Request | 396 |---------------------------------------------->| 397 | | 398 | | 399 | Reject | 400 |<----------------------------------------------| 401 | | 403 Figure 8: Amount Reservation Message Flow: Failure Case 405 4.4 Amount Capture 407 After having reserved a certain amount of a prepaid account, this 408 amount can be captured. Capturing reserved amounts is initiated by 409 an Amount Capture Request and - in case of success - confirmed by an 410 Amount Capture Response: 412 +---------------+ +------------------+ 413 | Event Handler | | Charging Handler | 414 +---------------+ +------------------+ 415 | | 416 | Amount Capture Request | 417 |---------------------------------------------->| 418 | | 419 | | 420 | Amount Capture Response | 421 |<----------------------------------------------| 422 | | 424 Figure 9: Amount Capture Message Flow: Successful Case 426 It might happen that the CH has to refuse the final amount capture 427 for some reason, although the CH had sent a positive Amount 428 Reservation Response to the EH before. In this case, the CH notifies 429 this fact by means of a Reject message. 431 +---------------+ +------------------+ 432 | Event Handler | | Charging Handler | 433 +---------------+ +------------------+ 434 | | 435 | Amount Capture Request | 436 |---------------------------------------------->| 437 | | 438 | | 439 | Reject | 440 |<----------------------------------------------| 441 | | 443 Figure 10: Amount Capture Message Flow: Failure Case 445 5. New Radius Attributes for Event-based Charging 447 This section defines a set of new Radius attributes that - along with 448 attributes standardized at the IETF previously - constitute the 449 Radius messages specified in Section 6. 451 5.1 Service-Name 453 The Service-Name attribute specifies the service to which the user 454 requests access. 456 0 1 2 3 457 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 0 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Type | Length | Service-Name ... 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Type 464 To be assigned by IANA, or to become a sub-type of a new IANA 465 assigned attribute type for event-based charging or charging in 466 general. 468 Length 470 >= 3 Byte 472 Service-Name 474 The value field of the Service-Name attribute is of type "string". 475 It identifies the service to which the user has requested access. 476 Service names MUST be assigned in a way independent of a specific 477 administration domain (to be detailed in future versions of this 478 document). 480 5.2 Requested-Action 482 The Requested-Action attribute specifies what operation the entity 483 receiving this attribute is requested to perform: price enquiry, 484 amount reservation, amount capture, or price enquiry. 486 0 1 2 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type | Length | Requested-A. | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Type 494 To be assigned by IANA, or to become a sub-type of a new IANA 495 assigned attribute type for event-based charging or charging in 496 general. 498 Length 500 3 Byte 502 Requested-Action 504 The value field of the Requested-Action attribute is of type 505 "integer". The following integer values are supported: 507 1 price-enquiry 508 2 direct-debiting 509 3 reservation 510 4 capture 512 All other values are reserved. 514 5.3 Cost 516 The Cost attribute indicates price information. It contains the 517 number (e.g., 70) of minor currency units (e.g., Cent) to be reserved 518 or debited from the user's prepaid account. In cases where no minor 519 currency unit is available the major currency unit must be taken. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Type | Length | Cost ... 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Type 529 To be assigned by IANA, or to become a sub-type of a new IANA 530 assigned attribute type for event-based charging or charging in 531 general. 533 Length 535 3 - 6 Byte 537 Cost 539 The value field of the Cost attribute is of type "integer" and 540 indicates the number of minor (if possible; otherwise, major) 541 currency units to be reserved or debited from the user's prepaid 542 account. 544 5.4 Currency-Code 546 This attribute indicates the currency to be applied to the value of 547 the Cost attribute. 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Type | Length | Currency-Code ... 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 Type 557 To be assigned by IANA, or to become a sub-type of a new IANA 558 assigned attribute type for event-based charging or charging in 559 general. 561 Length 563 3 - 6 Byte 565 Currency-Code 567 The value field of the Currency-Code attribute is of type "string" 568 and indicates the currency to be applied to the Cost value as 569 indicated by the Cost attribute. The string value for a single 570 currency is defined in [ISO4217]. 572 5.5 Charging-Session-Id 574 This attribute is a unique identifier the EH assigns to an event. It 575 is to facilitate the matching between different but correlated 576 messages such as Amount Reservation Requests and Amount Capture 577 Requests. In case of an Price Enquiry Request message, it is 578 possible that the Charging-Session-Id identifier is not generated by 579 the EH, but by the CH or the SP, depending on which of these entities 580 sends the Price Enquiry Request. 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type | Length | Charging-Session-Id ... 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Type 590 To be assigned by IANA, or to become a sub-type of a new IANA 591 assigned attribute type for event-based charging or charging in 592 general. 594 Length 596 >= 3 Byte 598 Charging-Session-Id 600 The value field of the Charging-Session-Id attribute is of type 601 "string". 603 5.6 International Mobile Subscriber Identity (IMSI) 605 If appropriate, this attribute can be used to identify a mobile 606 subscriber. Thus, it fits in the series of standard Radius 607 attributes such as Calling-Station-Id and Framed-IP-Address that are 608 suitable in the scope of this document for request originator 609 identification (especially at the Charging Handler's site which has 610 to map debiting and reservation requests to the right user accounts). 611 The definition of this attribute is borrowed from 3GPP where this 612 attribute is called 3GPP-IMSI (see [3GPP.29.061]). 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Type | Length | IMSI ... 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Type 622 To be assigned by IANA, or to become a sub-type of a new IANA 623 assigned attribute type for event-based charging or charging in 624 general. 626 Length 628 <= 17 Byte 630 IMSI 632 The value field of the IMSI attribute is of type "text". It 633 contains an UTF-8 encoded IMSI. An IMSI consists of not more than 634 15 digits each of which requires one Byte in the value field of 635 this attribute. The structure and content of IMSIs are defined in 636 [3GPP.23.003]. 638 6. Radius Messages for Event-based Charging 640 This section explicitly introduces Radius messages for event-based 641 charging and specifies which Radius attributes are mandatory or 642 optional. See Section 4 for an informal description of these 643 messages. 645 Regarding the number of occurences of attributes in the Radius 646 messages defined below, we use the following abbreviations: 648 0+ Zero or more instances of this attribute MAY be present. 649 0-1 Zero or one instance of this attribute MAY be present. 650 1 Exactly one instance of this attribute MUST be present. 652 6.1 Price Enquiry Request 654 Packet Type: 655 Access-Request (Code = 1) 657 Attributes: 658 Framed-IP-Address: 0-1 (see [RFC2865]) 659 Calling-Station-Id: 0-1 (see [RFC2865]) 660 IMSI: 0-1 661 Requested-Action: 1 (value MUST be set to 1 = price-enquiry) 662 Service-Name: 1 663 Charging-Session-Id: 1 665 Note 1: 666 None of the first three attributes must occur within this message. 667 However, rating an event might be dependent on user identity in 668 some scenarios (there might be, for instance, different user 669 categories each of which has its own rules for rating). 671 Note 2: 672 According to [RFC2865], Radius Access-Requests MUST contain either 673 a User-Password or a CHAP-Password or State attribute. An Access- 674 Request MUST NOT contain both a User-Password and a CHAP-Password. 675 Furthermore, an Access-Request MUST contain either a NAS-IP-Address 676 or a NAS-Identifier (or both). Which of these attributes are trans- 677 ferred in a Price Enquiry Request message in addition to the ones 678 listed above depends on the usage scenario. 680 6.2 Price Enquiry Response 682 Packet Type: 683 Access-Accept (Code = 2) 685 Attributes: 686 Charging-Session-Id: 1 687 Cost: 1 688 Currency-Code: 0-1 (currency might be clear from context) 690 Note: 691 The RE MUST use the same Charging-Session-Id value as presented 692 in the corresponding Price Enquiry Request message. 694 6.3 Direct Debiting Request 696 Packet Type: 697 Access-Request (Code = 1) 699 Attributes: 700 Framed-IP-Address: 0-1 (see [RFC2865]) 701 Calling-Station-Id: 0-1 (see [RFC2865]) 702 IMSI: 0-1 703 Requested-Action: 1 (value MUST be set to 2 = direct-debiting) 704 Service-Name: 1 705 Charging-Session-Id: 1 706 Cost: 1 707 Currency-Code: 0-1 (currency might be clear from context) 709 Note 1: 710 At least one of the first three attributes MUST occur within 711 this message in order to enable the CH to map this request 712 to the right user account. 714 Note 2: 715 According to [RFC2865], Radius Access-Requests MUST contain either 716 a User-Password or a CHAP-Password or State attribute. An Access- 717 Request MUST NOT contain both a User-Password and a CHAP-Password. 718 Furthermore, an Access-Request MUST contain either a NAS-IP-Address 719 or a NAS-Identifier (or both). Which of these attributes are trans- 720 ferred in a Direct Debiting Request message in addition to the ones 721 listed above depends on the usage scenario. 723 6.4 Direct Debiting Response 725 Packet Type: 726 Access-Accept (Code = 2) 728 Attributes: 729 Charging-Session-Id: 1 731 The CH MUST use the same Charging-Session-Id value as presented in 732 the corresponding Direct Debiting Request message. 734 6.5 Amount Reservation Request 736 Packet Type: 737 Access-Request (Code = 1) 739 Attributes: 740 Framed-IP-Address: 0-1 (see [RFC2865]) 741 Calling-Station-Id: 0-1 (see [RFC2865]) 742 IMSI: 0-1 743 Requested-Action: 1 (value MUST be set to 3 = reservation) 744 Service-Name: 1 745 Charging-Session-Id: 1 746 Cost: 1 747 Currency-Code: 0-1 (currency might be clear from context) 749 At least one of the first three attributes MUST occur within this 750 message in order to enable the CH to map this request to the right 751 user account. 753 According to [RFC2865], Radius Access-Requests MUST contain either a 754 User-Password or a CHAP-Password or State attribute. An Access- 755 Request MUST NOT contain both a User-Password and a CHAP-Password. 756 Furthermore, an Access-Request MUST contain either a NAS-IP-Address 757 or a NAS-Identifier (or both). Which of these attributes are trans- 758 ferred in an Amount Reservation Request message in addition to the 759 ones listed above depends on the usage scenario. 761 6.6 Amount Reservation Response 763 Packet Type: 764 Access-Accept (Code = 2) 766 Attributes: 767 Charging-Session-Id: 1 769 The CH MUST use the same Charging-Session-Id value as presented in 770 the corresponding Amount Reservation Request message. 772 6.7 Amount Capture Request 774 Packet Type: 775 Access-Request (Code = 1) 777 Attributes: 778 Framed-IP-Address: 0-1 (see [RFC2865]) 779 Calling-Station-Id: 0-1 (see [RFC2865]) 780 IMSI: 0-1 781 Requested-Action: 1 (value MUST be set to 4 = capture) 782 Service-Name: 1 783 Charging-Session-Id: 1 785 According to [RFC2865], Radius Access-Requests MUST contain either a 786 User-Password or a CHAP-Password or State attribute. An Access- 787 Request MUST NOT contain both a User-Password and a CHAP-Password. 788 Furthermore, an Access-Request MUST contain either a NAS-IP-Address 789 or a NAS-Identifier (or both). Which of these attributes are trans- 790 ferred in an Amount Capture Request message in addition to the ones 791 listed above depends on the usage scenario. 793 6.8 Amount Capture Response 795 Packet Type: 796 Access-Accept (Code = 2) 798 Attributes: 799 Charging-Session-Id: 1 801 The CH MUST use the same Charging-Session-Id value as presented in 802 the corresponding Amount Capture Request message. 804 6.9 Reject 806 Packet Type: 807 Access-Reject (Code = 3) 809 Attributes: 810 Charging-Session-Id: 1 811 Reply-Message: 0+ (see [RFC2865]) 813 Reply-Message attributes are used here to transport textual 814 indications to the receiver of this message why the corresponding 815 request could not be processed successfully. Within the scope of 816 this document, the following character strings are apparently helpful 817 for describing reasons of request refusal: 818 requested-action-not-supported 819 missing-parameter (e.g., name of service is missing from request) 820 invalid-parameter (e.g., service name "www.supercom.com/ 821 superservice" is invalid) 822 unknown-subscriber 823 limits-violated (e.g., due to insufficient account cover) 824 unspecified (no explicit reason provided) 826 [RFC2865] recommends to UTF-8 encode the characters of these strings. 828 7. IANA Considerations 830 This document requires the assignment of new Radius attributes number 831 for the following atttributes: 833 Service-Name 834 Requested-Action 835 Cost 836 Currency-Code 837 Charging-Session-Id 838 IMSI 840 8. Security Considerations 842 TBD 844 9. References 846 9.1 Normative References 848 [ISO4217] ISO, "Codes for the representation of currencies and 849 funds", August 2001. 851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", March 1997. 854 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 855 "Remote Authentication Dial In User Service (RADIUS)", RFC 856 2865, June 2000. 858 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000, 859 . 861 9.2 Informative References 863 [3GPP.23.003] 864 3GPP, "Numbering, addressing and identification; Release 865 6", 3GPP TS 23.003, June 2004. 867 [3GPP.29.061] 868 3GPP, "Interworking between the Public Land Mobile Network 869 (PLMN) supporting packet based services and Packet Data 870 Networks (PDN); Release 6", 3GPP TS 29.061, June 2004. 872 [I-D.draft-lior-radius-prepaid-extensions-03] 873 Lior, A., Yegani, P., Chowdhury, K., Madour, L. and Y. Li, 874 "PrePaid Extensions to Remote Authentication Dial-In User 875 Service (RADIUS)", draft-lior-radius-prepaid-extensions-03 876 (work in progress), February 2004, 877 . 879 Authors' Addresses 881 Christian Guenther 882 Siemens 883 Otto-Hahn-Ring 6 884 Munich, Bayern 81739 885 Germany 887 EMail: christian.guenther@siemens.com 888 Hannes Tschofenig 889 Siemens 890 Otto-Hahn-Ring 6 891 Munich, Bayern 81739 892 Germany 894 EMail: hannes.tschofenig@siemens.com 896 Intellectual Property Statement 898 The IETF takes no position regarding the validity or scope of any 899 Intellectual Property Rights or other rights that might be claimed to 900 pertain to the implementation or use of the technology described in 901 this document or the extent to which any license under such rights 902 might or might not be available; nor does it represent that it has 903 made any independent effort to identify any such rights. Information 904 on the procedures with respect to rights in RFC documents can be 905 found in BCP 78 and BCP 79. 907 Copies of IPR disclosures made to the IETF Secretariat and any 908 assurances of licenses to be made available, or the result of an 909 attempt made to obtain a general license or permission for the use of 910 such proprietary rights by implementers or users of this 911 specification can be obtained from the IETF on-line IPR repository at 912 http://www.ietf.org/ipr. 914 The IETF invites any interested party to bring to its attention any 915 copyrights, patents or patent applications, or other proprietary 916 rights that may cover technology that may be required to implement 917 this standard. Please address the information to the IETF at 918 ietf-ipr@ietf.org. 920 Disclaimer of Validity 922 This document and the information contained herein are provided on an 923 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 924 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 925 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 926 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 927 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 928 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 930 Copyright Statement 932 Copyright (C) The Internet Society (2004). This document is subject 933 to the rights, licenses and restrictions contained in BCP 78, and 934 except as set forth therein, the authors retain all their rights. 936 Acknowledgment 938 Funding for the RFC Editor function is currently provided by the 939 Internet Society.