Radext C. Guenther Internet-Draft H. Tschofenig Expires: January 9, 2005 Siemens July 11, 2004 Prepaid Extensions to Radius for Event-based Charging draft-guenther-radext-ppebc-00.txt Status of this Memo 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 9, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract In event-based charging procedures, customers get charged for service usage per se. This type of charging can be independent of data volume transferred, time period of service availment, or user subscription status. This memo introduces Radius attributes appropriate for event-based charging with debiting of prepaid user accounts. Guenther & Tschofenig Expires January 9, 2005 [Page 1] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Use Cases and Message Flows . . . . . . . . . . . . . . . . . 8 4.1 Price Enquiry . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Direct Debiting . . . . . . . . . . . . . . . . . . . . . 9 4.3 Amount Reservation . . . . . . . . . . . . . . . . . . . . 10 4.4 Amount Capture . . . . . . . . . . . . . . . . . . . . . . 11 5. New Radius Attributes for Event-based Charging . . . . . . . . 13 5.1 Service-Name . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 Requested-Action . . . . . . . . . . . . . . . . . . . . . 13 5.3 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4 Currency-Code . . . . . . . . . . . . . . . . . . . . . . 15 5.5 Charging-Session-Id . . . . . . . . . . . . . . . . . . . 16 5.6 International Mobile Subscriber Identity (IMSI) . . . . . 17 6. Radius Messages for Event-based Charging . . . . . . . . . . . 19 6.1 Price Enquiry Request . . . . . . . . . . . . . . . . . . 19 6.2 Price Enquiry Response . . . . . . . . . . . . . . . . . . 20 6.3 Direct Debiting Request . . . . . . . . . . . . . . . . . 20 6.4 Direct Debiting Response . . . . . . . . . . . . . . . . . 21 6.5 Amount Reservation Request . . . . . . . . . . . . . . . . 21 6.6 Amount Reservation Response . . . . . . . . . . . . . . . 21 6.7 Amount Capture Request . . . . . . . . . . . . . . . . . . 22 6.8 Amount Capture Response . . . . . . . . . . . . . . . . . 22 6.9 Reject . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 9.2 Informative References . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . 28 Guenther & Tschofenig Expires January 9, 2005 [Page 2] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 1. Introduction There are several models of how to charge customers for availing data services: Volume-based charging (VBC): (e.g., 2 Cent/KiloByte), Duration-based charging (DBC): (e.g., 3 Cent/minute), Subscription-based charging (SBC): (e.g., 5 Dollar/month+service), Event-based charging (EBC): (e.g., 7 Cent/URL or email). Charging models can be further divided into those with debiting of prepaid user accounts and those with debiting of non-prepaid accounts (such as current accounts at banks). Volume- and time-based charging with debiting of prepaid accounts is being treated in [I-D.draft-lior-radius-prepaid-extensions-03] by defining appropriate attributes for the Remote Authentication Dial-In User Service (Radius). In event-based charging procedures, customers get charged for service usage per se. This type of charging can be independent of data volume transferred, time period of service availment, or user subscription status. This memo introduces Radius attributes appropriate for event-based charging with debiting of prepaid user accounts. Guenther & Tschofenig Expires January 9, 2005 [Page 3] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 2. Terminology This document uses the following terms and acronyms: Radius Server: This is a server that offers the backend infrastructure for authentication and authorization via the protocol described in [RFC2865], and for accounting as described in [RFC2866]. Radius Client: This entity is responsible for passing user information to designated Radius Servers and then for acting on the responses received. Event: The occasion that triggers the execution of a charging procedure in relation to data service availment. Example: An http request demanding access to a chargeable data service. Volume-based Charging (VBC): A service usage charging procedure that is based on the data volume transferred to the service user for the purpose of service execution. Example: 2 Cent/KByte. Duration-based Charging (DBC): A service usage charging procedure that is based on the time period the user avails the service. Example: 3 Cent/minute. Subscription-based Charging (SBC): A service usage charging procedure that is based on the fact that the user has previously subscribed to the service in question. Example: 5 Dollar/month and service. Event-based Charging (EBC): A service usage charging procedure that is based on service availment per se. Example: 7 Cent/URL. Event Handler (EH): The network entity that is responsible for detecting chargeable events (e.g., an http request for a value content) and for deciding which type of charging (e.g., VBC, DBC, EBC, SBC, or combination of them) is to employed. From the Radius point of view, this entity acts as Radius Client. Rating Entity (RE): The network entity that accounts for calculating cost information regarding a given data service. From a Radius perspective, this entity acts as a Radius Server. Charging Handler (CH): The network entitiy that is responsible for executing charging-related tasks such as, for instance, price enquiry and debiting. From the Radius point of view, this entity can act both as Radius Server and Client. Accounts Database (AD): The network entity that supplies the Charging Handler with information regarding user accounts (e.g., account balance information). Within the scope of this specification, the AD is concerned with prepaid user accounts only. Service Provider (SP): The network entity that offers a chargeable data service. Access requests to chargeable data services of a SP are detected and handled by the Event Handler. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Guenther & Tschofenig Expires January 9, 2005 [Page 4] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 3. Framework The Radius messages defined in this memo transfer information related to event-based charging among network entities such as an Event Handler (EH), a Rating Entity (RE), a Charging Handler (CH), and a Service Provider (SP). The possible communication architectures for these Radius messages can vary in terms of Radius message interaction between the entities EH, RE, CH, and SP. Figure 1 depicts a basic network structure in which the RE and CH are separated entities acting as Radius Servers towards the EH which acts the role of a Radius Client: User | +-----+-----+ | Terminal | | Device | | (TD) | +-----+-----+ | | +----------+ +-----+-----+ | Event | | | | Policy | | | | Database +----+ Event | | (EPD) | | Handler | +----------+ | (EH) | +----------+ | | +-----------+ +----------+ | Rating | | | | Charging | | Accounts | | Entity +----+ +----+ Handler +----+ Database | | (RE) | | | | (CH) | | (AD) | +----------+ +-----+-----+ +-----------+ +----------+ | +-----+-----+ | Service | | Provider | | (SP) | +-----------+ Figure 1: Framework with EH-RE Connection The basic steps of operation in this network topology and its variations are the following: first, the user requests access to a certain data service. A user, for example, enters an URL into his or her web browser, selects an appropriate link, or clicks on a user menue item. The EH permanently scans the service access requests it is Guenther & Tschofenig Expires January 9, 2005 [Page 5] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 responsible for (e.g., it scans all http requests) in order to sort out requests for chargeable events. The EH falls back to an Event Policy Database (EPD) which helps distinguishing between chargeable and non-chargeable events and - in case of chargeable events - also helps deciding which type of charging (e.g., VBC, DBC, SBC, EBC, or combinations of them) is to be employed. A Rating Entity (RE) supplies the EH with cost information related to given data services (price enquiry). This specification is dedicated to the case of event-based charging with debiting to prepaid user accounts. In this case, the Charging Handler (CH) accounts for the following tasks: Debiting: To debit the user's prepaid account directly (i.e., without amount reservation) prior to service delivery or afterwards, Amount Reservation: To reserve a certain amount of money from the user's prepaid account (not applicable in usage scenarios with direct debiting, i.e., without amount reservation), and Amount Capture: To capture a reserved amount of money after successful service execution (not applicable in usage scenarios with direct debiting). Prior to service execution, the user will usually get informed about the terms for service availment (especially, costs). If (s)he accepts these conditions, the desired service is delivered to the user. In a variation of the first architectural model as shown in Figure 1, the RE has no direct Radius connection to the EH but builds up a Radius Server/Client pair along with the CH. Towards the EH, the CH acts as Radius Server: Guenther & Tschofenig Expires January 9, 2005 [Page 6] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 User | +-----+-----+ | Terminal | | Device | | (TD) | +-----+-----+ | | +----------+ +-----+-----+ +-----------+ | Event | | | | Rating | | Policy | | | | Entity | | Database +----+ Event | | (RE) | | (EPD) | | Handler | +-----+-----+ +----------+ | (EH) | | | | +-----+-----+ +----------+ | | | Charging | | Accounts | | +----+ Handler +----+ Database | | | | (CH) | | (AD) | +-----+-----+ +-----------+ +----------+ | +-----+-----+ | Service | | Provider | | (SP) | +-----------+ Figure 2: Framework with CH-RE Connection The basic steps of operation in this model are mostly the same as for the first model - but this time, the EH does not only leave charging of user accounts but also rating of events to other network entities. Guenther & Tschofenig Expires January 9, 2005 [Page 7] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 4. Use Cases and Message Flows This section describes some use cases in which the Radius attributes and messages specified in this memo are helpful: price enquiry, direct debiting, amount reservation, and amount capture. 4.1 Price Enquiry The RE is responsible for calculating price information related to a given data service. Depending on which Radius connections the RE has to the other network entities, the EH (see Figure 1), the CH (see Figure 2), or the SP can request this type of information by means of an Price Enquiry Request message. If no failure of any kind occurs, the RE sends a Price Enquiry Response back to the Charging Handler: +---------------+ +---------------+ | EH/CH/SP | | Rating Entity | +---------------+ +---------------+ | | | Price Enquiry Request | |---------------------------------------------->| | | | | | Price Enquiry Response | |<----------------------------------------------| | | Figure 3: Price Enquiry Message Flow: Successful Case In case of an error (e.g., the RE is not able to calculate the desired information, or the data provided by the EH are not sufficient to process the Price Enquiry Request appropriately), the RE will respond with a Reject message: Guenther & Tschofenig Expires January 9, 2005 [Page 8] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 +---------------+ +---------------+ | EH/CH/SP | | Rating Entity | +---------------+ +---------------+ | | | Price Enquiry Request | |---------------------------------------------->| | | | | | Reject | |<----------------------------------------------| | | Figure 4: Price Enquiry Message Flow: Failure Case 4.2 Direct Debiting Debiting of prepaid accounts can be preceded by reserving a sufficient amount from the prepaid account or can go without such an amount reservation. The latter case is referred to as 'direct debiting' which can occur prior to service execution or afterwards. This specification defines Radius messages suitable for direct debiting initiation (request) and confirmation (response). These are exchanged between an Event Handler (EH) and a Charging Handler (CH) as follows: +---------------+ +------------------+ | Event Handler | | Charging Handler | +---------------+ +------------------+ | | | Direct Debiting Request | |---------------------------------------------->| | | | | | Direct Debiting Response | |<----------------------------------------------| | | Figure 5: Direct Debiting Message Flow: Successful Case Of course, the CH will first check whether the prepaid user account has sufficient cover. If this is not the case, the CH will substitute its response message by an error message: Guenther & Tschofenig Expires January 9, 2005 [Page 9] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 +---------------+ +------------------+ | Event Handler | | Charging Handler | +---------------+ +------------------+ | | | Direct Debiting Request | |---------------------------------------------->| | | | | | Reject | |<----------------------------------------------| | | Figure 6: Direct Debiting Message Flow: Failure Case 4.3 Amount Reservation Besides messages for direct debiting, this specification also defines Radius messages for use cases with reservation of amounts of money (or of non-monetary units; to be detailed in future versions of this document) from user accounts. Reserved amounts are then captured at a later point of time. Amount reservation is initiated by an Amount Reservation Request and confirmed in case of success by an Amount Reservation Response as follows: +---------------+ +------------------+ | Event Handler | | Charging Handler | +---------------+ +------------------+ | | | Amount Reservation Request | |---------------------------------------------->| | | | | | Amount Reservation Response | |<----------------------------------------------| | | Figure 7: Amount Reservation Message Flow: Successful Case Amount reservation cannot take place at the CH's site if there is not enough cover of the prepaid user account. This circumstance is indicated to the EH by means of a Reject message: Guenther & Tschofenig Expires January 9, 2005 [Page 10] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 +---------------+ +------------------+ | Event Handler | | Charging Handler | +---------------+ +------------------+ | | | Amount Reservation Request | |---------------------------------------------->| | | | | | Reject | |<----------------------------------------------| | | Figure 8: Amount Reservation Message Flow: Failure Case 4.4 Amount Capture After having reserved a certain amount of a prepaid account, this amount can be captured. Capturing reserved amounts is initiated by an Amount Capture Request and - in case of success - confirmed by an Amount Capture Response: +---------------+ +------------------+ | Event Handler | | Charging Handler | +---------------+ +------------------+ | | | Amount Capture Request | |---------------------------------------------->| | | | | | Amount Capture Response | |<----------------------------------------------| | | Figure 9: Amount Capture Message Flow: Successful Case It might happen that the CH has to refuse the final amount capture for some reason, although the CH had sent a positive Amount Reservation Response to the EH before. In this case, the CH notifies this fact by means of a Reject message. Guenther & Tschofenig Expires January 9, 2005 [Page 11] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 +---------------+ +------------------+ | Event Handler | | Charging Handler | +---------------+ +------------------+ | | | Amount Capture Request | |---------------------------------------------->| | | | | | Reject | |<----------------------------------------------| | | Figure 10: Amount Capture Message Flow: Failure Case Guenther & Tschofenig Expires January 9, 2005 [Page 12] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 5. New Radius Attributes for Event-based Charging This section defines a set of new Radius attributes that - along with attributes standardized at the IETF previously - constitute the Radius messages specified in Section 6. 5.1 Service-Name The Service-Name attribute specifies the service to which the user requests access. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Service-Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA, or to become a sub-type of a new IANA assigned attribute type for event-based charging or charging in general. Length >= 3 Byte Service-Name The value field of the Service-Name attribute is of type "string". It identifies the service to which the user has requested access. Service names MUST be assigned in a way independent of a specific administration domain (to be detailed in future versions of this document). 5.2 Requested-Action The Requested-Action attribute specifies what operation the entity receiving this attribute is requested to perform: price enquiry, amount reservation, amount capture, or price enquiry. Guenther & Tschofenig Expires January 9, 2005 [Page 13] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Requested-A. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA, or to become a sub-type of a new IANA assigned attribute type for event-based charging or charging in general. Length 3 Byte Requested-Action The value field of the Requested-Action attribute is of type "integer". The following integer values are supported: 1 price-enquiry 2 direct-debiting 3 reservation 4 capture All other values are reserved. 5.3 Cost The Cost attribute indicates price information. It contains the number (e.g., 70) of minor currency units (e.g., Cent) to be reserved or debited from the user's prepaid account. In cases where no minor currency unit is available the major currency unit must be taken. Guenther & Tschofenig Expires January 9, 2005 [Page 14] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Cost ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA, or to become a sub-type of a new IANA assigned attribute type for event-based charging or charging in general. Length 3 - 6 Byte Cost The value field of the Cost attribute is of type "integer" and indicates the number of minor (if possible; otherwise, major) currency units to be reserved or debited from the user's prepaid account. 5.4 Currency-Code This attribute indicates the currency to be applied to the value of the Cost attribute. Guenther & Tschofenig Expires January 9, 2005 [Page 15] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Currency-Code ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA, or to become a sub-type of a new IANA assigned attribute type for event-based charging or charging in general. Length 3 - 6 Byte Currency-Code The value field of the Currency-Code attribute is of type "string" and indicates the currency to be applied to the Cost value as indicated by the Cost attribute. The string value for a single currency is defined in [ISO4217]. 5.5 Charging-Session-Id This attribute is a unique identifier the EH assigns to an event. It is to facilitate the matching between different but correlated messages such as Amount Reservation Requests and Amount Capture Requests. In case of an Price Enquiry Request message, it is possible that the Charging-Session-Id identifier is not generated by the EH, but by the CH or the SP, depending on which of these entities sends the Price Enquiry Request. Guenther & Tschofenig Expires January 9, 2005 [Page 16] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Charging-Session-Id ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA, or to become a sub-type of a new IANA assigned attribute type for event-based charging or charging in general. Length >= 3 Byte Charging-Session-Id The value field of the Charging-Session-Id attribute is of type "string". 5.6 International Mobile Subscriber Identity (IMSI) If appropriate, this attribute can be used to identify a mobile subscriber. Thus, it fits in the series of standard Radius attributes such as Calling-Station-Id and Framed-IP-Address that are suitable in the scope of this document for request originator identification (especially at the Charging Handler's site which has to map debiting and reservation requests to the right user accounts). The definition of this attribute is borrowed from 3GPP where this attribute is called 3GPP-IMSI (see [3GPP.29.061]). Guenther & Tschofenig Expires January 9, 2005 [Page 17] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IMSI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA, or to become a sub-type of a new IANA assigned attribute type for event-based charging or charging in general. Length <= 17 Byte IMSI The value field of the IMSI attribute is of type "text". It contains an UTF-8 encoded IMSI. An IMSI consists of not more than 15 digits each of which requires one Byte in the value field of this attribute. The structure and content of IMSIs are defined in [3GPP.23.003]. Guenther & Tschofenig Expires January 9, 2005 [Page 18] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 6. Radius Messages for Event-based Charging This section explicitly introduces Radius messages for event-based charging and specifies which Radius attributes are mandatory or optional. See Section 4 for an informal description of these messages. Regarding the number of occurences of attributes in the Radius messages defined below, we use the following abbreviations: 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present. 6.1 Price Enquiry Request Packet Type: Access-Request (Code = 1) Attributes: Framed-IP-Address: 0-1 (see [RFC2865]) Calling-Station-Id: 0-1 (see [RFC2865]) IMSI: 0-1 Requested-Action: 1 (value MUST be set to 1 = price-enquiry) Service-Name: 1 Charging-Session-Id: 1 Note 1: None of the first three attributes must occur within this message. However, rating an event might be dependent on user identity in some scenarios (there might be, for instance, different user categories each of which has its own rules for rating). Note 2: According to [RFC2865], Radius Access-Requests MUST contain either a User-Password or a CHAP-Password or State attribute. An Access- Request MUST NOT contain both a User-Password and a CHAP-Password. Furthermore, an Access-Request MUST contain either a NAS-IP-Address or a NAS-Identifier (or both). Which of these attributes are trans- ferred in a Price Enquiry Request message in addition to the ones listed above depends on the usage scenario. Guenther & Tschofenig Expires January 9, 2005 [Page 19] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 6.2 Price Enquiry Response Packet Type: Access-Accept (Code = 2) Attributes: Charging-Session-Id: 1 Cost: 1 Currency-Code: 0-1 (currency might be clear from context) Note: The RE MUST use the same Charging-Session-Id value as presented in the corresponding Price Enquiry Request message. 6.3 Direct Debiting Request Packet Type: Access-Request (Code = 1) Attributes: Framed-IP-Address: 0-1 (see [RFC2865]) Calling-Station-Id: 0-1 (see [RFC2865]) IMSI: 0-1 Requested-Action: 1 (value MUST be set to 2 = direct-debiting) Service-Name: 1 Charging-Session-Id: 1 Cost: 1 Currency-Code: 0-1 (currency might be clear from context) Note 1: At least one of the first three attributes MUST occur within this message in order to enable the CH to map this request to the right user account. Note 2: According to [RFC2865], Radius Access-Requests MUST contain either a User-Password or a CHAP-Password or State attribute. An Access- Request MUST NOT contain both a User-Password and a CHAP-Password. Furthermore, an Access-Request MUST contain either a NAS-IP-Address or a NAS-Identifier (or both). Which of these attributes are trans- ferred in a Direct Debiting Request message in addition to the ones listed above depends on the usage scenario. Guenther & Tschofenig Expires January 9, 2005 [Page 20] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 6.4 Direct Debiting Response Packet Type: Access-Accept (Code = 2) Attributes: Charging-Session-Id: 1 The CH MUST use the same Charging-Session-Id value as presented in the corresponding Direct Debiting Request message. 6.5 Amount Reservation Request Packet Type: Access-Request (Code = 1) Attributes: Framed-IP-Address: 0-1 (see [RFC2865]) Calling-Station-Id: 0-1 (see [RFC2865]) IMSI: 0-1 Requested-Action: 1 (value MUST be set to 3 = reservation) Service-Name: 1 Charging-Session-Id: 1 Cost: 1 Currency-Code: 0-1 (currency might be clear from context) At least one of the first three attributes MUST occur within this message in order to enable the CH to map this request to the right user account. According to [RFC2865], Radius Access-Requests MUST contain either a User-Password or a CHAP-Password or State attribute. An Access- Request MUST NOT contain both a User-Password and a CHAP-Password. Furthermore, an Access-Request MUST contain either a NAS-IP-Address or a NAS-Identifier (or both). Which of these attributes are trans- ferred in an Amount Reservation Request message in addition to the ones listed above depends on the usage scenario. 6.6 Amount Reservation Response Packet Type: Access-Accept (Code = 2) Attributes: Charging-Session-Id: 1 Guenther & Tschofenig Expires January 9, 2005 [Page 21] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 The CH MUST use the same Charging-Session-Id value as presented in the corresponding Amount Reservation Request message. 6.7 Amount Capture Request Packet Type: Access-Request (Code = 1) Attributes: Framed-IP-Address: 0-1 (see [RFC2865]) Calling-Station-Id: 0-1 (see [RFC2865]) IMSI: 0-1 Requested-Action: 1 (value MUST be set to 4 = capture) Service-Name: 1 Charging-Session-Id: 1 According to [RFC2865], Radius Access-Requests MUST contain either a User-Password or a CHAP-Password or State attribute. An Access- Request MUST NOT contain both a User-Password and a CHAP-Password. Furthermore, an Access-Request MUST contain either a NAS-IP-Address or a NAS-Identifier (or both). Which of these attributes are trans- ferred in an Amount Capture Request message in addition to the ones listed above depends on the usage scenario. 6.8 Amount Capture Response Packet Type: Access-Accept (Code = 2) Attributes: Charging-Session-Id: 1 The CH MUST use the same Charging-Session-Id value as presented in the corresponding Amount Capture Request message. 6.9 Reject Packet Type: Access-Reject (Code = 3) Attributes: Charging-Session-Id: 1 Reply-Message: 0+ (see [RFC2865]) Reply-Message attributes are used here to transport textual indications to the receiver of this message why the corresponding request could not be processed successfully. Within the scope of this document, the following character strings are apparently helpful Guenther & Tschofenig Expires January 9, 2005 [Page 22] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 for describing reasons of request refusal: requested-action-not-supported missing-parameter (e.g., name of service is missing from request) invalid-parameter (e.g., service name "www.supercom.com/ superservice" is invalid) unknown-subscriber limits-violated (e.g., due to insufficient account cover) unspecified (no explicit reason provided) [RFC2865] recommends to UTF-8 encode the characters of these strings. Guenther & Tschofenig Expires January 9, 2005 [Page 23] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 7. IANA Considerations This document requires the assignment of new Radius attributes number for the following atttributes: Service-Name Requested-Action Cost Currency-Code Charging-Session-Id IMSI Guenther & Tschofenig Expires January 9, 2005 [Page 24] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 8. Security Considerations TBD Guenther & Tschofenig Expires January 9, 2005 [Page 25] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 9. References 9.1 Normative References [ISO4217] ISO, "Codes for the representation of currencies and funds", August 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000, . 9.2 Informative References [3GPP.23.003] 3GPP, "Numbering, addressing and identification; Release 6", 3GPP TS 23.003, June 2004. [3GPP.29.061] 3GPP, "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN); Release 6", 3GPP TS 29.061, June 2004. [I-D.draft-lior-radius-prepaid-extensions-03] Lior, A., Yegani, P., Chowdhury, K., Madour, L. and Y. Li, "PrePaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", draft-lior-radius-prepaid-extensions-03 (work in progress), February 2004, . Authors' Addresses Christian Guenther Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: christian.guenther@siemens.com Guenther & Tschofenig Expires January 9, 2005 [Page 26] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: hannes.tschofenig@siemens.com Guenther & Tschofenig Expires January 9, 2005 [Page 27] Internet-Draft Radius Prepaid Ext. for Event Charging July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Guenther & Tschofenig Expires January 9, 2005 [Page 28]